---
name: the-maintainers-no
description: "Say no as an open-source maintainer without burning contributors or yourself — the feature that doesn't fit, the PR that took someone a weekend but can't merge, the company that wants free support, the fork suggestion said kindly. Use when a maintainer says 'how do I reject this PR nicely', 'a company is demanding support', 'this feature request won't die', or is avoiding an issue thread out of guilt. Produces the specific no for the situation, with reasoning shown and the relationship kept."
homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/the-maintainers-no.html
metadata:
  {
    "openclaw": { "emoji": "🧠" }
  }
---

# The Maintainer's No Skill

Maintainer burnout is mostly unsent nos: the feature request at 40 comments,
the well-meant PR that would triple the maintenance surface, the company
that filed "urgent" on a volunteer's project. Every avoided no costs a
week of low-grade guilt; the sent no costs five minutes and is almost never
received as badly as feared. This skill writes the *specific* no each
situation needs — with the reasoning shown, the effort honored, and a real
alternative where one exists — because "no with a why and a path" keeps
contributors that "maybe someday" quietly loses.

## What This Skill Produces

- The **situation-fit no**, drafted ready to post: scope-no, PR-no,
  support-no, urgency-no, or the fork blessing
- The **reasoning paragraph**: the project-vision line that makes this no
  consistent instead of personal (and reusable next time)
- An **alternative that's real**: plugin/extension point, the fork blessing,
  a linked workaround, a paid-support pointer if one exists — or nothing,
  stated honestly, if nothing exists
- A **policy line** worth adding to CONTRIBUTING/README so the next no is
  half-written

## Required Inputs

Ask for (if not already provided):
- The thread/PR/request text, and how long it's been festering
- The real reason it's a no (doesn't fit vision? maintenance cost? just
  don't want to? — all valid; the phrasing differs)
- Who's asking: first-timer, regular contributor, company, drive-by
- What the maintainer could genuinely offer, if anything (review a smaller
  PR? accept behind a flag? nothing?)

## Framework

1. **Diagnose the no.** Scope-no (doesn't fit what this project is) ·
   cost-no (fits, but the maintenance is forever and it's mine) · PR-no
   (effort real, direction wrong) · support-no (this is unpaid volunteer
   time being invoiced) · capacity-no (fits, but not this year — the only
   no that may honestly become "someday").
2. **Honor effort before delivering direction.** For PRs especially: name
   something genuinely good in it first (one specific thing, not flattery).
   The order is: thanks-with-specifics → the no with the why → the path if
   real. Skipping straight to the no is efficient and expensive.
3. **Show the vision line, not the mood.** "This project deliberately stays
   [small/zero-dep/single-purpose]; features like X belong in
   [plugins/forks/other tools]" — a no anchored to a stated principle
   generalizes; a no anchored to today's energy invites relitigation.
   If the principle isn't written anywhere yet, this is the moment: the
   skill drafts the CONTRIBUTING line.
4. **Bless the fork sincerely.** "This is exactly what forks are for — the
   license means you don't need my permission, and I mean that as an
   invitation, not a brush-off" defuses more standoffs than any other
   sentence in open source.
5. **For companies: name the exchange.** Volunteer-maintained ≠ SLA. The
   reply states what's available free (the issue queue, at volunteer pace),
   what isn't (deadlines, priority), and — if the maintainer wants it —
   the paid path ("sponsorship/support contract gets your issue a
   scheduled slot"). No apology anywhere in it.
6. **Close the loop physically.** The no ends with the issue's fate:
   closed-wontfix, converted to discussion, or left open behind a named
   condition. A no that leaves the thread open re-accrues the guilt.

## Output Format

```
## Diagnosis
[Which no this is, and the real reason in one honest line]

## The reply (ready to post)
[Thanks-with-specifics → the no with the vision line → the real path or
honest nothing → the thread's fate]

## Add to CONTRIBUTING (so the next one is half-written)
[The policy line this no just established]

## If they push back
[The one-paragraph second reply — same decision, warmer, final]
```

## Quality Checks

- [ ] The no is unambiguous — a reader cannot mistake it for maybe
- [ ] Effort is honored with a specific, true observation, not a compliment
      template
- [ ] The reasoning cites a project principle that will still be true next
      month
- [ ] Any offered alternative is real — no "PR welcome" unless a PR would
      genuinely merge
- [ ] The thread's fate is stated (closed / converted / condition), and the
      pushback reply doesn't reopen the decision

## Anti-Patterns

- [ ] Do not soften into ambiguity — "maybe down the road" costs you this
      conversation again in six months, with interest
- [ ] Do not apologize for the project's boundaries; gratitude yes,
      apology no
- [ ] Do not match a demanding tone — the calm no in a heated thread is
      read by every future contributor, not just this one
- [ ] Do not invent roadmap promises to escape the moment
- [ ] Do not skip the fork blessing out of possessiveness — the license
      already said yes; saying it warmly is free

## Related

[[maintainer-triage]] — the system that catches these before they fester;
[[saying-no-kindly]] — the general craft; [[first-maintainer-month]] for
setting the boundaries early enough that nos stay rare.