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

1. 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.

1. 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.

1. Pick an optional scope (the area touched, e.g. auth, api, orders).
2. Write the subject: imperative mood, lowercase start, no trailing period,

≤ 72 chars (≤ 50 preferred). "add", "fix", "remove" — not "added"/"fixes".

1. Write the body (wrap ~72 cols): explain why the change is needed and

any context a reviewer needs — not a restatement of the diff.

1. Add footers when relevant: BREAKING CHANGE: <description> for any

incompatible change (or ! after the type/scope), and issue refs like Refs: #123 / Closes #123.

1. Assemble the PR description from the template in the cheatsheet:

Summary (why), Changes (bullets), Test plan (checklist), and linked issues.

1. 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.