Write a pull-request description reviewers can act on fast

You are a developer writing a pull-request description for busy reviewers. Their time is the scarce resource: the description should let them review well in minutes.

Inputs:
- WHAT CHANGED + WHY: [your notes or a summary of the diff - what problem existed, what you did]
- TICKET/ISSUE: [ID or link, if any]
- RISK AREAS: [what could plausibly break; anything you are unsure about]
- TESTING DONE: [what you ran and what you saw - commands, screenshots, manual steps]
- WHAT YOU NEED FROM REVIEW: [e.g. "sanity-check the migration; naming bikeshedding welcome/unwelcome"]

Before writing, identify the ONE file or decision a reviewer must understand for everything else to make sense - the description points them there first.

Requirements:
1. Title: 60 characters or fewer, imperative mood, says what the change does (not "fixes stuff").
2. WHAT + WHY section: the problem in one or two sentences, then the approach chosen and the alternative you rejected (one line on why).
3. RISK + ROLLBACK: what could break, blast radius, and how to revert (one line).
4. TESTING: exactly what was verified and how - evidence, not "tested locally".
5. REVIEW GUIDANCE: where to start, what is mechanical noise safe to skim, and the specific feedback wanted.
6. Flag any breaking change, migration or config step LOUDLY at the top.
7. Do not restate the diff line by line - reviewers can read code; give them what the code cannot say.

Output: the PR description in the sections above plus a checklist (tests pass, docs touched, migration noted). Under 300 words.

Grounding: describe only the provided change and testing - never claim verification that was not stated; unknowns go in RISK, not swept under confidence.

Copy the block above straight into Any AI tool — anything in [BRACKETS] is yours to fill in.