git-conventional-commits
Apply when writing commit messages to maintain consistent, readable git history that enables automated changelog generation.
When & Why to Use This Skill
This Claude skill streamlines the Git workflow by enforcing the Conventional Commits specification. It helps developers maintain a consistent, machine-readable commit history by providing structured patterns for types, scopes, and subjects. By standardizing how changes are documented, it directly enables automated semantic versioning and changelog generation, making it an essential tool for professional software engineering and collaborative development.
Use Cases
- Automated Changelog Generation: Enable CI/CD tools to automatically parse commit history and generate comprehensive release notes based on structured types like 'feat' and 'fix'.
- Semantic Versioning (SemVer): Use commit prefixes to automatically determine version bumps (MAJOR, MINOR, or PATCH), ensuring predictable and automated release cycles.
- Team Collaboration and Code Review: Improve repository maintainability by ensuring all team members provide clear, imperative-style context for every code change.
- Project Auditing and Troubleshooting: Quickly filter and search through git history using specific scopes (e.g., 'auth', 'api') to identify when and why specific features or bugs were introduced.
| name | git-conventional-commits |
|---|---|
| description | Apply when writing commit messages to maintain consistent, readable git history that enables automated changelog generation. |
| version | 1.0.0 |
| tokens | ~400 |
| confidence | high |
| - https | //github.com/angular/angular/blob/main/CONTRIBUTING.md#commit |
| last_validated | 2025-01-10 |
| next_review | 2025-01-24 |
| tags | [git, commits, conventions] |
When to Use
Apply when writing commit messages to maintain consistent, readable git history that enables automated changelog generation.
Patterns
Pattern 1: Commit Format
<type>(<scope>): <subject>
[optional body]
[optional footer(s)]
Source: https://www.conventionalcommits.org/en/v1.0.0/
Pattern 2: Types
feat: New feature (MINOR version bump)
fix: Bug fix (PATCH version bump)
docs: Documentation only
style: Formatting, no code change
refactor: Code change, no feature/fix
perf: Performance improvement
test: Adding/fixing tests
chore: Build, tooling, deps
ci: CI/CD changes
Pattern 3: Examples
# Feature
feat(auth): add OAuth2 login with Google
# Bug fix
fix(cart): prevent negative quantity values
# Breaking change (triggers MAJOR version)
feat(api)!: change response format to JSON:API
BREAKING CHANGE: All endpoints now return JSON:API format.
Migration guide: docs/migration-v2.md
# With scope
fix(ui/button): correct hover state color
# Multi-line body
feat(search): add full-text search
Implements Elasticsearch integration for product search.
Includes fuzzy matching and relevance scoring.
Closes #123
Pattern 4: Scope Guidelines
Scope = module, component, or area affected
Good scopes:
- auth, cart, api, db
- ui/button, api/users
- deps, config, ci
No scope when change is broad:
- docs: update README
- chore: update dependencies
Anti-Patterns
- Vague messages - "fix bug", "update code", "WIP"
- Missing type - Always prefix with type
- Too long subject - Keep under 72 chars
- Multiple changes - One logical change per commit
Verification Checklist
- Type prefix present (feat/fix/docs/etc.)
- Subject is imperative ("add" not "added")
- Subject under 72 characters
- Breaking changes marked with
!or footer - One logical change per commit