conventional-commits

Writes commit messages and PR titles following the Conventional Commits 1.0.0 specification.

Updated May 19, 2026
One-click install
npx skills add https://github.com/Curcolor/CLAUDEMAX --skill conventional-commits-curcolor
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: conventional-commits
Source: https://github.com/Curcolor/CLAUDEMAX/tree/main/skills/conventional-commits
Command: npx skills add https://github.com/Curcolor/CLAUDEMAX --skill conventional-commits-curcolor

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent commit messages break automated versioning, changelogs, and release tooling. This Skill formats every commit message and PR title according to the Conventional Commits 1.0.0 spec so tools like semantic-release and commitlint work correctly. ## Core Features & Use Cases - Spec-compliant formatting: Enforces the <type>[scope][!]: <description> structure with the standard type list (feat, fix, docs, refactor, perf, test, build, ci, chore, revert), imperative mood, and 72-character wrapping. - Breaking change handling: Adds the ! marker and BREAKING CHANGE: footer correctly, plus footers like Closes: and Refs: for issue linking. - Guided workflow: Inspects git diff --staged --stat, picks the right type and scope from repo conventions, and flags changes that should be split into separate commits. - Use Case: After staging a new authentication feature, ask for a commit and receive feat(auth): add Google OAuth provider with a proper body and Closes: #142 footer, ready for semantic-release to bump the minor version. ## Quick Start Ask the assistant to write a commit message for your currently staged changes following the Conventional Commits specification.

Frequently Asked Questions about conventional-commits

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a conventional commit message?

Use the format <type>[optional scope][!]: <description>, such as feat(auth): add Google OAuth provider. The description must be imperative, lowercase, without a trailing period, and the type must come from the standard list like feat, fix, docs, or refactor.

What commit types are allowed in Conventional Commits?

The standard types are feat, fix, docs, style, refactor, perf, test, build, ci, chore, and revert. feat triggers a minor version bump and fix a patch bump in tools like semantic-release, while the others have no version impact.

How do I mark a breaking change in a commit message?

Add an exclamation mark after the type or scope, like feat(api)!: drop /v1 endpoints, and include a BREAKING CHANGE: footer explaining the impact. Either marker forces a major version bump regardless of the commit type.

Does Conventional Commits work with semantic-release and commitlint?

Yes, the format is machine-parseable by design. semantic-release and release-please derive version bumps and changelogs from the types, while commitlint rejects malformed messages in pre-commit hooks.

When should I split changes into multiple commits?

Split when more than one type applies to the staged changes, such as a new feature mixed with an unrelated bug fix. Each commit should describe one primary change so versioning and changelogs stay accurate.