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.

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

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

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