Write PR

A PR body carries two things. The problem the PR solves, and what changed to solve it. Everything else is noise a reviewer has to read past.

Shape

<the problem, one or two sentences>

<what changed to solve it, one or two sentences>

- `path/to/module.ts`: what it does now
- `path/to/gone.ts`: deleted, callers moved to `module.ts`

---
Written by <model> using <harness>.

Bullets name load-bearing files. A file a reviewer can skim past gets no line.

Nothing else goes in the body. No summary of the summary, no test counts, no "this PR adds", no section that restates the title.

Rules

• Every line traces to a hunk in the diff. Describe what the code does now, not what it enables or unlocks.
• Name the problem concretely. "Threads over 200 messages froze the sidebar for ~4s" beats "performance issues in threads".
• Deletions and renames count as changes. They are the ones reviewers miss.
• Apply the unslop skill to the body before creating the PR.

Process

1. git log --oneline <base>..HEAD and git diff <base> --stat.
2. Read the diff itself, not just the stat. Behavior changes, deletions, and renames hide inside small line counts. Done when every file in the stat is either in a bullet or judged noise.
3. Write the problem, the change, the bullets, the blurb.
4. Cut. Done when every remaining line is one of those four things.
5. gh pr create --title "<prefixed>" --body-file <file> --base <base>.