conventional-commits

Generate conventional commit messages conforming to commitlint rules.

21|2|Updated Nov 5, 2023
One-click install
npx skills add https://github.com/sgcarstrends/sgcarstrends --skill conventional-commits-sgcarstrends
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: conventional-commits
Source: https://github.com/sgcarstrends/sgcarstrends/tree/main/.claude/skills/conventional-commits
Command: npx skills add https://github.com/sgcarstrends/sgcarstrends --skill conventional-commits-sgcarstrends

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you create proper conventional commit messages for semantic versioning, ensuring consistency across the codebase.

Core Features & Use Cases

  • Commit Formats: Enforce <type>(<scope>): <subject> with optional body and footer.
  • Scopes & Types: Predefined scopes (api, web, database, etc.) and types (feat, fix, chore, docs, etc.).
  • Quality & Planning: Plan version bumps and document breaking changes with footers.

Quick Start

Create a commit like: git commit -m "feat(api): add COE data endpoint" or "fix(web): resolve UI bug".

Frequently Asked Questions about conventional-commits

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

FAQPage Schema
How do I write conventional commits for semantic versioning?

Conventional commits follow the format <type>(<scope>): <subject> with optional body and footer. Types include feat, fix, chore, docs, and refactor; scopes specify areas like api, web, database, or utils. This standardized format enables automatic version bumping and consistent project history.

What's the correct format for commit messages with breaking changes?

Mark breaking changes in the footer using BREAKING CHANGE: description, or add ! after the scope like feat(api)!: subject. This signals major version increments in semantic versioning and ensures downstream tools and developers recognize incompatible updates.

Can I use conventional commits across different project types?

Yes. Conventional commits work across any project using Git and semantic versioning. Define your scopes (api, web, database, utils, etc.) to match your architecture, then apply the same type and formatting rules regardless of language or framework.

How do conventional commits relate to commitlint validation?

Conventional commits generate messages that conform to commitlint rules, an automated linter for Git commits. Commitlint enforces the type, scope, and subject structure, catching formatting errors before they reach version control and keeping commit history clean.

What types and scopes should I define for my commits?

Common types are feat (feature), fix (bug fix), chore (maintenance), docs (documentation), refactor (code restructure), and test (test updates). Scopes reflect your codebase structure: api, web, database, utils, or other modules relevant to your project.

Do I need to include a body or footer in every commit message?

Body and footer are optional. Use body to explain the why behind changes; use footer for issue references (Closes #123) or breaking changes. Type and subject are required; additional elements depend on change complexity and project conventions.