Conventional Commit Builder

Overview

Build a commit message that satisfies the Conventional Commits 1.0 spec by filling in the parts: type, optional scope, short description, optional body, breaking-change note, and footers like Closes #123 or Co-authored-by. The output is copy-paste ready and validated against the official grammar.

It's for teams using automated changelog generators, semantic-release pipelines, or commit linters - anywhere your CI cares about the shape of feat(api): add pagination vs Add pagination. Reach for it when training new contributors, breaking a long history of inconsistent messages, or just making sure your release-please / standard-version run picks the right bump.

How it works

Conventional Commits 1.0 defines a strict header grammar: <type>[(scope)][!]: <description>, where type is feat, fix, docs, style, refactor, perf, test, build, ci, chore, or revert. A ! after the scope (or a BREAKING CHANGE: footer) signals a major-version bump in semantic-release.

The body and footers follow a blank line, with footers parsed as Token: value pairs (per RFC 822-style). The builder emits the canonical 50/72 column convention - 50 for the subject, 72 for body wrap - that's friendly to git log --oneline displays.

Examples

• Minimal feat:

  feat: add password reset endpoint
  

• Scoped fix with footer:

  fix(auth): reject empty bearer tokens
  
  Closes #482
  

• Breaking change (forces a major bump):

  feat(api)!: rename /users to /accounts
  
  BREAKING CHANGE: clients must update their base path.
  

• Multi-line body with co-author:

  refactor(billing): extract invoice formatter
  
  Pulls Stripe-specific formatting out of BillingService so we
  can swap providers without touching the domain layer.
  
  Co-authored-by: Sam Reed <sam@example.com>
  

FAQ

What types should I use?

The 1.0 spec only mandates feat and fix. Most teams adopt the Angular convention's full list (docs, style, refactor, perf, test, build, ci, chore) for clarity.

Does the scope need to be a folder name?

No - scope is any short identifier. Common conventions are the affected package, feature area, or module name. Keep it lowercase and short.

How do I trigger a major-version bump?

Either append ! after the type/scope (feat(api)!:) or include a BREAKING CHANGE: <description> footer. Semantic-release treats either as a major bump.

Can I write Fix(API): with capitals?

The spec is lowercase. Linters like commitlint will reject capitalised types unless you configure exceptions.

Try Conventional Commit Builder