| name | write-pull-request |
| description | Write GitHub pull request titles, descriptions, reviewer guidance, and validation notes in the repository's required format. Use when drafting a new PR body, revising an existing PR description, preparing reviewer guidance, or documenting checks and tests performed. |
Write Pull Request
- Base the PR on the actual diff, changed files, and checks. Do not invent tests, commands, or implications.
- Use this exact body structure:
## What was changed## How to review## What the implication was## Checks and tests performed
- For bug fixes, include the original symptom in
## What was changed only when it adds useful review context.
- Keep file references in the PR body repo-relative, not absolute local filesystem paths.
- Use a conventional-commit PR title that summarizes the change.
- Match the PR body to the size and complexity of the change. For small changes, prefer short prose over diagrams, long review checklists, or padded bullet lists.
Section Expectations
What was changed
Describe the change concisely. For small PRs, a short paragraph is enough.
For bug fixes, add an Original symptom this addresses: block right after the summary when it helps reviewers understand the change.
How to review
Point reviewers to the relevant file, section, or commit order. Keep this proportional to the diff.
What the implication was
Describe the practical impact directly. Use Mermaid only when it materially improves understanding.
Checks and tests performed
List only checks that add reviewer signal. Prefer:
- tests added or updated for this change
- targeted validation outside normal hook coverage
- meaningful manual verification
- broader gates like
pnpm run ci only when they add coverage beyond the default flow
- for property-based tests, the invariants asserted, generator bounds, and how failures can be replayed from seed/path
Do not restate obvious command behavior. If a routine command simply passed, say that directly.
