conventional-commits

Enforce conventional commit formatting for git commit messages.

1|Updated Feb 24, 2026

Search Tags:#git #workflow #changelog #commits #release #commit-message #conventional-commits

Ready to run

npx skills add https://github.com/Danomanic/agent-skill-catalog --skill conventional-commits-danomanic

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: conventional-commits
Source: https://github.com/Danomanic/agent-skill-catalog/tree/main/skills/conventional-commits
Command: npx skills add https://github.com/Danomanic/agent-skill-catalog --skill conventional-commits-danomanic

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Enforces a consistent, machine-parseable commit message format so teams can generate reliable changelogs, automate releases, and make pull request history easier to scan.

Core Features & Use Cases

Standardized Formatting: Defines the type, optional scope, and imperative lowercase description structure for commit headers.
Guidance and Rules: Recommends common types (feat, fix, docs, style, refactor, test, chore, perf, ci), a 72-character header limit, and use of BREAKING CHANGE in footers for breaking API changes.
Use Case: Ideal for developers integrating semantic-release, automated changelog generation, or enforcing commit conventions during code review.

Quick Start

Format each git commit message using the Conventional Commits pattern with a lowercase imperative header and keep the subject line under 72 characters.

Frequently Asked Questions about conventional-commits

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

FAQPage Schema

How do I format git commit messages for automated changelog generation?▼

Git commit messages for automated changelog generation require a standardized format with a type, optional scope, and an imperative lowercase description under 72 characters. This machine-parseable structure enables CI tooling to reliably extract changes and generate release notes.

What is the conventional commits format for structuring git commit headers?▼

The conventional commits format structures git commit headers with a type, optional scope, and an imperative lowercase description. Common types include feat, fix, docs, style, refactor, test, chore, perf, and ci to categorize changes for code review and semantic-release tooling.

How do I indicate breaking changes in commit messages for CI release tooling?▼

To indicate breaking changes in commit messages for CI release tooling, add a BREAKING CHANGE footer below the commit header. This standardized footer alerts automated release pipelines and changelog generators to major API modifications requiring version bumps.

Does semantic-release work with standardized lowercase commit messages?▼

Yes, semantic-release integrates with standardized lowercase commit messages by parsing the commit type and optional scope. This machine-parseable format allows the automated release tooling to determine version bumps and generate changelog entries without manual intervention.

What are the limitations of using conventional commit formatting in code review?▼

Conventional commit formatting in code review requires strict adherence to the type, scope, and 72-character header limit. Developers must manually author imperative lowercase descriptions and correctly append footers for issue references or breaking changes, which can slow down rapid commits.

When do I need machine-parseable commit messages for my git workflow?▼

You need machine-parseable commit messages for your git workflow when integrating automated changelog generation, CI release tooling, or semantic-release. Standardized formatting allows teams to automatically extract release notes and enforce commit conventions during code review.