Conventional Commit Generator

Header: "fix(api): handle an empty request body".

How it works

• Joined the type, the optional `(scope)` and the `!` breaking marker into the header.
• Added the description after `: `.
• Appended the body and a `BREAKING CHANGE:` footer as separate blank-line-separated paragraphs when present.

• Conventional Commits 1.0.0: the type and description are mandatory; the scope and a `!` are optional; a breaking change is signalled by `!` and/or a `BREAKING CHANGE:` footer.
• The description should be imperative and lower-case, without a trailing period, so generators and changelogs parse it correctly.

Methodology

1. Validate the type against the Conventional Commits type set and the description against the no-trailing-period rule.
2. Assemble the header as `type(scope)!: description`.
3. Join the optional body and the `BREAKING CHANGE:` footer with blank lines.

Usage

1. Pick a commit type and optionally enter a scope.
2. Enter a short, imperative description.
3. Optionally add a body and, for a breaking change, tick the marker and describe it.
4. Copy the generated message.

Examples

These are examples, not current values: they use fixed inputs, while the interactive tool computes live results in your browser.

Fix with a scope

{
  "type": "fix",
  "scope": "api",
  "description": "handle an empty request body",
  "body": "Return 400 instead of throwing when the body is absent.",
  "breaking": false,
  "breakingNote": ""
}

Feature with a breaking change

{
  "type": "feat",
  "scope": "",
  "description": "drop support for Node 16",
  "body": "",
  "breaking": true,
  "breakingNote": "Node 18 is now the minimum supported version."
}

Docs with no scope

{
  "type": "docs",
  "scope": "",
  "description": "document the retry policy",
  "body": "",
  "breaking": false,
  "breakingNote": ""
}

Limitations

Why the format matters

Conventional Commits gives each message a machine-readable header: `type(scope): description`. Tools such as semantic-release, changelog generators and commit linters read that header to decide the next version and to group entries.

The `!` and the `BREAKING CHANGE:` footer are the two conventions that signal an incompatible change; use them together so both humans and tools see the break.