Pr Writeup

---
name: pr-writeup
description: Write a clear, reviewer-friendly pull-request description from the actual branch diff. Use when the user asks to open a PR, write PR notes, or summarize a branch's changes for review.
---

# PR write-up

Produce a PR description grounded in the real diff, not a guess. Follow these steps.

## 1. Gather the facts
- Base branch: `git merge-base HEAD origin/main` (fall back to `origin/master` if there is no `main`).
- Diff summary: `git diff --stat <base>...HEAD` for the shape of the change.
- Full diff: `git diff <base>...HEAD` — read it before writing a word.
- Commit subjects: `git log --format='%s' <base>..HEAD`.

## 2. Write the description
Use this structure. Keep it tight — reviewers skim.

```
## What & why
<2–4 sentences: what this changes and the problem it solves. Lead with the user-
or system-visible effect, not the file list.>

## Changes
- <the handful of load-bearing changes, each one line; group trivia like "tests,
  formatting" into a single bullet>

## Testing
- <what you ran and what passed: build, test suite, manual steps. Be specific —
  "added 3 tests covering the empty-input case; full suite green" beats "tested">

## Risk / rollout
- <anything a reviewer should worry about: migrations, config, breaking changes,
  feature-flag state. Write "none" if genuinely none — don't invent risk.>
```

## Rules
- Describe only what the diff actually does. If a commit message claims something the diff doesn't show, trust the diff and flag the mismatch.
- No filler ("this PR aims to…"). Active voice. Name things the way the codebase names them.
- Don't include a "Generated by" line or emoji unless the repo's other PRs use them — match house style.
- If the diff is large and does several unrelated things, say so and suggest splitting; a reviewer will thank you.