Use this skill when the user asks for a PR description, pull request body, or a body draft for a branch or existing PR.
Do not use this skill for PR titles, commit names, code review, release notes, changelogs, creating or publishing PRs, marking PRs ready, monitoring CI, or fixing branches.
Before drafting, read PR body rules. Follow those rules for section structure, bug-fix formatting, Sentry links, legal/regulatory citations, testing notes, large diffs, and examples.
Workflow
- Pin the source of truth before reading changed files.
- Existing PR request: use the PR's exact current remote diff and metadata.
- Current branch request: use the exact branch diff the user wants described.
- Ambiguous published-PR plus local-WIP state: ask a brief follow-up before mixing remote PR changes with unpublished local changes.
- Preserve required sections from
.github/pull_request_template.md when it exists, because GitHub will not apply the template when a PR is created with an explicit body.
- Infer the goal, behavior changes, DB/schema/data changes, likely affected workflow, independent merge safety, and testing coverage from the diff before asking follow-up questions.
- Use the bug-fix format when the user says the PR is a bug fix or the diff clearly shows a targeted bug fix. If a bug-fix body needs a Sentry URL and none is available, stop and ask for it.
- If legal, regulatory, tax, immigration, employment, or government-program rules materially motivate the change, verify a current authoritative source before citing it.
Output Contract
- Return only the final PR description as raw Markdown, with no commentary before or after it.
- Make
## Context the first section unless the repository template requires another first section.
- Include
## Summary, ## Independent Merge Safety, and ## Testing.
- Include
## Behavior Change for normal PRs.
- Include
## Root Problem and ## Solution for bug fixes.
- Include
## DB Changes, ## Key Files Changed, and ## Related PRs / Follow-ups only under the conditions in the reference.
- Mark merge-safety checkboxes truthfully from the diff.
- Do not invent testing coverage. Explicitly state whether all new behavior is covered by system specs, and list any behavior that was not covered by system specs.
1---2name: write-pr-description3description: Draft a GitHub pull request description or PR body from an exact branch or PR diff. Use for requests like "write a PR description/body", including normal PRs and bug-fix PRs; do not use for PR titles, commit messages, reviews, release notes, CI repair, or PR publication workflows unless those workflows explicitly delegate body drafting.4---56Use this skill when the user asks for a PR description, pull request body, or a body draft for a branch or existing PR.78Do not use this skill for PR titles, commit names, code review, release notes, changelogs, creating or publishing PRs, marking PRs ready, monitoring CI, or fixing branches.910Before drafting, read [PR body rules](references/pr-body-rules.md). Follow those rules for section structure, bug-fix formatting, Sentry links, legal/regulatory citations, testing notes, large diffs, and examples.1112## Workflow13141. Pin the source of truth before reading changed files.15 - Existing PR request: use the PR's exact current remote diff and metadata.16 - Current branch request: use the exact branch diff the user wants described.17 - Ambiguous published-PR plus local-WIP state: ask a brief follow-up before mixing remote PR changes with unpublished local changes.182. Preserve required sections from `.github/pull_request_template.md` when it exists, because GitHub will not apply the template when a PR is created with an explicit body.193. Infer the goal, behavior changes, DB/schema/data changes, likely affected workflow, independent merge safety, and testing coverage from the diff before asking follow-up questions.204. Use the bug-fix format when the user says the PR is a bug fix or the diff clearly shows a targeted bug fix. If a bug-fix body needs a Sentry URL and none is available, stop and ask for it.215. If legal, regulatory, tax, immigration, employment, or government-program rules materially motivate the change, verify a current authoritative source before citing it.2223## Output Contract2425- Return only the final PR description as raw Markdown, with no commentary before or after it.26- Make `## Context` the first section unless the repository template requires another first section.27- Include `## Summary`, `## Independent Merge Safety`, and `## Testing`.28- Include `## Behavior Change` for normal PRs.29- Include `## Root Problem` and `## Solution` for bug fixes.30- Include `## DB Changes`, `## Key Files Changed`, and `## Related PRs / Follow-ups` only under the conditions in the reference.31- Mark merge-safety checkboxes truthfully from the diff.32- Do not invent testing coverage. Explicitly state whether all new behavior is covered by system specs, and list any behavior that was not covered by system specs.
willakins