| name | conventional-commits |
| description | Writes git commit messages following the Conventional Commits 1.0.0 spec. Use when committing changes, when the user asks for a commit message, or when a repo enforces commit linting. |
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 a CONTRIBUTING.md mentioning Conventional Commits.
How to use it
- Inspect the change first:
git diff --staged (or git diff if 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 -20 for 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
fix and refactor → 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.
