Menu
Follow project commit conventions when preparing commit messages and creating commits. Use when drafting, reviewing, or validating commit messages.
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
| name | commit-conventions |
| description | Follow project commit conventions when preparing commit messages and creating commits. Use when drafting, reviewing, or validating commit messages. |
All commits must follow the Conventional Commits specification v1.0.0.
Format:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Allowed types:
feat - a new featurefix - a bug fixdocs - documentation changes onlystyle - formatting, missing semicolons, etc; no logic changerefactor - code change that is neither a fix nor a featuretest - adding or updating testschore - build process, tooling, dependency updatesci - CI/CD configuration changesperf - performance improvementsrevert - reverting a previous commitRules:
Pre-commit hooks enforce formatting and required checks automatically. After making a commit, ask whether I would like to push the changes to the upstream branch.
Use this skill when a task depends on a library or dependency and you need reliable documentation or API context. Prefer project instructions, repo-local skills, global skills, installed docs, source, and types first. Use remote docs only when local material is not enough to complete the task safely.
Practical TypeScript defaults for application code: strong but simple typing, clear type modeling, consistent `type` vs `interface` choices, and keeping shared/exported types in nearby `types.ts` files. Use when writing or refactoring TypeScript and deciding how to model data, annotate boundaries, organize type definitions, or improve readability without adding type noise.
Organize or refactor modern TypeScript fullstack applications around module-first boundaries with small readable files, explicit public exports, high cohesion, low coupling, and deliberate placement of shared code and third-party services. Use when designing folder structure, splitting oversized routes or components, separating UI from validation/business logic/data access, deciding where shared code should live, or defining a module's public API.
General React engineering skill for building and refactoring React code in this repository. Use this whenever tasks involve React components, hooks, state management, effects, rendering performance, UI composition, client/server boundaries, or React architecture decisions—even if the user does not explicitly mention "React best practices."