commit

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

1. 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).
2. 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.
3. 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.