conventional-commit▌
marcelorodrigo/agent-skills · updated Apr 22, 2026
Structured commit message format following the Conventional Commits specification.
- ›Defines 12 commit types (feat, fix, refactor, docs, test, chore, ci, build, perf, style, deps, revert) with clear purposes and semantic versioning correlation
- ›Enforces a required header format with optional scope and body, all lines under 100 characters, subject line capped at 70 characters
- ›Includes guidelines for imperative present-tense language, body content explaining what and why, and support for
Conventional Commit Messages
Follow these conventions when creating commits.
Prerequisites
Before committing, ensure you're working on a feature branch, not the main branch.
# Check current branch
git branch --show-current
If you're on main or master, create a new branch first:
# Create and switch to a new branch
git checkout -b <type>/<short-description>
Branch naming should follow the pattern: <type>/<short-description> where type matches the commit type (e.g., feat/add-user-auth, fix/null-pointer-error, refactor/extract-validation).
Format
<type>(<scope>): <subject>
<body>
<footer>
The header is required. Scope is optional. All lines must stay under 100 characters.
Commit Types
| Type | Purpose |
|---|---|
build |
Build system or CI changes |
chore |
Routine maintenance tasks |
ci |
Continuous integration configuration |
deps |
Dependency updates |
docs |
Documentation changes |
feat |
New feature |
fix |
Bug fix |
perf |
Performance improvement |
refactor |
Code refactoring (no behavior change) |
revert |
Revert a previous commit |
style |
Code style and formatting |
test |
Tests added, updated or improved |
Subject Line Rules
- Use imperative, present tense: "Add feature" not "Added feature"
- Capitalize the first letter
- No period at the end
- Maximum 70 characters
Body Guidelines
- Explain what and why, not how
- Use imperative mood and present tense
- Include motivation for the change
- Contrast with previous behavior when relevant
Conventional Commits
The commit contains the following structural elements, to communicate intent to the consumers of your library:
- fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
- feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
- BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
- types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
- footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format.
Examples
Simple fix
fix(api): Handle null response in user endpoint
The user API could return null for deleted accounts, causing a crash
in the dashboard. Add null check before accessing user properties.
Feature with scope
feat(alerts): Add Slack thread replies for alert updates
When an alert is updated or resolved, post a reply to the original
Slack thread instead of creating a new message. This keeps related
notifications grouped together.
Refactor
refactor: Extract common validation logic to shared module
Move duplicate validation code from three endpoints into a shared
validator class. No behavior change.
Breaking change
feat(api)!: Remove deprecated v1 endpoints
Remove all v1 API endpoints that were deprecated in version 23.1.
Clients should migrate to v2 endpoints.
BREAKING CHANGE: v1 endpoints no longer available
Revert Format
revert: feat(api): Add new endpoint
This reverts commit abc123def456.
Reason: Caused performance regression in production.
Principles
- Each commit should be a single, stable change
- Commits should be independently reviewable
- The repository should be in a working state after each commit
References
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.7★★★★★56 reviews- ★★★★★Emma Bansal· Dec 24, 2024
conventional-commit has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Xiao Chawla· Dec 24, 2024
conventional-commit reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Li Huang· Dec 24, 2024
Useful defaults in conventional-commit — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Kofi Desai· Dec 8, 2024
We added conventional-commit from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Shikha Mishra· Dec 4, 2024
I recommend conventional-commit for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Aditi Sanchez· Dec 4, 2024
Solid pick for teams standardizing on skills: conventional-commit is focused, and the summary matches what you get after install.
- ★★★★★Amina Gupta· Nov 27, 2024
Useful defaults in conventional-commit — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Rahul Santra· Nov 23, 2024
Solid pick for teams standardizing on skills: conventional-commit is focused, and the summary matches what you get after install.
- ★★★★★Li Chen· Nov 23, 2024
I recommend conventional-commit for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Henry Smith· Nov 15, 2024
Registry listing for conventional-commit matched our evaluation — installs cleanly and behaves as described in the markdown.
showing 1-10 of 56