conventional-commits
Guide for writing conventional commit messages. Use when committing changes, writing commit messages, or reviewing commit history.
适合你，如果你希望团队提交信息格式统一
npx oh-my-skill add axone-protocol/contracts/conventional-commitscurl -fsSL https://oh-my-skill.com/install.sh | bash -s -- axone-protocol/contracts/conventional-commitsnpx oh-my-skill verify axone-protocol/contracts/conventional-commits怎么用
商店整理自技能原文 · 版本 7a14fd6 · 表述以原文为准Claude 会帮你编写符合 Conventional Commits 格式的提交消息，强制使用 type(scope): verb subject 单行格式，推荐精准的动作动词，避免弱动词，并确保每个提交只包含一个意图。
当你要求写提交消息、审查提交历史，或在提交变更时，Claude 会触发并遵循此规范。
技能原文 SKILL.md
Conventional Commits
Commit Message Format
<type>(<scope>): <verb> <subject>
One line only. No body. No footer (except for breaking changes).
Subject Line Rules
- Imperative mood, present tense
- Short, dense, unambiguous
- Describes the intent, not the implementation
- One line only
- No capitalization at start
- No period at end
Verb Selection
⚠️ Avoid weak verbs:add,remove,change,update,modify
Use precise, action-oriented verbs:
| Verb | Use When | | - | - | | enforce | Adding constraints or rules | | introduce | Bringing in new concepts/APIs | | implement | Building out functionality | | prevent | Blocking undesired behavior | | fix | Correcting bugs | | refactor | Restructuring without behavior change | | clarify | Improving readability/naming | | align | Making consistent with standards | | tighten | Strengthening validation/constraints | | harden | Security or robustness improvements | | validate | Input/state verification | | handle | Managing edge cases | | support | Enabling new use cases | | ensure | Guaranteeing invariants | | document | Documentation work |
Type
| Type | Description | Triggers | | - | - | - | | feat | New feature | Minor version bump | | fix | Bug fix | Patch version bump | | docs | Documentation only | No release | | style | Formatting, whitespace | No release | | refactor | Code restructuring | No release | | perf | Performance improvement | Patch version bump | | test | Adding/updating tests | No release | | build | Build system, dependencies | No release | | ci | CI/CD configuration | No release | | chore | Maintenance tasks | No release |
Scope
- Mandatory when it adds clarity
- Short, meaningful, domain or component oriented
- Use contract names without
axone-prefix:gov,logic - Other examples:
workflow,dependabot,README,make,deps - If unsure, omit it
Examples
See [examples](./references/examples.md) for comprehensive good and bad examples.
Quick reference:
feat(gov): introduce quadratic voting mechanism fix(handlers): prevent overflow in vote counting refactor(state): clarify storage key naming test(gov): validate error paths for unauthorized access build(deps): enforce abstract-sdk 0.26.1
Granularity
Rule: One commit = one intention
| Instead of... | Prefer... | | - | - | | One big mixed commit | Multiple focused commits | | feat: implement X and fix Y | Two separate commits | | Tests bundled with feature | Separate test: commit | | Build changes with feature | Separate build: commit |
What to Avoid
- ❌ Generic messages hiding what changed
- ❌ Explanations or rationale in the message
- ❌ Marketing language or inflated wording
- ❌ Multiple intentions in one commit
- ❌ Vague subjects like "improve", "update", "fix issue"
Breaking Changes
Use ! after type/scope:
feat(msg)!: restructure ExecuteMsg variants refactor(api)!: enforce stricter validation schema
Commit Linting
Commits are validated using commitlint. Ensuring lint passes is mandatory.
Validate locally:
npm i -g @commitlint/cli @commitlint/config-conventional echo "feat(gov): introduce voting mechanism" | commitlint --extends @commitlint/config-conventional