pr-description-generator
starsforks
How to install pr-description-generator?
girijashankarj/cursor-handbook/pr-description-generator
$npx -y skills add girijashankarj/cursor-handbook --skill pr-description-generatorGenerate comprehensive PR titles and descriptions with summary, test plan, risks, and linked issues. Use when the user asks to write or improve a pull request description.
SKILL.md
| 1 | # Skill: PR Description Generator |
| 2 | |
| 3 | Analyze branch changes and produce a complete pull request title and description following team conventions. |
| 4 | |
| 5 | ## Trigger |
| 6 | When the user asks to generate, write, or improve a PR description — or when opening a new pull request. |
| 7 | |
| 8 | ## Prerequisites |
| 9 | - [ ] Working on a feature/fix branch (not `main` or `develop`) |
| 10 | - [ ] Commits exist on the branch |
| 11 | - [ ] Base branch identified (default: `main`) |
| 12 | |
| 13 | ## Steps |
| 14 | |
| 15 | ### Step 1: Gather Branch Context |
| 16 | - [ ] Get current branch: `git branch --show-current` |
| 17 | - [ ] Get base branch (ask user or default to `main`) |
| 18 | - [ ] Get commit log: `git log --oneline $(git merge-base HEAD origin/main)..HEAD` |
| 19 | - [ ] Get file summary: `git diff --stat origin/main...HEAD` |
| 20 | - [ ] Get full diff summary: `git diff origin/main...HEAD --stat` |
| 21 | - [ ] Count changes: files changed, insertions, deletions |
| 22 | |
| 23 | ### Step 2: Analyze Change Scope |
| 24 | - [ ] Identify the primary change category (feature, fix, refactor, docs, chore) |
| 25 | - [ ] List all affected modules/packages |
| 26 | - [ ] Identify breaking changes |
| 27 | - [ ] Identify database migrations |
| 28 | - [ ] Identify new dependencies |
| 29 | - [ ] Note any security-relevant changes (auth, permissions, input validation) |
| 30 | |
| 31 | ### Step 3: Generate PR Title |
| 32 | - [ ] Format: imperative mood, 50–72 characters |
| 33 | - [ ] Mirror the primary commit or user-facing outcome |
| 34 | - [ ] Prefix with type if team convention: `feat: ...`, `fix: ...` |
| 35 | - [ ] For draft PRs, prefix with `[WIP]` or `[Draft]` |
| 36 | |
| 37 | ### Step 4: Generate PR Body |
| 38 | |
| 39 | #### Summary Section |
| 40 | - [ ] 2–4 sentences explaining **what** changed and **why** |
| 41 | - [ ] Link to design doc, RFC, or ticket if applicable |
| 42 | |
| 43 | #### Type of Change |
| 44 | - [ ] Classify: feature / bug fix / docs / refactor / chore / breaking change |
| 45 | - [ ] Use checkboxes if PR template supports it |
| 46 | |
| 47 | #### Changes Made |
| 48 | - [ ] Bullet list of key changes (grouped by module if multi-module) |
| 49 | - [ ] Mention new files, deleted files, renamed files |
| 50 | - [ ] Highlight architectural decisions |
| 51 | |
| 52 | #### Testing |
| 53 | - [ ] List what was tested: unit, integration, manual |
| 54 | - [ ] Note what was **not** tested and why |
| 55 | - [ ] Include commands to reproduce: `npm test -- --grep "feature-name"` |
| 56 | - [ ] Mention if type-check and lint pass |
| 57 | |
| 58 | #### Risk & Rollback |
| 59 | - [ ] Breaking changes and migration steps |
| 60 | - [ ] Feature flags used |
| 61 | - [ ] Rollback strategy (revert commit, feature flag toggle) |
| 62 | - [ ] Performance implications |
| 63 | |
| 64 | #### Screenshots / Recordings |
| 65 | - [ ] Include placeholder section for UI changes |
| 66 | - [ ] Before/after screenshots when relevant |
| 67 | |
| 68 | #### Checklist |
| 69 | - [ ] Tests added/updated |
| 70 | - [ ] Documentation updated |
| 71 | - [ ] No secrets or PII in code |
| 72 | - [ ] Type-check passes |
| 73 | - [ ] Lint passes |
| 74 | - [ ] Breaking changes documented |
| 75 | |
| 76 | #### Related Issues |
| 77 | - [ ] `Closes #123` for issues this PR resolves |
| 78 | - [ ] `Refs #456` for related issues |
| 79 | - [ ] Link to parent epic or project board |
| 80 | |
| 81 | ### Step 5: Security Review |
| 82 | - [ ] Verify no secrets, internal hostnames, or PII in the PR description |
| 83 | - [ ] Verify no internal URLs or resource ARNs |
| 84 | - [ ] Use generic placeholders where needed |
| 85 | |
| 86 | ### Step 6: Output |
| 87 | - [ ] Present title and body in a copyable format |
| 88 | - [ ] Optionally provide a shorter version for stacked PRs |
| 89 | - [ ] Suggest reviewers based on changed files (if CODEOWNERS exists) |
| 90 | |
| 91 | ## Rules |
| 92 | - **NEVER** include secrets, API keys, or real infrastructure names in PR text |
| 93 | - **NEVER** include PII (customer names, emails, etc.) |
| 94 | - **ALWAYS** mention what testing was done and what was skipped |
| 95 | - **ALWAYS** flag breaking changes prominently |
| 96 | - Keep the summary concise — reviewers skim first, read details second |
| 97 | |
| 98 | ## Template Output |
| 99 | |
| 100 | ```markdown |
| 101 | ## Summary |
| 102 | Brief description of changes and motivation. |
| 103 | |
| 104 | ## Type of Change |
| 105 | - [ ] Feature |
| 106 | - [ ] Bug fix |
| 107 | - [ ] Refactor |
| 108 | - [ ] Documentation |
| 109 | - [ ] Breaking change |
| 110 | |
| 111 | ## Changes |
| 112 | - Added X to handle Y |
| 113 | - Updated Z for better performance |
| 114 | - Removed deprecated W |
| 115 | |
| 116 | ## Testing |
| 117 | - [x] Unit tests added for new service |
| 118 | - [x] Type-check passes |
| 119 | - [ ] Integration tests (not applicable — no API changes) |
| 120 | |
| 121 | ## Risk & Rollback |
| 122 | - Low risk — additive change behind feature flag |
| 123 | - Rollback: disable `FEATURE_X` flag |
| 124 | |
| 125 | ## Screenshots |
| 126 | N/A (backend only) |
| 127 | |
| 128 | ## Checklist |
| 129 | - [x] Tests added |
| 130 | - [x] Docs updated |
| 131 | - [x] No secrets in code |
| 132 | - [x] Type-check passes |
| 133 | |
| 134 | ## Related Issues |
| 135 | Closes #123 |
| 136 | Refs #100 |
| 137 | ``` |
| 138 | |
| 139 | ## Completion |
| 140 | Copy-paste ready PR title and description. If the branch has many commits spanning multiple concerns, suggest splitting into stacked PRs. |
| 141 | |
| 142 | ## If a Step Fails |
| 143 | - **No commits on branch:** Ask the user to describe planned changes |
| 144 | - **Can't determine base branch:** Default to `main`, ask for confirmation |
| 145 | - **Large diff (>50 files):** Group changes by module, provide high-level summary |
| 146 | - **No test info:** Add a note: "Testing plan TBD" and flag for the user |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
