| name | pr-description |
| description | Draft concise PR descriptions from branch context. Use when the user asks for /pr-description, a PR description, pull request summary, or branch change summary — especially when API or client contracts may change. |
| disable-model-invocation | true |
PR Description
Focus on the latest changes for the current Git branch, unless the user asks for a different range.
Graduated from Trivelta PAM v2; keep this skill generic across backend/frontend/monorepo work.
Workflow
- Gather branch context: current branch, recent commits, changed files, and diff from the branch base (
main/origin/main unless the user specifies otherwise).
- Separate implementation details from user/API behavior. Keep notes skimmable for reviewers who need a quick implementation read.
- Identify contract changes: routes, methods, params, response shape, status/error codes, auth, pagination/filter/sort, OpenAPI/docs, CLI flags, or E2E cases.
- Include frontend/client notes only when contracts or consumer-facing behavior changed.
- Keep wording concise. Prefer bullets, concrete file/module names, and outcomes over a file-by-file changelog.
Output Template
## Summary
- <Primary outcome or feature/fix>
- <Secondary notable change, if useful>
## Implementation Notes
- <Architecture/flow detail reviewers should know>
- <Data/schema/service behavior worth calling out>
## API Contract / Frontend Notes
- <Only include when contracts or client-facing behavior changed>
- <Call out endpoint/method/params/response/auth/errors/pagination changes>
## Testing
- <Commands run or focused test coverage>
- <Known gaps or commands not run, if any>
Omit API Contract / Frontend Notes when there are no API or client-facing contract changes.
Style
- Lead with what changed and why it matters.
- Keep the summary at 1-3 bullets.
- Keep implementation notes high-signal.
- For frontend notes, write as a quick handoff: exact contract change, migration concern, and anything the client must display/send differently.
- Do not invent tests. If evidence is missing, say what was not run.
- Prefer ASD-STE100 short sentences when writing the final description.
Stacked PRs (gh-stack)
Compose with the hub skill gh-stack. Do not replace stack CLI workflows.
After gh stack submit --auto (or when the user asks to polish stack PR bodies):
- Run
gh stack view --json to list each layer and its PR number.
- For each open PR in the stack (bottom → top):
- Check out that layer (
gh stack checkout <branch-or-pr>).
- Diff against the stack parent (the branch below), not trunk alone — that is the reviewer's layer diff.
- Draft this skill's template for that layer only.
- Apply with
gh pr edit <n> --body-file <path> (and --title if the auto title is weak).
- Keep each description scoped to that layer. Do not restate the whole stack in every PR; one short "Stack context" bullet is enough when helpful.
