Conventional Commit Message skill for agents
Conventional Commit Message
A skill that writes Conventional Commits messages: picks the type by release impact, the scope by package and checks the text with commitlint
- 8,525 ★ on the repository
- Last commit
- ISC
Minimal access
Why this level
- The skill is made of text rules and runs nothing itself, while the agent may read git and local config files
- Validation runs the local commitlint, which reads the message text and the project configuration
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/conventional-commit-messageDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewMinimal accessThe tool runs nothing and makes no network calls.
- The skill is made of text rules and runs nothing itself, while the agent may read git and local config files
- Validation runs the local commitlint, which reads the message text and the project configuration
This is third-party code. Review the repository files before installing.
What it does
The conventional-commit-message skill sits in the skills folder of the conventional-changelog repository, home of tools for releases and changelogs. When you ask an agent to write, amend or review a commit message, it first looks at what changed: `git diff --staged --name-only`, then `git diff --name-only`, and a search for commitlint config files and `package.json`. If the project uses commitlint, the agent reads its config to learn allowed types, scopes, casing and length. The type is chosen by release impact, not by file path. New user-facing behavior gets `feat` and bumps the minor version, a correction gets `fix` or `perf`, while `docs`, `refactor`, `test`, `build`, `ci` and `chore` are hidden from the changelog and do not bump the version. The skill warns separately: a metadata or config change that raises the minimum Node.js version, removes exports or tightens dependencies counts as visible and needs `!` with a `BREAKING CHANGE` footer. In a monorepo the scope is the package name, and for a shared reason several scopes can be listed with commas. The skill validates the finished message with the local `./node_modules/.bin/commitlint`, feeding the text through `echo` or `printf`. If it fails, the agent fixes the type, scope, casing or length and tries again. By default the user gets only the message back, and when release impact is uncertain, two options with the consequences explained.
Who it is for. For developers and maintainers who drive changelogs and versions from Conventional Commits and want an agent to produce commit messages without format fixes.
Good fit when
- The project builds its changelog and version numbers from commits, and the agent's message has to land in the right section
- The repository uses commitlint and the message must be checked before commit against the real rules
- A monorepo change touches several packages and you need to pick a scope
- You need to decide how to classify a dependency update or a minimum Node.js version change: a chore, a fix or a breaking change
- You want an existing message rewritten so it reads like a changelog line
Not a fit when
- The project uses another message format, such as free-form or emoji-based: the skill's rules do not fit
- You need to generate the changelog itself from history: the skill writes messages, while the conventional-changelog packages build the log
- You need automatic version publishing in CI: the repository README names other tools for that
- You write messages by hand following your team's own convention: the skill's rules would be extra
Example request
Look at what is staged and write a Conventional Commits message, then check it with commitlintLimitations
- The skill is aimed at projects using the `conventional-changelog-conventionalcommits` preset and compatible release tooling. In other repositories the set of hidden and visible types may not match the team's rules.
- Validation needs a local commitlint. If it is not in `node_modules`, the skill allows running it through `pnpm`, `npm exec` or `npx`, but only when your environment allows it, and if it cannot run, the agent says so.
- The skill asks git and the file system for data about your changes, including the list of changed files, to choose a scope. The agent sees the staged contents the same way it does in ordinary work on the project.
- The skill only sets rules and commits nothing: making the commit or regenerating the message is up to the user, or the agent at your request.
- The repository has one skill so far, and it covers commit messages only. Changelog generation and version bumping are not part of it.
- The repository is distributed under the ISC license, while the skill's own header says MIT.
How to disable. Delete the conventional-commit-message folder from the agent's skills directory (for example `.claude/skills` in the project or the home folder). The skill changes nothing else in the project: the commitlint config and commit history stay as they were.
FAQ
Which commit type does the skill choose for a dependency update?
A runtime update in `dependencies` counts as `fix`: it changes the published package's dependency graph and should trigger a release even with no code edits. If the update removes support for earlier behavior, `!` and a `BREAKING CHANGE` footer are added. For development tooling such as a linter it takes `build` or a `dev-deps` scope.
How does the skill decide a change is breaking?
It looks for signs in config files, exports and dependencies: a higher minimum runtime or Node.js version, removed or narrowed exports, CLI flags and presets, tighter dependency ranges, changed generated output. The skill's own example: moving to Node.js 22 is written as `feat!: require Node.js 22`.
What if commitlint is not installed locally?
The skill first looks for `./node_modules/.bin/commitlint`, because it uses the version and config installed in the repository. The fallback is `pnpm commitlint`, `npm exec commitlint` or `npx commitlint`, but only when your environment allows running it. If the command is unavailable, the agent says so.
How does the skill format issue references?
For a fix that should close an issue, a footer such as `Fixes #123.` goes at the bottom of the message, and for context without closing, `Refs #123.`. References are added when the work is tied to an issue, report or URL the user named.
How does the skill treat names inside the message text?
Function, option, flag, type and file names in the description go in backticks. Tokens starting with `@`, such as `@types/node`, are wrapped the same way, otherwise GitHub reads them as a user mention and notifies that account.
Discussion
No questions or reviews yet.
Related
SkillsA finalization-discipline skill: the agent describes the accepted result and keeps rejected alternatives out of titles, commits and PRs
skill-creator: skills from OpenAPI, GraphQL and MCP
@asnd/skill-creator
The /skill-creator command turns a link to an OpenAPI spec, GraphQL schema or MCP server into a ready skill with wrappers.
GitHub CLI skills
GitHub CLI skills (gh, gh-skill)
Official GitHub CLI skills: how an agent should call gh correctly and how to manage skills with gh skill
A code review skill across many languages and frameworks: architecture, performance, security, anti-patterns and common bugs
A skill that runs an experiment loop: you set a metric, the agent tries one change at a time on its own branch and keeps only improvements
The /improve skill: a strong model audits a repository and writes self-contained fix plans, and you hand the execution to a cheaper model
README in short
The repository's front page opens by describing the project as a changelog generator from git data and recommends three external tools for automating versioning and releases. The skills section names one skill and gives two install commands, for pnpm and npm. Next come a list of key ecosystem modules, including commitlint and commitizen, and a table of all packages in the repository. A separate page on the project site explains what the skill does and what gets installed into the agent's skills folder.
README badge
Original SKILL.md
---
name: conventional-commit-message
description: Generate high-quality Conventional Commit messages for repositories using conventional-changelog-conventionalcommits.
license: MIT
compatibility:
- Claude Code
- Codex
- Cursor
- Gemini CLI
- GitHub Copilot
- Windsurf
- Cline
- Roo Code
- Goose
- Continue
- OpenCode
- Amp
- universal
metadata:
author: dangreen
tags:
- conventional-commits
- conventional-changelog
- commit-message
- changelog
- release
- monorepo
---
# Conventional Commit Message
Use this skill when writing, amending, reviewing, or suggesting commit messages for repositories that use the `conventional-changelog-conventionalcommits` preset or compatible Conventional Commits release tooling.
## Commit Shape
Use the Conventional Commits 1.0.0 message structure:
```text
<type>[optional scope][optional !]: <description>
[optional body]
[optional footer(s)]
```