| name | commit-conventions |
| description | Use when making git commits. Conventional commit format and rules. |
| version | 1.0.0 |
| tags | ["process","git"] |
Commit Conventions
When to Use
∀ git commits.
Format: <type>(<scope>): <summary>
| Type | When |
|---|
feat | New feature ∨ capability |
fix | Bug fix |
refactor | Code restructuring without behavior change |
test | Adding ∨ updating tests |
docs | Documentation changes |
chore | Tooling, config, dependencies |
Scope: feature work → auth/login | module → api/users | general → omit scope
feat(auth/login): add user validation
fix(auth/login): handle null email in signup
test(auth/login): add failing spec for email validation
docs(api): update API documentation
revert(auth/login): undo broken migration
chore: update dependencies
PR Titles
PR titles become the squash-merge commit on main — same conventional-commit rules apply:
| Kind | Format | Example |
|---|
| Slice PR | <type>(S<NN>): <summary> | feat(S03): /pi-rules doctor diagnostic CLI |
| Milestone PR | <type>(M<NN>): <name> | feat(M01): rule discovery expansion |
Always squash-merge — never merge-commit. Merge-commit messages
(Merge pull request #N from …) are non-conventional and break release tooling.
Rules
- Atomic: 1 logical change/commit
- Stage specific files (¬
git add . ¬git add -A)
- ¬commit generated files
- ¬commit secrets (.env, credentials, API keys)
- Imperative summary ("add" ¬"added"), <72 chars
Enforcement
Enforced by lefthook commit-msg hook. ¬bypass with --¬-verify.