Conventional Commit
Format every commit and feature branch with Conventional Commits so agents and humans can read history and changelogs.
Overview
Conventional Commit is an agent skill most often used in Ship (also Build and Operate) that formats git commits and branches to the Conventional Commits specification.
Install
npx skills add https://github.com/marcelorodrigo/agent-skills --skill conventional-commitWhat is this skill?
- 11 commit types in spec table (build through test)
- Required header type(scope): subject with optional body and footer
- Branch rule: never commit on main—use <type>/<short-description>
- 100-character line limit on header and body lines
- MIT-licensed skill with explicit when-to-use frontmatter for commits
- 11 documented commit types in the type table
- 100-character maximum per commit message line
Adoption & trust: 802 installs on skills.sh; 10 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You ship fixes and features but commit messages are inconsistent, blocking readable history and automated versioning.
Who is it for?
Solo builders and agents committing daily who want conventional messages without looking up the spec each time.
Skip if: Repos that already enforce commit format via hooks and you only need bypass instructions, or squashed-only workflows with no per-commit messages.
When should I use this skill?
Committing code changes, writing commit messages, or formatting git history per Conventional Commits.
What do I get? / Deliverables
Each commit follows typed headers, sane branch names off main, and optional body/footer text ready for PR review and changelog tooling.
- Conventional commit header with optional body and footer
- Feature branch named <type>/<short-description>
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship review because clean commits matter most when preparing merges and release notes, though you use it throughout delivery. Review covers git hygiene, message structure, and branch naming before PRs and releases—not one-off local experiments on main.
Where it fits
Agent finishes a UI tweak and needs a feat(ui) commit instead of a vague 'updates' message.
You open a PR and squash-prep requires cleanly typed commits for reviewers and release notes.
Production hotfix gets fix(api) with a short body explaining the regression.
Spike branch uses chore/prototype commits so experiments do not pollute main history semantics.
How it compares
Commit-message discipline skill—not an interactive rebase tutor or PR description generator.
Common Questions / FAQ
Who is conventional-commit for?
Indie developers and agent-assisted workflows that need predictable, machine-readable git messages on feature branches.
When should I use conventional-commit?
Before any git commit during Build feature work, when polishing Ship review PRs, or during Operate iterate hotfixes—anytime you write a commit message or branch name.
Is conventional-commit safe to install?
It is documentation-only for git messaging; still review the Security Audits panel on this Prism page before enabling agent git write access.
SKILL.md
READMESKILL.md - Conventional Commit
# Conventional Commit Messages Follow these conventions when creating commits. ## Prerequisites Before committing, ensure you're working on a feature branch, not the main branch. ```bash # Check current branch git branch --show-current ``` If you're on `main` or `master`, create a new branch first: ```bash # 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 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 reviewabl