Conventional Commit & PR
What this does
Reads a diff and produces (a) one or more Conventional Commit messages —
correct type(scope): subject line, a body explaining the why, and a
BREAKING CHANGE: footer when relevant — and (b) a clean pull-request
description (Summary, Changes, Test plan checklist, linked issues). Well-formed
Conventional Commits also drive automated semver bumps and changelogs.
When to use it
- Committing staged/unstaged changes and you want a spec-correct message.
- Splitting a mixed working tree into logically separate commits.
- Writing a PR description from the branch's full set of commits/changes.
How to use it
- Inspect the changes:
git status, git diff (unstaged) and
git diff --staged (staged). For a PR, also review the whole branch:
git log <base>..HEAD and git diff <base>...HEAD.
- Determine the type from the dominant change (see the spec summary in
references/cheatsheet.md):
feat · fix · docs · refactor · test · chore · perf ·
build · ci. If the diff mixes concerns, recommend splitting into
separate commits — one type per commit.
- Pick an optional scope (the area touched, e.g.
auth, api, orders).
- Write the subject: imperative mood, lowercase start, no trailing period,
≤ 72 chars (≤ 50 preferred). "add", "fix", "remove" — not "added"/"fixes".
- Write the body (wrap ~72 cols): explain why the change is needed and
any context a reviewer needs — not a restatement of the diff.
- Add footers when relevant:
BREAKING CHANGE: <description> for any
incompatible change (or ! after the type/scope), and issue refs like
Refs: #123 / Closes #123.
- Assemble the PR description from the template in the cheatsheet:
Summary (why), Changes (bullets), Test plan (checklist), and linked issues.
- Present the final commit message(s) and PR body as copy-paste blocks. Only
run
git commit / open the PR if the user explicitly asks.
Inputs
- The working-tree diff (staged and/or unstaged) or the branch's diff vs. base.
- Optional: linked issue IDs, the target base branch, and any
repo-specific commit/scope conventions (check the recent
git log style).
Output
- One or more Conventional Commit messages (subject + body + footers).
- A PR description: Summary, Changes, Test plan checklist, linked issues.
Notes & constraints
- Match the repo's existing style — read recent
git log for scope naming
and conventions before drafting.
- One logical change per commit; recommend splitting when the diff spans
unrelated concerns.
- A breaking change requires either
! (e.g. feat(api)!: …) or a
BREAKING CHANGE: footer — prefer including the footer so tooling catches it.
- This skill drafts messages; it does not commit, push, amend, or force-push
unless the user explicitly requests it. Never bypass hooks or signing.
- Use forward-slash paths.
1---2name: conventional-commit-pr3description: Turns a code diff into Conventional Commit messages and a high-quality pull-request description. Use when committing staged or unstaged changes, when writing a commit message that follows the Conventional Commits spec, or when assembling a PR description with summary, changes, and a test-plan checklist.4license: MIT5---67# Conventional Commit & PR89## What this does1011Reads a diff and produces (a) one or more Conventional Commit messages —12correct `type(scope): subject` line, a body explaining the *why*, and a13`BREAKING CHANGE:` footer when relevant — and (b) a clean pull-request14description (Summary, Changes, Test plan checklist, linked issues). Well-formed15Conventional Commits also drive automated semver bumps and changelogs.1617## When to use it1819- Committing staged/unstaged changes and you want a spec-correct message.20- Splitting a mixed working tree into logically separate commits.21- Writing a PR description from the branch's full set of commits/changes.2223## How to use it24251. Inspect the changes: `git status`, `git diff` (unstaged) and26 `git diff --staged` (staged). For a PR, also review the whole branch:27 `git log <base>..HEAD` and `git diff <base>...HEAD`.282. Determine the **type** from the dominant change (see the spec summary in29 [`references/cheatsheet.md`](references/cheatsheet.md)):30 `feat` · `fix` · `docs` · `refactor` · `test` · `chore` · `perf` ·31 `build` · `ci`. If the diff mixes concerns, recommend splitting into32 separate commits — one type per commit.333. Pick an optional **scope** (the area touched, e.g. `auth`, `api`, `orders`).344. Write the **subject**: imperative mood, lowercase start, no trailing period,35 ≤ 72 chars (≤ 50 preferred). "add", "fix", "remove" — not "added"/"fixes".365. Write the **body** (wrap ~72 cols): explain *why* the change is needed and37 any context a reviewer needs — not a restatement of the diff.386. Add **footers** when relevant: `BREAKING CHANGE: <description>` for any39 incompatible change (or `!` after the type/scope), and issue refs like40 `Refs: #123` / `Closes #123`.417. Assemble the **PR description** from the template in the cheatsheet:42 Summary (why), Changes (bullets), Test plan (checklist), and linked issues.438. Present the final commit message(s) and PR body as copy-paste blocks. Only44 run `git commit` / open the PR if the user explicitly asks.4546## Inputs4748- The working-tree diff (staged and/or unstaged) or the branch's diff vs. base.49- Optional: linked issue IDs, the target base branch, and any50 repo-specific commit/scope conventions (check the recent `git log` style).5152## Output5354- One or more Conventional Commit messages (subject + body + footers).55- A PR description: Summary, Changes, Test plan checklist, linked issues.5657## Notes & constraints5859- Match the **repo's existing style** — read recent `git log` for scope naming60 and conventions before drafting.61- One logical change per commit; recommend splitting when the diff spans62 unrelated concerns.63- A breaking change requires either `!` (e.g. `feat(api)!: …`) **or** a64 `BREAKING CHANGE:` footer — prefer including the footer so tooling catches it.65- This skill drafts messages; it does not commit, push, amend, or force-push66 unless the user explicitly requests it. Never bypass hooks or signing.67- Use forward-slash paths.
sujanbhuiyan