code-commitlisted

# Conventional Commit Skill Create coherent, reviewable commits that follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. Message syntax matters, but the selected changes must tell one clear story too. ## Message Format Every generated commit has a title and body: ``` <type>(<scope>): <imperative title> <1-5 lines describing the change and, when useful, its reason or effect> ``` Use a lowercase scope that identifies the affected component. The title is concise, imperative, lowercase, and has no trailing period. The body is concrete: explain the behavior, motivation, or important implementation decision rather than restating the title. | Type | Use for | |------|---------| | `feat` | New user-facing capability | | `fix` | Corrected behavior | | `docs` | Documentation only | | `style` | Formatting only | | `refactor` | Restructuring without behavior change | | `test` | Tests only | | `chore` | Maintenance or tooling | | `perf` | Performance improvement | | `ci` | Continuous integration configuration | | `build` | Build system or dependencies | | `revert` | Reverting a prior commit | Breaking changes may use `!` after the type or scope, a `BREAKING CHANGE:` footer, or both. Include issue footers such as `Closes #123` only when the issue is known. ## Create a Commit When the user asks to commit, first inspect the complete worktree: 1. Run `git status --short`. 2. Read both `git diff --cached` and `git diff` so pre-staged work is not mi