Writing a good PR description takes longer than it should. You've already done the hard work — the code is done — but now you're staring at a blank text box trying to summarize context, motivation, and testing notes while your brain is already on the next task. AI handles this well. Here's a step-by-step walkthrough you can use today.
Bad PR descriptions slow down review cycles. Reviewers ask questions that are already answered in the diff, or they approve without really understanding the change. The fix isn't discipline — it's reducing the friction of writing a good description in the first place.
Start by pulling the diff between your branch and main:
git diff main...HEAD > pr_diff.txt
If the diff is large (500+ lines), focus on the meaningful parts — skip lockfile changes and generated files:
git diff main...HEAD -- '*.ts' '*.py' '*.go' > pr_diff.txt
Open your AI tool of choice (ChatGPT, Claude, Gemini — all work here) and use this prompt:
You are a senior engineer writing a pull request description for a code review.
Here is the diff:
<paste diff here>
Write a pull request description with the following sections:
1. **What changed** — a 2–3 sentence plain-English summary of what this PR does.
2. **Why** — the motivation or problem being solved.
3. **How to test** — concrete steps a reviewer can follow to verify the change locally.
4. **Notes for reviewer** — anything non-obvious, edge cases to watch, or follow-up work deferred.
Be specific. Reference actual function names, files, or logic from the diff. Do not be vague.
The AI output will be 80–90% usable. Your job is to:
This takes 2–3 minutes, not 15.
Once you've done this a few times, extract the structure into a .github/pull_request_template.md
file in your repo:
## What changed
## Why
## How to test
- [ ] Step 1
- [ ] Step 2
## Notes for reviewer
Now the AI output maps directly to the template fields. Every PR on your team starts from the same skeleton, and the quality floor rises across the board.
You are a senior engineer writing a pull request description for a code review.
Here is the diff:
[PASTE DIFF]
Write a pull request description with the following sections:
1. **What changed** — a 2–3 sentence plain-English summary of what this PR does.
2. **Why** — the motivation or problem being solved.
3. **How to test** — concrete steps a reviewer can follow to verify the change locally.
4. **Notes for reviewer** — anything non-obvious, edge cases to watch, or follow-up work deferred.
Be specific. Reference actual function names, files, or logic from the diff. Do not be vague.
This workflow takes about 5 minutes the first time and under 2 minutes once it's part of your routine. Better descriptions mean faster reviews — that's a compounding win on every PR you ship.
I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=medium_w8