Agent-Skills.md

Agent Skills: Pull Request Guidelines

Draft and review durable GitHub pull request titles and bodies for Epicenter. Use when creating a PR, running gh pr create, drafting or editing a PR body, writing changelog entries, linking issues, choosing merge strategy, or reviewing PR text. For local commits and branches use the git skill; for issue replies use github-issues. Never include Testing, Test Plan, or Verification sections in PR bodies unless explicitly requested.

UncategorizedID: epicenterhq/epicenter/pull-request

Repository

epicenterhq/epicenter
EpicenterHQLicense: NOASSERTION
4,687363

Install this agent skill to your local

pnpm dlx add-skill https://github.com/EpicenterHQ/epicenter/tree/HEAD/.agents/skills/pull-request

Skill Files

Browse the full folder contents for pull-request.

Download Skill

Loading file tree…

.agents/skills/pull-request/SKILL.md

Skill Metadata

Name
pull-request
Description
Draft and review durable GitHub pull request titles and bodies for Epicenter. Use when creating a PR, running gh pr create, drafting or editing a PR body, writing changelog entries, linking issues, choosing merge strategy, or reviewing PR text. For local commits and branches use the git skill; for issue replies use github-issues. Never include Testing, Test Plan, or Verification sections in PR bodies unless explicitly requested.

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: