Build a Conventional Commit message
Conventional Commits is a format for git messages that turns chaos ("update", "fix stuff", "wip") into a readable history. Every commit starts with a type (`feat`, `fix`, `docs`, `refactor`...), optionally has a scope in parentheses (e.g. `feat(auth):`), then a short description. Easy to read, easy to automate.
This tool assembles a commit message from a form. Pick a type from the bar (11 types), type the short description, optionally add a scope, body, breaking change (adds `!` after the type and a `BREAKING CHANGE:` footer), footers (Closes #123, Co-authored-by, Signed-off-by).
You get the result in three formats: plain text (paste into the editor after `git commit`), shell command (`git commit -m "..."` with escaped quotes), JSON (for bots like semantic-release).
Live validation: short description max 72 characters (hard limit), no trailing period, present tense ("add" not "added").
How to use it
- Pick a commit type in the top bar. feat (new feature), fix (bug fix), docs (documentation), refactor (code change with no behavior change), perf (performance), test, build, ci, chore (small cleanup), revert, style (formatting).
- Scope (optional), what part of the codebase the commit touches, e.g. `auth`, `api`, `ui`. Click a preset chip or type your own. It appears in parentheses: `feat(auth): ...`.
- Short description, one line, max 72 characters, no trailing period, present tense ("add login flow", not "added login flow"). The counter shows the length, warns when over the limit and when it spots past tense.
- Breaking change (Switch), turn on if this commit breaks backward compatibility (API change, removed feature, semantics change). The generator adds `!` after the type (`feat!:`) and a `BREAKING CHANGE: description` footer.
- Body (optional), the details. Write why here (context, motivation), not what (the diff already shows that).
- Footers (optional), add rows with buttons: Closes #123 (closes an issue), Refs #456 (related issue, does not close), Co-authored-by (a second author, e.g. after pair programming), Signed-off-by (DCO, Developer Certificate of Origin, required by projects like the Linux kernel), Reviewed-by, Custom (your own key).
- Pick the output format (Plain / Shell / JSON) and copy. Plain goes into the git editor after `git commit`. Shell goes straight into the terminal. JSON feeds a CI bot or changelog generator.
When this is useful
Concrete situations where Conventional Commits changes the quality of a project:
- Automatic releases. semantic-release or release-please analyse the commits since the last release. feat → bump minor (1.4.0 → 1.5.0). fix → bump patch (1.4.0 → 1.4.1). BREAKING CHANGE → bump major (1.4.0 → 2.0.0). Zero manual work.
- Automatic CHANGELOG.md. After a release the tool generates a "What's new in 1.5.0" section, grouped into "Features", "Bug Fixes", "Performance Improvements". Each line links to the commit. You can also do this by hand with our changelog generator.
- Readable git history. `git log --oneline` shows "feat(auth): add magic link login", "fix(api): handle empty body", "docs: clarify install steps". Not "update", "fix", "wip". Every new teammate understands the history at a glance.
- Faster code review. The reviewer sees the prefix and knows whether it is a feat (look closely at tests, edge cases) or a refactor (look closely, behavior should not have changed). They can filter PRs by type.
- PR templates and CI checks. Many projects (Vercel, Astro, Next.js) have CI validation that the PR title is a Conventional Commit. Generate a valid title here so the bot does not bounce you.
- Working in a monorepo. The scope in the commit (`feat(web):`, `fix(api):`) tells you which package/app the change is in. Changelogs group them separately.
After producing a batch of commits, use the CHANGELOG generator which groups commits by type. And if you are building a project README, the "Contributing" section is a good place to mention Conventional Commits, the README builder has a ready template.