| name | write-pr-desc |
| description | Generate a GitHub Pull Request description. Creates structured, reviewer-centric PR descriptions with title, summary, why (before/after), implementation details, and impact. Use when user says "write PR description", "PR desc", "describe this PR", or "generate PR description". |
| compatibility | Requires git for diff context, optionally gh CLI for PR metadata. |
Write PR Description
Generate a concise, factual, reviewer-centric Pull Request description.
Core Principles
- Be concise, factual, and reviewer-centric
- Use short sentences, bullet points, and specific nouns
- Present tense, active voice
- Never make up information — only use what's in the code
- Focus on "why" over "what" — the diff shows what changed
Process
- Get the diff context (staged changes, branch diff, or PR diff)
- Understand what changed and why
- Generate description following the template below
Required Sections
Title (50 chars max)
Use imperative mood that completes: "If applied, this PR will..."
- Start with action verb: Add/Fix/Update/Remove/Refactor
- Capitalize first word, no period
Summary
Brief overview explaining what this PR accomplishes:
- Primary change using imperative mood
- Scope: packages/modules affected
- Root cause (for bugs) or motivation (for features)
- Feature flags or configuration changes
Why
Show the problem and solution through scenarios.
### [Component/Feature Name]
[One-line problem statement]
**Before:**
- Scenario: [specific situation] → [problem/outcome]
- Impact: [user/system effect]
[ASCII diagram if it clarifies flow - 5-10 lines]
**After:**
- Scenario: [same situation] → [fixed outcome]
- Impact: [improvement achieved]
[ASCII diagram of new flow if needed]
Implementation
3-5 bullets covering technical approach:
- Key design decisions and trade-offs
- New interfaces or patterns introduced
- Breaking changes or migrations
- Why this approach over alternatives
- Reference related commits if multiple logical changes
Impact & Testing
**Risk:** [One line - what could break]
**Changes:**
- Performance: [complexity/latency if significant]
- Behavior: [user-facing/API changes]
- Security: [auth/data access if relevant]
**Testing:**
- Coverage: [what's tested]
- Manual validation: [if needed]
**Rollout:**
- [Feature flags, compatibility notes]
Related
- Links: [issues, RFCs]
- Follow-ups: [TODOs with owners]
Constraints
- Max ~200 lines total
- Every section must add unique value
- Concrete examples > abstract descriptions
- Scenario-driven explanations
- Include ASCII diagrams only when they clarify architecture
Examples
See EXAMPLES.md for bug fix and feature PR examples.