Menu
Enforce commit message convention for features, fixes, chores, and docs
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Reference guide for building a Rust clean-architecture backend with Axum, SeaORM, Argon2, JWT, and sea-orm-migration. Use when scaffolding a new Rust service, adding a feature (domain + use-case + repository + handler), or reviewing Rust code against the axum-clean-architecture reference layout.
Enforce Kana monorepo best practices when writing FastAPI (Python) + TanStack (React/TypeScript) code inside a moon-managed pnpm/uv workspace
Best-practices guide for building a moon + pnpm TypeScript monorepo with a Hono/oRPC/Drizzle/better-auth backend and a TanStack Router SPA frontend. Use when scaffolding a new full-stack app, adding a feature (use-case + router + route + UI), or reviewing code against the saas-boilerplate reference layout.
Enforce pre-commit/pre-push hooks, lint-staged checks, and semver version bump on every push
Apply Robert C. Martin's (Uncle Bob's) Clean Code, Clean Architecture, and Clean Craftsmanship principles when writing, reviewing, or refactoring code. Use this skill whenever the user asks to write new code of non-trivial size (functions, classes, modules, services), refactor or clean up existing code, review code for quality, design a module or system boundary, write tests, or whenever the user mentions "clean code," "clean architecture," "SOLID," "SRP," "OCP," "LSP," "ISP," "DIP," "TDD," "refactor," "code smells," "code review," "Uncle Bob," or "Robert Martin." Also engage proactively when producing or examining code that shows poor naming, long functions (>20 lines), deep nesting, unclear abstractions, duplicated logic, switch/if-else chains that should be polymorphic, missing tests, leaky boundaries, or frameworks bleeding into business logic — even if the user did not explicitly ask for a cleanup. Do not wait for magic words; if you are writing or touching code, consult this skill.
| name | commit-convention |
| description | Enforce commit message convention for features, fixes, chores, and docs |
All commit messages MUST follow one of the four formats below. The type is lowercase. The subject is imperative, lowercase, and has no trailing period.
feat — New feature or new behaviourScope is required: the name of the affected module.
feat(<module>): <what changed or what feature>
Examples:
feat(auth): add google oauth sign-in
feat(billing): support multi-currency invoices
feat(users): allow avatar upload
fix — Bug fix or issue resolutionScope is required: the name of the affected module.
fix(<module>): <what was fixed>
Examples:
fix(auth): prevent token refresh race condition
fix(cart): correct total when discount is zero
fix(api): return 404 instead of 500 on missing user
chore — Housekeeping, dependency bumps, config changesNo scope.
chore: <what was adjusted>
Examples:
chore: adjust package.json version (bump)
chore: update eslint config
chore: remove unused devDependency
docs — Documentation onlyNo scope.
docs: <what changed>
Examples:
docs: add setup guide to README
docs: document commit convention
docs: clarify env variable defaults
feat, fix, chore, docs).feat and fix REQUIRE a module scope in parentheses.chore and docs do NOT use a scope.| Situation | Type |
|---|---|
| New user-facing capability | feat |
| New internal behaviour | feat |
| Something was broken, now works | fix |
| Version bump in package.json | chore |
| Lockfile regeneration, config tweak | chore |
| README, guide, or comment-only change | docs |