tomevault-io 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.mdfor full rules and examples.
Workflow
Inspect changes
- Check
git statusandgit diff --cachedto confirm what will be committed. - If changes mix concerns or include formatting noise, ask to split or stage appropriately.
- Check
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.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.