How to Write a Pull Request Description with AI

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.

---

Why PR Descriptions Get Skipped (or Written Badly)

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.

---

Step 1: Get Your Raw Diff

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

---

Step 2: Paste the Diff into Your AI Tool with This Prompt

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.

---

Step 3: Review and Edit the Output

The AI output will be 80–90% usable. Your job is to:

• Fix any context it couldn't infer from the diff alone (e.g., why this ticket existed)
• Add a link to the issue or ticket
• Trim anything that's redundant with the diff itself

This takes 2–3 minutes, not 15.

---

Step 4: Save a Template for Your Team

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.

---

The Full Prompt, Ready to Copy

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