Verified against Claude Code · 2026-07-20
Turn a raw git diff into a pull request description reviewers can use
A format-forced prompt that turns a raw diff into a structured pull request description written for a reviewer who has not seen the code, instead of a generic one-line summary.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are writing this pull request description for a reviewer who has not seen the diff yet and will not open every file before deciding how to review it. Write for that reader, not for someone who, like you, just read every line. TICKET JIRA-4821 — zero-row CSV export throws a TypeError FORMAT Summary: one or two sentences on what changed and why, in plain language, no implementation detail yet. Why: the problem or requirement that made this change necessary. Link the ticket if one exists. What changed: a bullet list grouped by area or module, not by file. A reviewer thinks in features, not file trees. How this was tested: what you actually ran, such as unit tests, manual repro steps, or screenshots. Not "tests pass" — specifics. Risk and rollback: what is the blast radius if this is wrong, and how would it be reverted or flagged in production? CONSTRAINTS - Do not describe the diff line by line. Describe intent and effect. - Do not claim test coverage or manual verification that is not backed by something specific you can name. - If the diff contains changes unrelated to the stated purpose, call that out explicitly under What changed instead of omitting it. - Keep it skimmable in under sixty seconds. This is a routing document for the reviewer's attention, not the full explanation. Paste the diff, or git diff output, below this line, unedited.
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Asked to summarize a diff with no format, a model reliably writes from its own vantage point — it just read every changed line, so it under-explains, producing the generic this pull request updates the checkout flow that tells a reviewer nothing about what to actually look at. Explicitly naming the reader as a reviewer who has not seen the diff yet is a documented technique for calibrating output to an audience rather than just a format: the instruction changes what the model chooses to include, not only how it is arranged. Forcing a fixed section template of summary, why, what changed, how tested, and risk does two things at once — it prevents the generic one-liner, and it makes an incomplete description visually obvious, since an empty or vague how this was tested section is far easier for a human to notice and reject than a missing sentence buried in a paragraph. The explicit instruction to flag unrelated changes rather than omit them also counters a real failure mode of diff summarization: a model asked to describe the change will describe the change it judges most relevant to the stated purpose, silently dropping a drive-by edit a reviewer actually needed to see.
What you get back
Summary: Fixes CSV export throwing an error when a report has zero rows. Why: Support ticket JIRA-4821 — three customers hit this in the last week when filtering to an empty date range. What changed: - Reporting/export: guarded the average-row calculation against a zero total instead of dividing into NaN. How this was tested: added a unit test for a zero-row report and re-ran the full export test suite locally, 22 passed. Risk and rollback: low risk, one-line guard on a pure function; revert is a single commit revert with no data migration involved.
Verified against
Claude Code Sonnet 4.6 · 2026-07-20
GitHub Copilot Copilot Chat 1.250 (VS Code) · 2026-07-21
Changelog
- 2026-07-21 — Initial publish, verified against Claude Code (Sonnet 4.6) and GitHub Copilot Chat.
Building this for real?
This is a free starting point. If you'd rather have custom software built and running for your business, that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
