Conventional Commits
When creating a commit message, follow Conventional Commits 1.0.0.
When to use this skill
- The user asks to commit staged or unstaged changes.
- The user asks "write a commit message for this diff".
- The repo has
commitlint,husky, or aCONTRIBUTING.mdmentioning Conventional Commits.
How to use it
- Inspect the change first:
git diff --staged(orgit diffif nothing is staged). Never invent a message without reading the diff. - Pick the type from the actual change, not the file names:
feat— user-visible behavior addedfix— user-visible bug fixedrefactor— behavior-preserving restructuredocs,test,build,ci,chore,style,perf
- Add a scope when the repo already uses them (check
git log --oneline -20for the house style). - Subject line: imperative mood, lowercase after the colon, no trailing period, ≤ 72 chars.
- Body (optional): explain why, wrap at 72. Footer:
BREAKING CHANGE:or issue refs (Closes #123).
Decision tree
- Mixed unrelated changes in one diff → propose splitting into multiple commits instead of one vague
chore. - Change is a revert → use
revert:and reference the reverted SHA. - Unsure between
fixandrefactor→ does an end user observe the difference? Yes =fix, no =refactor.
Done means
git log -1 --format=%s matches ^(feat|fix|refactor|docs|test|build|ci|chore|style|perf|revert)(\(.+\))?!?: .+ and the message honestly describes the diff.
Part of awesome-antigravity-skills. Browse more Agent Skills at orangebot.ai/skills.