Prompts / PR description

Writing gitpull-requestswriting

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.