write-prlisted

# Write PR Description The body exists so a reviewer can decide where to spend their attention. It says why the change exists, what the new behaviour is, and which part of the diff carries the risk. The diff already lists the files. ## Process 1. Check the change against [reviewability](#reviewability) and raise a split where one is warranted 2. Write the title: `TICKET-KEY: [Short descriptor]`, colon after the key, descriptor in sentence case. Prefer an imperative verb and the domain class names as they appear in code over a prose paraphrase. Where the PR ships more than one deliverable, join them with ` + `, the feature first and reusable infrastructure second. No ticket key available? Ask rather than inventing one 3. Pick the Change Type: Feature, Bugfix, Improvement, Task, Story, Chore, or Hotfix. Combine two (`Bugfix/Improvement`, `Feature/Story`) only where the PR genuinely spans both 4. Write the body from `assets/body-template.md`, or the repository's own template where it has one 5. Check the draft against [the rules](#rules) and adjust where it drifts Commit subjects are not PR titles: they take the `git-commit` skill's `TICKET-KEY - ...` hyphen. Where the repository squash-merges, the merged subject deliberately inherits this title's colon. ## Reviewability A PR carries one review objective. Before opening it, answer: - What is the one thing this PR asks the reviewer to judge? - Can they get the intent from the title and description, without read