| name | commit-message |
| description | Generate evidence-grounded Conventional Commit messages from staged or unstaged Git diffs, including type, optional scope, breaking-change footers, and split-commit advice. Trigger for commit-message drafting or commit type/scope selection; do not create the commit unless explicitly asked. |
Commit Message
Outcome
Produce a paste-ready Conventional Commit message whose claims are supported by
the actual repository changes.
Workflow
- Read repository guidance that defines commit conventions, then inspect the
relevant diff. Prefer the staged diff when staged changes exist or the user
says the commit is ready; otherwise inspect the unstaged diff and state the
scope used.
- Identify the primary intent, not merely the largest changed file. If the diff
mixes independent intents, recommend the smallest sensible commit split.
- Choose the most specific type:
feat, fix, docs, style, refactor,
perf, test, build, ci, chore, or revert.
- Add a scope only when one stable module, package, or domain clearly owns the
change.
- Write an imperative subject with no trailing period and keep it under 72
characters when practical. Follow repository language conventions; default
to English only when no convention or user preference is available.
- Add a body only when the reason, behavior change, migration note, or split
rationale would help a future reader.
- Add
BREAKING CHANGE: and issue footers only when the diff or supplied
context supports them.
Output
When the user asks only for the commit message, output only the final commit message.
When the user asks for help choosing, include:
- Selected type and scope
- Split-commit concerns
- Final commit message
Completion Check
- Every subject/body claim is traceable to the inspected diff or supplied issue.
- The type describes intent, the scope is not guessed, and no issue ID or
breaking change is invented.
- Do not stage, commit, amend, or push unless the user explicitly requests it.
