What is the Conventional Commits specification?

Conventional Commits is a lightweight convention for commit messages with the shape type(scope): description, an optional body, and optional footers. It makes history readable and lets tools auto-generate changelogs and version bumps.

What commit types are supported?

The builder covers the Angular-derived set used by commitlint and semantic-release: feat, fix, docs, style, refactor, perf, test, build, ci, chore and revert. Each type shows a one-line description of when to use it.

How does it decide the semantic version bump?

A breaking change always means a major bump. A feat means a minor bump, and fix or perf mean a patch. Other types do not trigger a release on their own. The live preview shows the impact as you type.

What is the git commit command it copies?

It builds a git commit command using one -m flag per paragraph, with each paragraph safely single-quoted for POSIX shells. Paste it straight into your terminal to commit the subject, body and footers in one go.

Does it store my commit messages anywhere?

Only in your own browser. The current draft, your recent scopes and your saved history live in localStorage on your device. Nothing is ever uploaded to a server.

Conventional Commit Builder

Q: How do I mark a breaking change?

Tick the breaking change box. The builder adds an exclamation mark after the type or scope and appends a BREAKING CHANGE footer describing what broke and how to migrate, exactly as the spec requires.

A Conventional Commit Builder that turns a few form fields into a perfectly formatted, spec-compliant commit message — the kind that tools like commitlint, semantic-release and changesets expect. It is for developers who want clean, machine-readable Git history without memorising the exact punctuation of the Conventional Commits specification.

How it works

A Conventional Commit has three parts: a header, an optional body, and optional footers. The header follows the pattern type(scope): description — for example feat(auth): add password reset endpoint. The builder lets you pick the type from a labelled grid, type an optional scope, and write the description. As you fill the fields it assembles the message live and shows you exactly what will be committed.

It also lints your message against the conventions in real time: it warns when the subject line runs past 72 characters, when the description starts with a capital letter or ends with a full stop, and when you slip into the past tense (“added”) instead of the recommended imperative mood (“add”). Errors — like a missing description — block the copy buttons so you never ship a malformed header.

Tick breaking change and the builder inserts the ! marker after the type or scope and appends a BREAKING CHANGE: footer, which is what signals a major version bump to release tooling. Below the preview you can attach structured footers such as Refs, Closes or Co-authored-by, and turn on optional gitmoji prefixes. When you are happy, copy the raw message, copy a ready-to-run git commit command with one -m per paragraph, or save the message to a local history you can reload and edit later. Your draft, recent scopes and history are all stored in your browser — nothing is uploaded.

Example

Say you added a new, backwards-incompatible authentication endpoint. You pick feat, set the scope to auth, write the description drop legacy token endpoint, tick breaking change, and describe the migration. The builder produces:

feat(auth)!: drop legacy token endpoint

The /v1/token route is removed in favour of OAuth device flow.

BREAKING CHANGE: clients must migrate to /v2/oauth before upgrading.
Closes: #482

The SemVer indicator shows major, and the “Copy git commit” button hands you a terminal-ready command. Every figure and field is processed in your browser — no commit data leaves your device.