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.

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.

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.

references/commit_rules.md: conventional format, output pattern, quality gate, example output.