Maintainer Decline
Guide for drafting issue closure and decline responses as an open-source package...
Install
npx skills add posit-dev/skills --skill maintainer-decline -g -a claude-code -y- Repository
- posit-dev/skills551
- Category
- Design
- Updated
- 7d ago
- License
- MIT
- Context cost
- Mediumabout 2,222 tokens
- Runs scripts
- No, instructions only
What it does
Guide for drafting issue closure and decline responses as an open-source package maintainer. Use when helping compose a reply that says \"no\" to a feature request, closes an issue as won't-fix, redirects a user to a different package, explains why a design choice is intentional, or otherwise declines or closes a community contribution. Also use when the maintainer needs to explain a deprecation, point out a user misunderstanding, or communicate an effort/scope tradeoff to a contributor.
Maintainer Decline
Help an open-source maintainer compose responses that close, decline, or redirect issues while leaving the contributor informed and respected.
Core Philosophy
Closure is not dismissal. A well-crafted decline educates, unblocks, or redirects the contributor productively. The goal is that someone reading your response walks away understanding why, even if they didn't get what they asked for.
Principles
Explain the why, not the what. Contributors understand they're being told "no." What they need is the reasoning: strategic direction, design philosophy, effort/benefit tradeoff, or the actual technical root cause.
Validate before declining. Acknowledge the contributor's point before the redirect. Phrases like "Yeah," "This is a reasonable idea," or "I think..." signal that you heard them before delivering the decision.
Offer a path forward when possible. Even a "no" can come with "but you could..." or "use X instead." Leave the contributor unblocked or pointed in the right direction.
Use "we" for design decisions. "We believe," "we've decided," "we experimented with..." positions decisions as team choices, not personal gatekeeping.
One decision per response. No hedging, no "maybe later" unless you mean it. Clear closure, even if that closure is "this will happen after X."
Brevity signals respect. Most declines land in 1, 3 sentences. Go longer only when the misunderstanding is significant or teaching is genuinely needed.
Acknowledge effort. If the contributor did real work (wrote a reprex, drafted code, did research), name it. "Thanks for the detailed report" costs nothing and signals you value their time.
Response Patterns
Choose the pattern that fits the situation. These are not templates, they're structural moves you can adapt.
Duplicate
One line. Link the original issue. No elaboration needed.
Duplicate of #7651
Fixed / Resolved
Link the fix. Nothing else required.
