Git Commit Assistant
Quick start
-
Review staged changes and ensure they cover a single concern.
-
Choose <type>(optional-scope) and write an imperative 50-72 character summary.
-
Add body for why/decisions/trade-offs; footers for breaking changes or issue references.
-
Show the message in a fenced code block, ask for approval to commit, then commit only if approved.
-
See references/commit_rules.md for full rules and examples.
Workflow
Inspect changes
-
Check git status and git diff --cached to confirm what will be committed.
-
If changes mix concerns or include formatting noise, ask to split or stage appropriately.
Select type/scope
-
Allowed types: feat, fix, refactor, docs, test, chore, build, ci, perf, style.
-
Scope is optional; keep it short (e.g., api , auth , deps ).
Draft the message
-
Summary: imperative, no trailing period, describe what/why, not implementation detail.
-
Body (only if valuable): why the change was needed, key decisions, trade-offs; wrap to ~72 chars.
-
Footers (when relevant): breaking changes, migration notes, issue references (e.g., Closes #123 ).
Quality gate
-
Message intent must match the staged diff; avoid kitchen-sink commits.
-
Do not mix formatting-only changes with functional work.
-
Avoid noisy summaries like update , fix stuff , changes , wip .
Confirmation and commit
-
Present the message in a fenced code block and ask the user to accept.
-
On approval:
-
Confirm staged changes are correct; surface unstaged items before committing.
-
Run git commit -m "<summary>" with additional -m "<body>" / -m "<footers>" as needed.
-
If the commit fails, report the error and pause for guidance.
-
If the user declines, revise the message or wait for more information.
Reference
- references/commit_rules.md : conventional format, output pattern, quality gate, example output.