What this prompt does
This prompt turns the AI into a senior engineer who writes a pull-request description a busy reviewer can approve fast, working only from the diff and context you supply. You paste the [diff], link the [ticket] or motivation, set the [risk_level], and name the [reviewers]. It returns six parts: a two-sentence summary of what the PR does and why it is safe, the motivation tied to the ticket, a bulleted change list grouped by area, a test plan scaled to the risk level, a screenshots placeholder for user-facing changes, and rollback notes.
The structure works because it is anchored to the diff and explicitly told not to invent changes. That keeps the description honest: every bullet in the changes list must trace to the diff, so the scope it describes matches what actually shipped instead of quietly overstating the work. The variables shape tone and depth: [ticket] grounds the motivation in a concrete reason, [risk_level] scales how thorough the test-plan checklist becomes, and [reviewers] lets the model address the description to the right audience and pitch the detail accordingly. The output is ready-to-paste Markdown, so the description goes straight into the PR body with no reformatting.
When to use it
- You want reviewers to approve quickly instead of guessing at intent.
- Your PRs keep stalling on thin or missing descriptions.
- A change is risky enough to need a real test plan and rollback notes.
- You have a user-facing change that needs a screenshots section.
- You want each change bullet traceable to the diff, not invented.
- You are standardising PR descriptions across a team or client repos.
Example output
You get a ready-to-paste Markdown PR description: a two-sentence summary of what the PR does and why it is safe, a motivation paragraph referencing the ticket, a bulleted changes list grouped by area with each line traceable to the diff, a reviewer-facing test-plan checklist sized to the risk level, a screenshots and recordings placeholder for user-facing work, and rollback notes covering how to revert and what to watch after deploy. It is addressed to your named reviewers and reads like a description a senior engineer wrote, not a generic template.
Pro tips
- Paste the full
[diff]; the description can only be accurate about what it can see. - Put a real ticket ID in
[ticket]so the motivation section is concrete, not hand-wavy. - Set
[risk_level]honestly; it directly scales how detailed the test plan becomes. - Check deliverable three carefully so every change bullet traces to the diff and scope isn't inflated.
- Name
[reviewers]so the test plan speaks to who is actually reviewing. - For large diffs, split the PR first; a tighter diff produces a sharper description.
