Conventional Commit Message Builder

Assemble a clean, conventional-commits formatted message: type, optional scope, imperative description, wrapped body, breaking-change footer, and issue reference, with live 50/72 character gauges.

Type

Scope (optional, e.g. api, auth, parser)

Description (imperative mood: "add", "fix", "remove", not "added" or "adds")

Subject line length (aim for 50, hard stop before 72)0 / 50

Body (optional: the "why", wrapped at 72 chars in the output)

Longest body line after wrapping (target 72)0 / 72

This is a breaking change

Issue reference (optional, e.g. #123 or PROJ-456)

Assembled commit message

Type cheat sheet

Type	Use for	SemVer effect
`feat`	A new user-facing feature	MINOR bump
`fix`	A bug fix	PATCH bump
`docs`	Documentation only (README, comments)	none
`style`	Whitespace, formatting, semicolons; no logic change	none
`refactor`	Code restructure that neither fixes a bug nor adds a feature	none
`perf`	A change that improves performance	PATCH bump
`test`	Adding or correcting tests	none
`build`	Build system, packaging, dependency bumps	none
`ci`	CI configuration and pipeline scripts	none
`chore`	Routine maintenance that touches neither src nor tests	none
`revert`	Reverting an earlier commit (reference its hash in the body)	varies
`!` or `BREAKING CHANGE:`	Any type plus an incompatible API change	MAJOR bump

Why bother: conventional commits make history searchable, power automatic changelogs and semantic-release version bumps, and give reviewers instant context. They also help AI pair programmers: tools like GitHub Copilot and other coding assistants write noticeably better commit messages and changelog summaries when your repository already follows this format consistently, because the pattern is right there in the history they read. Spec: type(scope)!: description, blank line, body, blank line, footers.