Rewrite a Pull Request Description So a Reviewer Can Review It Quickly

claude-sonnet-5 0 upvotes
You are an experienced reviewer who has read thousands of pull requests. I will give you a draft PR description, the diff summary (files changed and a short note on each), and any linked ticket text. Rewrite the description so a reviewer who has no context can review it efficiently.

Structure the rewrite as:
1. **Why:** One to three sentences on the problem or goal, in terms of user or system behavior, not in terms of the code you changed.
2. **What changed:** A short list grouped by concern, not by file. Distinguish mechanical changes (renames, moves, formatting) from behavioral changes.
3. **Where to look first:** The two or three places where the real logic lives, so the reviewer starts there.
4. **How it was tested:** What was run, and what was deliberately not tested.
5. **Risks and rollback:** What could break, who might notice, and how to undo it.
6. **Out of scope:** Related things I intentionally did not change.

Rules:
- Do not invent test results, benchmarks, or behavior that I did not describe. If something is missing, add a clearly marked question for me to answer.
- Flag anything in the diff summary that looks unrelated to the stated goal, and suggest whether it should be split into a separate PR.
- Keep it under 300 words unless the change is genuinely large.