Use pr-description-writer
Write the pull request title and description for one change, from the actual diff and commits
Write the pull request title and description for one change, from the actual diff and commits: what changed and why, how it was tested with only the checks that were really run, what a reviewer should look at first, and the risk and rollback. It also reports what the diff contains that the commits don't mention, such as a dependency bump, a deleted test or a schema change.
Reach for it when the user asks to write a PR description, a pull request summary, a merge request body, or says "describe this change for review", "write up this branch".
Install it
npx skilldrop-cli install pr-description-writer # Claude Code, your user folder
npx skilldrop-cli install pr-description-writer --project # Claude Code, this repo
npx skilldrop-cli install pr-description-writer --ide cursor # or kiro, codex, antigravity, copilot
It is part of the Dev team pack: --pack dev-team installs it with its neighbours.
Ask for it
Say it the way you would to a colleague. Requests like these route to it:
- "Write the PR description for this branch"
- "I need a pull request summary for these commits before I ask for review"
- "Here's my diff, write the merge request body"
- "My PR description just says 'fixes stuff'. Rewrite it properly from the diff."
Requests like these belong to a different skill, so it shouldn't answer them:
- "Write the release notes for everything merged since v2.3.0"
- "Is this branch safe to merge? Run the full review."
- "What tests should we write for the new refund flow?"
If another skill answers instead, ask for this one by name: "use pr-description-writer".
Check what you get
A good result:
- Everything traces to the diff, the commits or the user. No invented issue numbers, metrics, reviewers or test results.
- The test section is honest. A check that wasn't run is listed as not run.
- A reviewer learns where to look. The body names the riskiest part of the diff.
- Surprises are surfaced. A dependency bump, deleted test, migration or API change that the commits skip appears under Reviewer notes.
- Claims about the code are checked. Before saying a test does or doesn't cover a change, or that two changes are independent, work it through against the diff (run the arithmetic, trace the call). If you can't confirm it, leave the claim out.
- Short. The body fits on one screen. A long PR gets a tighter summary, not a longer one.
Use something else when
- Notes for a whole release or a changelog entry across many changes. Use
release-notes. - Deciding whether the change is safe to merge. Use
pre-merge-review. - Designing the tests the change needs. Use
test-plan-generator.
Next
- SKILL.md, the instructions the agent reads
- Its page on the site
- Related: pre-merge-review, release-notes, test-plan-generator