Conventional Commits
The Conventional Commits spec
is a standard for writing human- and machine-readable commit messages. It powers
automated changelogs, semantic versioning, and release pipelines.
Format reference
type(scope)!: description
Optional body explains the why.
Footer holds BREAKING CHANGE: and issue refs.
The ! signals a breaking change.
Tips for good commits
Keep the header under 72 characters. Use the imperative mood ("add", not "added").
A well-scoped commit is easier to review, revert, and cherry-pick — especially in
fast-moving monorepos.
Why commit messages are worth the extra minute
Every repo eventually has the "what did this commit even do" moment — usually at 2am, usually during an
incident. A history full of "fix stuff" and "wip" is useless right when you need it most. Conventional
Commits fix that with a small amount of structure: a type, an optional scope, and a description you can
grep. Once your history follows the format, tooling like commitlint and semantic-release can enforce it
and turn it into changelogs and version bumps for free.
How the builder works
It walks you through the parts of a commit in order. Pick one of eleven types — feat,
fix, docs, style, refactor, perf,
test, build, ci, chore, or revert —
then add a scope for the area of the codebase you touched, write a short description, and optionally
add a body explaining why the change exists. Flag it as a breaking change and the tool adds the
! marker and the BREAKING CHANGE: footer for you. Issue references land in
the footer too, so GitHub and Jira can link the commit automatically. You also get a matching branch
name suggestion, which keeps feat/user-auth style naming consistent across the team
without anyone writing a naming policy doc.
Frequently asked questions
Does this use AI to write the message?
No. It's a structured builder — you supply the words, it assembles them into the correct Conventional Commits format. Nothing is generated, so nothing is hallucinated.
Is my commit text sent to a server?
No. Everything happens in your browser. You can draft commits for private code without worrying where the text goes.
When should I use feat versus chore?
If a user or another developer can observe the change in behavior, it's feat (or fix). If it only changes tooling, dependencies, or housekeeping with no visible effect, it's chore or build.
Do I need the body?
Not always. Skip it for obvious one-liners. Write it whenever the reason for the change isn't clear from the diff — the body is where "why" lives, and "why" is the part git can't reconstruct for you later.
// huntermussel
Want to enforce commit conventions and automate releases in your pipeline?
HunterMussel sets up commitlint, semantic-release, and changelog generation so every merge produces a clean, versioned release — automatically.
Explore CI/CD & DevOps Engineering →