| name | pr-style |
| description | This skill should be used when creating or editing a GitHub pull request title or description, regardless of tool (gh CLI, GitHub MCP tools, API). Defines PR title format and body format with Why/What/Notes sections. |
Pull Request Style
Conventions for PR titles and descriptions. These apply no matter how the PR
is created (gh CLI, GitHub MCP tools, API).
General
- Always create draft PRs.
- Assign the PR to me (the author), not to Claude or a bot identity.
- Keep PR titles, descriptions, and comments concise and clear.
- Include only useful information. Remove redundancy and over-explanation.
- Prefer explicitness and clarity over verbosity.
- Express Why/What/Notes content as concise, to-the-point bullet lists. Avoid
prose paragraphs.
- All references to functions, libraries, projects, products must be linked.
- Include a small, illustrative code snippet whenever it conveys the change
faster than prose. This is desired for PRs in general, and especially for bug
fixes: a minimal example of the triggering case (and what went wrong) makes
the problem concrete for reviewers. Keep it short — just enough to convey the
point, not a full reproduction.
- The PR text describes the change only: no "Generated with Claude Code" lines,
no session links or model names.
- In Claude cloud sandbox sessions, the platform appends a "Generated by
Claude Code" footer to the PR body at creation time, outside your control.
After creating a PR, always read it back and, if a footer was appended,
update the PR body to remove it (updates are not re-footered). Also verify
angle-bracket placeholders survived; the platform strips them even inside
code spans.
PR Title Format
Write the title as if the whole PR was squashed into a single commit using
conventional commits. Use imperative mood (e.g., "Add feature" not "Added
feature"). Keep it concise and descriptive.
PR Body Format
## Why?
[Explain the motivation for this change. What problem does it solve?]
## What?
[Describe what was changed. List the key modifications.]
## Notes
[Optional. Additional context, testing notes, or follow-up items.]
Rules:
## Why? - Required. Explain motivation and problem being solved## What? - Required. Describe the changes made## Notes - Optional. Omit entirely if no notes are needed
Try keeping Why? and What? around maximum 3 bullets each. Group related changes
into one bullet rather than enumerating every file touched — reviewers read the
diff for that. But keep each bullet concise and direct. Preferably only one
sentence per bullet point. If it is hard to fit the PR description within these
constraints, it's possible the PR is too large and discuss whether to split it
up.
File References
Use [file:lineno](url) with SHA-pinned URLs:
https://github.com/<owner>/<repo>/blob/<sha>/<path>#L<lineno>
- SHA:
git rev-parse HEAD
- Owner/repo: from
git remote get-url origin (or gh repo view --json nameWithOwner -q .nameWithOwner when gh is available)
Example Body
## Why?
Users need secure access to their accounts. Currently there is no
authentication mechanism in place.
## What?
- Add login/logout endpoints
- Implement JWT token generation
- Add password hashing with bcrypt
- Create auth middleware for protected routes
## Notes
Requires `JWT_SECRET` env variable to be set in production.
