Conventional Commits
Guidelines for writing conventional commit messages that follow project standards and trigger automated releases
$ Installieren
git clone https://github.com/vm0-ai/vm0 /tmp/vm0 && cp -r /tmp/vm0/.claude/skills/conventional-commits ~/.claude/skills/vm0// tip: Run this command in your terminal to install the skill
name: Conventional Commits description: Guidelines for writing conventional commit messages that follow project standards and trigger automated releases
Conventional Commits Skill
This skill provides comprehensive guidance on writing conventional commit messages for the vm0 project. All commits must follow the Conventional Commits format to ensure consistent history and enable automated versioning via release-please.
Quick Reference
Format
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Core Rules (STRICT REQUIREMENTS)
- Type must be lowercase -
feat:notFeat:orFEAT: - Description must start with lowercase -
add featurenotAdd feature - No period at the end -
fix user loginnotfix user login. - Keep title under 100 characters - Be concise
- Use imperative mood -
addnotaddedoradds
Common Types (Quick List)
| Type | Purpose | Release? |
|---|---|---|
feat: | New feature | â Minor bump |
fix: | Bug fix | â Patch bump |
docs: | Documentation | â No release |
refactor: | Code refactoring | â No release |
test: | Tests | â No release |
chore: | Build/tools | â No release |
Pro tip: If you want a refactor to trigger a release, use fix: refactor ... instead.
When to Load Additional Context
- Need detailed type definitions? â Read
types.md - Confused about what triggers releases? â Read
release-triggers.md - Want to see good and bad examples? â Read
examples.md
Quick Validation Checklist
Before committing, verify:
- â Type is lowercase and valid
- â Description starts with lowercase
- â No period at the end
- â Under 100 characters
- â Imperative mood (add, fix, update)
- â Accurately describes the "why" not just the "what"
Special Rules for Documentation App
Changes to turbo/apps/docs should use feat(docs): or fix(docs): instead of docs(...):
Why? The turbo/apps/docs directory IS the documentation application. Updates to it are features/fixes to the docs product, not just documentation changes to code. Using feat(docs) or fix(docs) triggers a proper release.
| Change Type | Commit Type | Example |
|---|---|---|
| Add new docs page | feat(docs): | feat(docs): add codex provider documentation |
| Fix broken link | fix(docs): | fix(docs): correct model selection link path |
| Update content | feat(docs): | feat(docs): update quick start instructions |
â docs: add integration guide (won't trigger release)
â
feat(docs): add integration guide (triggers release)
Common Mistakes to Avoid
â Fix: Resolve database connection timeout. (capitalized type, has period)
â added user auth (missing type, wrong tense)
â feat: Add user authentication system with OAuth2... (capitalized description, too long)
â docs: update quick start (for turbo/apps/docs changes - use feat(docs) instead)
â
fix: resolve database connection timeout
â
feat: add user authentication
â
docs(api): update endpoint documentation (for inline code docs, not turbo/apps/docs)
â
feat(docs): add new integration page (for turbo/apps/docs changes)
Integration with Workflow
This skill should be triggered whenever:
- Creating a commit message
- Validating an existing commit message
- Planning what changes should go into a single commit
- Deciding if changes should trigger a release
The commit message should focus on why the change was made, not what was changed (git diff shows the what).
Repository
