Pull Request Guidelines
If the task is only staging, splitting, or committing local changes, use git. If the task is issue triage or public issue replies, use github-issues. The writing-voice rules govern the prose in any body you write.
Default Standard
A PR body is a durable explanation of the change, not a reviewer-only checklist. Write the lightest body that still makes sense after merge. Open with why the change matters, then weave in what changed with the examples a reader needs to trust it.
Pick A Body Shape
Match the change to a shape, then open that shape's section in references/body-patterns.md:
| Change |
Shape |
Body in one line |
| Narrow bug or UI fix |
Focused fix |
Two or three paragraphs, no headings |
| New or changed public surface |
API or feature guide |
Smallest call site first, concept headings allowed |
| Composition change, stable behavior |
Refactor or architecture guide |
Old shape, new shape, ownership decision |
| Versioned release or migration |
Release notes |
Version heading, contents, breaking section |
When unsure, default to the focused fix and add structure only when a reader would be lost without it.
Hard Rules
- Do not include
## Summary, ## Changes, ## Testing, ## Test Plan, or ## Verification sections unless the user explicitly asks.
- Report commands run, tests run, and verification gaps in the chat final response, not the PR body.
- Do not list changed files. The diff tab already does that.
- Do not include AI or tool attribution.
- PR titles use the same conventional commit format as commits.
- Include code examples for public API, CLI, HTTP, config, or type-signature changes.
- Name breaking changes with old and new examples.
- Add a
## Changelog section only for feat: and fix: PRs with user-visible changes.
References
Load these on demand:
- Body shapes, openers, headings, framing patterns, and what to avoid: references/body-patterns.md.
- Diagram catalog (composition trees, before/after, journeys, flow, comparison tables) with when to use each: references/visual-patterns.md.
- A full worked body to copy a structure from before drafting your own: references/examples.md.
- Changelog entries for
feat: or fix: PRs: references/changelog-entries.md.
- Issue linking, username verification, CODEOWNERS, and merge strategy: references/github-pr-operations.md.
1---2name: pull-request3description: Draft and review Epicenter pull request titles and bodies, including changelog and merge details. Use when creating a PR or editing its text, not for local commits, branches, or issue replies.4---56# Pull Request Guidelines78If the task is only staging, splitting, or committing local changes, use [git](../git/SKILL.md). If the task is issue triage or public issue replies, use [github-issues](../github-issues/SKILL.md). The [writing-voice](../writing-voice/SKILL.md) rules govern the prose in any body you write.910## Default Standard1112A PR body is a durable explanation of the change, not a reviewer-only checklist. Write the lightest body that still makes sense after merge. Open with why the change matters, then weave in what changed with the examples a reader needs to trust it.1314## Pick A Body Shape1516Match the change to a shape, then open that shape's section in [references/body-patterns.md](references/body-patterns.md):1718| Change | Shape | Body in one line |19| --- | --- | --- |20| Narrow bug or UI fix | Focused fix | Two or three paragraphs, no headings |21| New or changed public surface | API or feature guide | Smallest call site first, concept headings allowed |22| Composition change, stable behavior | Refactor or architecture guide | Old shape, new shape, ownership decision |23| Versioned release or migration | Release notes | Version heading, contents, breaking section |2425When unsure, default to the focused fix and add structure only when a reader would be lost without it.2627## Hard Rules2829- Do not include `## Summary`, `## Changes`, `## Testing`, `## Test Plan`, or `## Verification` sections unless the user explicitly asks.30- Report commands run, tests run, and verification gaps in the chat final response, not the PR body.31- Do not list changed files. The diff tab already does that.32- Do not include AI or tool attribution.33- PR titles use the same conventional commit format as commits.34- Include code examples for public API, CLI, HTTP, config, or type-signature changes.35- Name breaking changes with old and new examples.36- Add a `## Changelog` section only for `feat:` and `fix:` PRs with user-visible changes.3738## References3940Load these on demand:4142- Body shapes, openers, headings, framing patterns, and what to avoid: [references/body-patterns.md](references/body-patterns.md).43- Diagram catalog (composition trees, before/after, journeys, flow, comparison tables) with when to use each: [references/visual-patterns.md](references/visual-patterns.md).44- A full worked body to copy a structure from before drafting your own: [references/examples.md](references/examples.md).45- Changelog entries for `feat:` or `fix:` PRs: [references/changelog-entries.md](references/changelog-entries.md).46- Issue linking, username verification, CODEOWNERS, and merge strategy: [references/github-pr-operations.md](references/github-pr-operations.md).
epicenterhq