conventionalcommits

Write Conventional Commits v1.0.0 messages that map to SemVer version bumps.

Updated Sep 9, 2026
One-click install
npx skills add https://github.com/DeepSpaceCartel/skills --skill conventionalcommits-deepspacecartel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: conventionalcommits
Source: https://github.com/DeepSpaceCartel/skills/tree/main/skills/conventionalcommits
Command: npx skills add https://github.com/DeepSpaceCartel/skills --skill conventionalcommits-deepspacecartel

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Commit histories written in freeform prose cannot be parsed by release-automation or changelog-generation tools, forcing maintainers to manually determine version bumps and draft release notes. This Skill provides the Conventional Commits v1.0.0 specification so every commit message follows a machine-readable grammar. ## Core Features & Use Cases - Message Grammar: Defines the type(scope): description structure with optional body and footers, including the ! marker and BREAKING CHANGE footer for breaking changes. - Type Vocabulary: Documents the spec-mandated types (fix, feat) and the widely-used conventional set (build, chore, ci, docs, perf, refactor, revert, style, test). - SemVer Mapping: Explains how fix maps to PATCH, feat to MINOR, and ! or BREAKING CHANGE to MAJOR, enabling automated version calculation from commit history. - Use Case: When preparing a release, review the commit history and write messages like feat(auth): add OAuth2 refresh-token support so tooling can compute the next version number and draft a changelog entry automatically. ## Quick Start Write a Conventional Commits message for my staged changes that adds a new export feature to the reporting module.

Frequently Asked Questions about conventionalcommits

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

FAQPage Schema
How do I write a Conventional Commits message?▼

Use the format `type(scope): description`, such as `feat(auth): add OAuth2 refresh-token support`. The description must immediately follow the colon on the same line and read as a present-tense instruction like "add X", not "added X".

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

Either append `!` before the colon, like `feat!: remove support for Node 16`, or add a `BREAKING CHANGE:` footer describing what breaks. The footer token must be uppercase, and it should state the concrete thing that breaks, such as a changed signature or removed flag.

Which commit types trigger a SemVer version bump?▼

Only `fix` maps to PATCH and `feat` maps to MINOR per the spec. A `!` marker or `BREAKING CHANGE` footer on any type forces a MAJOR bump. Other types like `docs`, `chore`, or `refactor` do not bump the version on their own.

What commit types are allowed in Conventional Commits?▼

Only `fix` and `feat` carry spec-mandated meaning. The widely-used conventional set also includes `build`, `chore`, `ci`, `docs`, `perf`, `refactor`, `revert`, `style`, and `test`, which are convention rather than requirement.

Does Conventional Commits enforce one change per commit?▼

No, the spec only constrains the commit message format, not commit granularity. Keeping one logical change per commit is a separate good practice that the specification does not itself enforce.