Conventional commits
Reusable agent skills for automated coding workflows across languages and frameworks.
npx -y skills add CodeByVibes/agents-extras --skill conventional-commitsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 17 days oldThe repository was created 17 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Enforces Conventional Commits 1.0.0 for all git commits in this project. When generating commit messages, always inspect the staged changes, identify the primary logical change, and produce a concise commit following the Conventional Commits specification.
SKILL.md
4.1 KB, as published. Nobody here has run it
Conventional Commits
This skill enforces the Conventional Commits 1.0.0 specification.
Agent behavior
Before writing a commit message:
- Inspect the staged changes or git diff.
- Identify the primary logical change.
- Ignore unrelated formatting or whitespace-only edits.
- Select the most specific commit type.
- Use a scope only when it improves clarity.
- Write an imperative, concise subject.
- Add a body only when additional context provides value.
- Add footers only when applicable.
- Never invent issue numbers, ticket IDs, or breaking changes.
- Never describe changes that are not present in the diff.
Commit format
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Choosing the correct type
| Question | Type |
|---|---|
| Adds new user-visible functionality | feat |
| Fixes incorrect behavior | fix |
| Improves internal structure only | refactor |
| Improves performance | perf |
| Documentation only | docs |
| Formatting/style only | style |
| Tests only | test |
| Build system or dependencies | build |
| CI/CD | ci |
| Maintenance/tooling | chore |
| Reverts a commit | revert |
Header rules
- MUST follow
<type>[scope]: <description> - MUST use imperative mood
- MUST begin the description with a lowercase letter
- MUST NOT exceed 72 characters
- MUST NOT end with a period
- SHOULD include a lowercase scope when it improves clarity
Examples:
feat(api): support image batch uploads
fix(auth): handle expired refresh tokens
docs(readme): update installation guide
refactor(parser): simplify token handling
Body
Include a body only when it explains what changed and why.
Do not invent explanations simply to make the commit longer.
Wrap lines at approximately 72 characters.
Footer
Common footers include:
Closes #42
Refs #104
Co-authored-by: Jane Doe <[email protected]>
Acked-by: John Doe <[email protected]>
BREAKING CHANGE: remove deprecated configuration format
Breaking changes
Signal breaking changes using either:
feat!: remove legacy API
or
BREAKING CHANGE: clients must migrate to the new endpoint
Intent over implementation
Describe the project change, not the coding activity.
Prefer:
feat(api): support image batch uploads
Instead of:
feat: add endpoint
Avoid references to AI, Copilot, ChatGPT, code generation, or tooling unless they are the actual subject of the change.
Atomic commits
Each commit should represent one logical change.
If staged changes contain unrelated work, recommend splitting them into multiple commits rather than creating a generic message.
Never generate
- misc
- update
- changes
- cleanup
- WIP
- work in progress
- final fix
- another fix
- temp
Common examples
feat(ui): add dark mode toggle
fix(cache): prevent stale API responses
refactor(config): split settings into modules
perf(search): cache expensive queries
docs: update installation instructions
build(docker): upgrade Node.js base image
ci(github): run tests on pull requests
chore(deps): bump express to latest version
test(api): cover validation edge cases
revert: revert "feat(auth): add passkey login"
Optional tooling
Commitlint
npm install --save-dev @commitlint/cli @commitlint/config-conventional
Commitizen
pip install commitizen
Example .commitlintrc.yaml:
extends:
- "@commitlint/config-conventional"
rules:
header-max-length: [2, always, 72]
scope-case: [2, always, lower-case]
subject-full-stop: [2, never, "."]