axone-protocol/conventional-commits
.agents/skills/conventional-commits/SKILL.md
Guide for writing conventional commit messages. Use when committing changes, writing commit messages, or reviewing commit history.
$ install --global
skillsauthnpx skillsauth add axone-protocol/contracts conventional-commitsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 3, 2026, 12:06 PM77.4s2 files scanned
SKILL.md
- name:
- conventional-commits
- description:
- Guide for writing conventional commit messages. Use when committing changes, writing commit messages, or reviewing commit history.
- license:
- BSD-3-Clause
- author:
- axone.xyz
- version:
- 1.0
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 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
Related Skills
axone-protocol/rust-testing
development
VerifiedTrustedCommunity
Patterns for Rust testing in Axone CosmWasm contracts. Use when adding unit tests, integration tests, data-driven cases, or coverage-oriented test scenarios.
123SKILL.mdUpdated Apr 3, 2026
axone-protocol/rust-quality-gates
development
VerifiedTrustedCommunity
Repository quality gates for Rust and generated artifacts. Use when validating changes locally or before committing Rust, schema, or documentation updates.
123SKILL.mdUpdated Apr 3, 2026
axone-protocol/rust-contract-domain-modeling
development
VerifiedTrustedCommunity
Domain-driven modeling patterns for Axone contracts. Use when introducing domain concepts, encoding invariants, or deciding boundaries between domain, handlers, services, gateways, queries, and state.
123SKILL.mdUpdated Apr 3, 2026
axone-protocol/doc-generation
development
VerifiedTrustedCommunity
Guide for regenerating Axone contract schemas and rendered Markdown docs. Use when contract APIs or metadata change, when checking generated-doc drift, or when preparing documentation commits.
123SKILL.mdUpdated Apr 3, 2026