Commit — Conventional Commits Generator
When to Trigger
- User wants to commit, save, or check in changes
- User asks to commit after completing a task
- Code changes are ready and user signals completion
Process
Gather context — run in parallel:
git status— see what changedgit diff HEAD— see the actual diffgit log --oneline -5— match existing commit style
Determine type:
Type When featNew feature or capability fixBug fix refactorCode change, no behavior change docsDocumentation only testAdding or correcting tests buildBuild system or dependencies choreMaintenance task ciCI/CD configuration styleFormatting, whitespace perfPerformance improvement Generate message:
type(scope): description- Lowercase type, optional scope
- Imperative mood, no period, under 72 chars
- Breaking changes: append
!before: - Body only when diff needs extra context (max 3 bullet points)
Stage and commit:
git add <specific files>— prefer explicit files overgit add -Agit commit -m "type(scope): description"- Execute automatically — no confirmation needed
Anti-Rationalization
| Excuse | Rebuttal | What to do instead |
|---|---|---|
| "I'll just use a generic message" | Generic messages make git history useless. | Spend 5 seconds analyzing the diff — the type and scope are obvious from the changes. |
| "The user didn't specify a format" | Conventional Commits is the project standard — guard will block non-CC messages anyway. | Always generate CC format. |
| "I'll commit everything together" | Unrelated changes in one commit make bisect and revert impossible. | If changes span multiple concerns, suggest splitting first. |
Evidence Required
-
git statuschecked before staging - Only relevant files staged (not
git add -Ablindly) - Message follows
type(scope): descriptionformat - Type accurately reflects the change (feat ≠ fix ≠ refactor)
Red Flags
- Vague messages: "update code", "fix stuff", "changes"
- Wrong type: using
featfor a bug fix,fixfor a new feature - Staging unrelated files
- Using
--no-verifyto bypass hooks