prlisted

<objective> Write the description a reviewer needs in order to review well: what changed, why, and how to convince themselves it works. The audience is someone who did not do the work and has twenty minutes. What they need is orientation and a way to verify — not a restatement of the diff, which they can already read. </objective> ## Two modes | Mode | Trigger | Behaviour | |---|---|---| | **Unattended** | A pipeline asks for the description at a path | Fill the template from the diff, tests and ticket. Write the file. **No questions, no git, no `gh`.** | | **Interactive** | A human runs it | Draft → confirm the summary → ask what the diff cannot answer → show the final → act only on an explicit go-ahead | ## Gather Read-only, always: - `git diff <base>...HEAD --stat` and `--name-status` - `git log <base>..HEAD --oneline` - The changed files themselves — enough to describe them accurately - The ticket and its acceptance criteria - The added or changed tests - The worklog's blast-radius entry, if there is one Base branch: whatever the request states, else `CONNECTIONS.md → version_control.base`, else the repository default. ## Template Fill exactly this. **Delete sections that do not apply** rather than writing "N/A" — an empty heading is a small tax on every reviewer who reads it. ```markdown [type]: <short description> Branch: `<branch>` · Target: `<base>` · Ticket: <id> ## Overview What this does and why, in one paragraph. Written like a person wrote it. ## Mot