Conventional Commit Workflow
When To Use
- Generating conventional commit messages from staged changes
When NOT To Use
- Full PR preparation: use sanctum:pr-prep
- Amending existing commits: use git directly
Steps
-
Gather context (run in parallel):
git status -sbgit diff --cached --statgit diff --cachedgit log --oneline -5
If nothing is staged, tell the user and stop.
-
Classify: Pick type (
feat,fix,docs,refactor,test,chore,style,perf,ci) and optional scope. -
Draft the message:
- Subject:
<type>(<scope>): <imperative summary>(50 chars max) - Body: What and why, wrapped at 72 chars
- Footer: BREAKING CHANGE or issue refs
- Subject:
-
Slop check: reject these words and replace with plain alternatives:
| Reject | Use instead | |--------|-------------| | leverage, utilize | use | | seamless | smooth | | comprehensive | complete | | robust | solid | | facilitate | enable | | streamline | simplify | | optimize | improve | | delve | explore | | multifaceted | varied | | pivotal | key | | intricate | detailed |
Also reject: "it's worth noting", "at its core", "in essence", "a testament to"
-
Write to
./commit_msg.txtand preview.
Rules
- NEVER use
git commit --no-verifyor-n - Write for humans, not to impress
- If pre-commit hooks fail, fix the issues