# Maintainer Decline

Guide for drafting issue closure and decline responses as an open-source package...

- Repository: https://github.com/posit-dev/skills (551 stars)
- Category: Design
- License: MIT
- Last updated: 2026-10-28
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add posit-dev/skills --skill maintainer-decline -g -a claude-code -y`
Codex: `npx skills add posit-dev/skills --skill maintainer-decline -g -a codex -y`
Cursor: `npx skills add posit-dev/skills --skill maintainer-decline -g -a cursor -y`
Gemini CLI: `npx skills add posit-dev/skills --skill maintainer-decline -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add posit-dev/skills`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

The rest: https://github.com/posit-dev/skills/blob/HEAD/open-source/maintainer-decline/SKILL.md