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

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

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

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

4) 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.