
Conventional Commit
- 889 installs
- 15 repo stars
- Updated August 2, 2026
- marcelorodrigo/agent-skills
conventional-commit is an agent skill that generates standardized git commit messages and branch names following the Conventional Commits specification for developers maintaining clean history.
About
conventional-commit is a marcelorodrigo agent-skills package (version 1.0.0, MIT license) that teaches agents to write Conventional Commits-compliant messages. Before committing, the skill checks the current branch with git branch --show-current and instructs creating a feature branch when on main or master using type/short-description naming aligned with commit types. It covers commit type prefixes, scopes, bodies, and breaking-change footers per the specification. Developers reach for conventional-commit when agents produce vague messages like "fix stuff" and changelog or semantic-release tooling needs parseable history. The skill triggers on commit, git history formatting, or pull request preparation tasks.
- Generates Conventional Commit messages using the exact spec format: type(scope): subject
- Supports 12 standardized commit types including feat, fix, refactor, docs, perf, ci, build, chore, deps, style, revert a
- Enforces branch naming convention matching commit type before allowing commits
- Keeps all commit lines under 100 characters with optional scope, body and footer
- Hard-gate: requires working on a feature branch, never main or master
Conventional Commit by the numbers
- 889 all-time installs (skills.sh)
- +4 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #76 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/marcelorodrigo/agent-skills --skill conventional-commitAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 889 |
|---|---|
| repo stars | ★ 15 |
| Security audit | 3 / 3 scanners passed |
| Last updated | August 2, 2026 |
| Repository | marcelorodrigo/agent-skills ↗ |
How do you write Conventional Commits messages with an agent?
Generate consistent, standardized commit messages that follow the Conventional Commits specification.
Who is it for?
Developers using semantic-release or changelog automation who need agents to emit parseable Conventional Commits on every change.
Skip if: Repositories with custom commit formats unrelated to Conventional Commits or teams that squash all history without caring about message structure.
When should I use this skill?
The user commits code, asks for a commit message, formats git history, or prepares a branch before a pull request.
What you get
Conventional Commits-formatted message with type, scope, body, and correctly named feature branch off main.
- formatted commit message
- feature branch name
By the numbers
- Skill metadata version 1.0.0
Files
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-currentIf 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: <description> 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 availableRevert 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
Related skills
How it compares
Use conventional-commit for spec-compliant messages; use PR-description skills when the deliverable is the pull request body instead of commit text.
FAQ
What specification does conventional-commit follow?
conventional-commit follows the Conventional Commits specification for typed commit messages, optional scopes, bodies, and breaking-change footers, packaged as version 1.0.0 MIT skill.
Does conventional-commit prevent commits on main?
conventional-commit instructs agents to run git branch --show-current and create a type/short-description feature branch when on main or master before committing changes.
Is Conventional Commit safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.