Conventional Commit

Generate commit messages following the Conventional Commits 1.0.0 specification.

Commit Message Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Instructions

When the user asks to commit changes:

1. Analyze the changes by running:

   • git status to see all modified/added/deleted files
   • git diff --staged to see staged changes
   • git diff to see unstaged changes
   • git log -5 --oneline to match the repository's commit style

2. Determine the commit type (REQUIRED):

   Type	Description	SemVer
   feat	New feature	MINOR
   fix	Bug fix	PATCH
   docs	Documentation only	-
   style	Formatting, no code change	-
   refactor	Code change, no feature/fix	-
   perf	Performance improvement	-
   test	Adding/updating tests	-
   build	Build system or dependencies	-
   ci	CI configuration	-
   chore	Other changes	-

3. Identify breaking changes:

   • Append "!" after type/scope for breaking changes: "feat!:" or "feat(api)!:"
   • Add "BREAKING CHANGE:" footer for detailed explanation
   • Breaking changes trigger MAJOR version bump

4. Write the commit message:

   • Description MUST immediately follow the colon and space
   • Description is a short summary in imperative mood
   • Body MUST begin one blank line after description
   • Footers MUST begin one blank line after body

5. Stage and commit:

   • Stage relevant files with git add
   • Create commit with the generated message
   • Show git status after to confirm success
   • DO NOT add any Claude Code references, co-author tags, or "Generated with" footers

Specification Rules

• Type MUST be a noun (feat, fix, etc.)
• Scope MUST be a noun in parentheses describing codebase section
• Description MUST use imperative mood ("add" not "added")
• Body is free-form, may have multiple paragraphs
• Footer token MUST use - instead of spaces (except BREAKING CHANGE)
• BREAKING CHANGE MUST be uppercase
• NEVER include AI-generated markers, Claude Code references, or Co-Authored-By: Claude footers

Examples

Feature with breaking change footer

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Breaking change with !

feat(api)!: send an email to the customer when a product is shipped

Breaking change with exclamation mark and footer

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Simple docs change (no body)

docs: correct spelling of CHANGELOG

Feature with scope

feat(lang): add Polish language

Fix with multi-paragraph body and footers

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Revert commit

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

Footer Formats

Footers follow git trailer format:

• Token: value or Token #value
• Common footers: Refs:, Closes:, Reviewed-by:, Co-authored-by:
• BREAKING CHANGE: description for breaking changes

Interactive Mode

If changes are complex or ambiguous, ask the user:

• Which files to include in the commit
• What type of change this represents
• If there are breaking changes
• If they want to split into multiple commits (encouraged by spec)