Conventions
The canonical `type:` scheme shared by issue labels, branch names, and commit message prefixes. Use when labeling an issue, naming a branch, or writing a commit message.From its SKILL.md
npx -y skills add kavo-labs/kavo --skill conventionsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 13 stars13 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.
SKILL.md
1.8 KB, as published. Nobody here has run it
Commit and branch conventions
One type vocabulary is shared across three surfaces in this repo — an
issue's label, its branch prefix, and the Conventional Commit prefix used for
work on it:
| Type | Meaning | Issue label |
|---|---|---|
feat | New capability | type:feat |
fix | Bug fix | type:fix |
chore | Tooling, deps, housekeeping | type:chore |
test | Test coverage work | type:test |
docs | Documentation | type:docs |
refactor | Code restructuring, no behavior change | type:refactor |
perf | Performance improvements | type:perf |
ci | CI/build pipeline changes | type:ci |
Creating a branch from an issue
An issue's type: label is also its branch prefix. Off an up-to-date main:
git checkout main && git pull --ff-only
git checkout -b <type>/<issue-number>-<short-slug>
If the issue has no type: label, ask the user which one applies before
branching; do not guess.
Writing commit messages
Commits follow Conventional Commits using the same type vocabulary:
<type>(<scope>): <subject> (e.g. feat(core): add cursor pagination), scope
optional but preferred when the change is package-scoped. Subject line under
~72 chars, imperative mood. Add a short body only when the "why" isn't
obvious.