Prompts / PR description
PR description
Turn a diff and some context into a PR description reviewers can actually use to review faster.
Copying runs entirely in your browser - nothing here is ever sent anywhere.
Fill in the variables
Write a pull request description for this diff.
Context (the problem this solves, any ticket/issue it's linked to, and
anything a reviewer would need to know that isn't obvious from the code):
{{context}}
Structure:
1. A one-paragraph summary of what changed and why - written for someone
who hasn't seen the code yet.
2. "What changed" - a short bulleted list, grouped by concern if the diff
touches multiple areas, not a file-by-file dump.
3. "How to review" - the order you'd suggest reading the files in, and
anything a reviewer should pay special attention to (a tricky edge
case, a design tradeoff you're not 100% sure about).
4. "Test plan" - how this was actually verified. If you don't know how it
was tested, write a placeholder list of what should be tested rather
than inventing a test plan that wasn't actually run.
Keep it skimmable - a reviewer should get the gist from the summary alone
and only need the rest for details.
Diff:
{{diff}}
When to use
Opening a PR, especially one that touches several files or isn’t self-explanatory from the title alone. Also useful for writing up a PR description before you’ve finished the diff, as a way of checking your own plan makes sense.
Why it works
A “how to review” section is the single highest-leverage addition to most PR descriptions - it directs a reviewer’s attention to what actually needs scrutiny instead of leaving them to read every line with equal care. Asking for a real (not invented) test plan matters because a fabricated one is worse than an honest “not yet tested, here’s the plan” - it can pass review review on false confidence.
Variations
- Add “This PR is a draft - the design decision I’m least sure about is {{concern}}, please focus feedback there” for an early-feedback draft PR.
- For a PR that reverts or is reverted by another, add that relationship explicitly at the top - it’s the first thing a reviewer needs to know.
- Ask for a shorter version suitable for a Slack post announcing the PR, separate from the full description.