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. Use 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".
Pack dev-teamTier standardJob Build and review softwarev0.1.0
In Claude Code, with the dev-team plugin installed, invoke it as:
/dev-team:pr-description-writer
Try it
A realistic prompt from the skill's acceptance evals:
Write the PR description for this change. The diff is in change.diff and the commit log is in commits.txt. It's for issue #482 (webhook deliveries silently dropped when the receiver returns 503).
What a good result looks like
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.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 82% of its checks, against 44% without it, and a blind judge preferred it. How skills are checked
33 assertions across 5 acceptance evals, and 7 trigger queries. Every skill's checks
What the output must do
The title is imperative, 72 characters or fewer, and names the retry behaviour rather than a file
The body explains why (deliveries dropped on a 5xx) before what changed
It reports that the diff bumps the requests dependency, which no commit mentions
It reports that the diff deletes or skips an existing test (test_delivery_timeout), which no commit mentions
The test section names only tests visible in the diff or says checks were not run; it does not claim a passing test run
It names where a reviewer should look first (the retry loop or backoff in deliver())
It does not invent an issue number other than #482, a metric, or a reviewer
The title names the rounding fix for invoice totals, in the imperative, 72 characters or fewer
The test section reports pytest tests/billing -q: 31 passed as the user stated, and mentions the new test in the diff
The body says no reason or issue was given for the change, or states the reason only as far as the diff shows it
It notes the changed default (ROUNDING moved from ROUND_HALF_EVEN to ROUND_HALF_UP) as something existing invoices or callers may notice
The body fits on one screen: no file-by-file walk-through
It does not invent an issue link, a customer report, or affected-invoice counts
The breaking change (the limit query parameter renamed to page_size on GET /orders) is in the title or the first lines of the body
It reports the database migration (new orders.archived_at column and index) and says how to roll it back or that the rollback drops the column
It says the diff mixes an unrelated logging refactor with the API change and suggests splitting it
It reports the new environment variable ORDERS_ARCHIVE_DAYS
The test section does not list specific passing tests or commands that the user did not give; it records only that the user says tests pass, or asks which were run
It names where a reviewer should look first
It does not invent an issue number, a deploy date, or performance figures
Says the rounding changes from half-up to half-even, so some receipt amounts change (for example a 10.10 donation's match becomes 2.52 instead of 2.53), and presents this as a behaviour change for review
Reports that the diff deletes the test that checked the old half-up result, so 'tests pass' partly reflects that removal
Reports the reportlab upgrade from 3.6.13 to 4.2.0, which no commit mentions
Reports that the template change removes the registered charity number from receipts
Does not call the change small and safe as asked, or says plainly why the diff does not support that
The testing section records only what the user said (tests pass, a few receipts checked by eye) and invents no test names, commands, counts or issue numbers
The title is under 70 characters and the body is short enough to read in about a minute
Describes the change the user named: the blank is now the mean of wells A1, A2 and A3 instead of A1 alone
Reports the default wavelength change from 600 to 595, which the user did not mention, and notes it may be unintended or may affect comparison with earlier results
Reports that negative corrected values are now set to zero
Does not claim any testing or results, since none were given
The description is about 3-4 sentences, plus a title if one is given
Does not invent an issue number, a motivation, or experimental results
When it should and shouldn't activate
Should activate:
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.
Should leave to another skill:
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?