| name | commit |
| description | Write a Conventional Commits message from the actual staged diff, then commit. Use when the user asks to commit, write a commit message, or save changes. |
commit
Produce a precise commit message grounded in the real staged changes, then create
the commit. Never invent changes the diff does not show.
Steps
- Inspect what is staged:
git status --short to see staged vs unstaged.git diff --cached to read the actual staged change. If nothing is staged,
stop and ask whether to git add first (do not stage silently).
- Derive the message from the diff only:
- type:
feat, fix, refactor, docs, test, chore, perf,
build, ci, or style - chosen from what the diff does.
- scope (optional): the module/area touched, e.g.
feat(installer): ....
- subject: imperative mood, <= 72 chars, no trailing period.
- body (when the change is non-trivial): what changed and why, wrapped at
~72 cols. Reference issues if the user mentions them.
- Mark a breaking change with
! after the type/scope and a
BREAKING CHANGE: footer.
- Show the proposed message and commit with it.
Rules
- One logical change per commit. If the staged diff spans unrelated concerns, say
so and suggest splitting.
- Subject describes the effect, not the file list ("add retry to the API client",
not "edit client.go").
- Match the repository's existing commit style if it clearly differs from
Conventional Commits.
- Do not add co-author or tool attribution unless the project asks for it.
Example
feat(api): retry idempotent requests on 5xx
Wrap GET and PUT calls in an exponential-backoff retry (3 attempts, full
jitter). Non-idempotent verbs are left untouched so retries never double-write.
