git-commitlisted

# Git Commit (Conventional Commits) Produce commit messages that are precise, scannable, and machine-parseable. A good commit message explains *what* changed and *why*, in a form that tools can use to generate changelogs and infer semantic-version bumps automatically. ## Message structure Every message follows this shape: ``` <type>[optional scope][optional !]: <description> [optional body] [optional footer(s)] ``` Only the `<type>:` prefix and `<description>` are required. The blank lines separating description, body, and footers are mandatory when those sections exist — parsers rely on them. ## Workflow Do not write a message from the prompt alone. Read the actual change first, then compose. 1. **Inspect what changed.** Run `git status` to see scope, then `git diff` (unstaged) and `git diff --staged` (staged) to see the substance. The diff tells you the real intent; the user's phrasing may not. 2. **Decompose into independent commits.** Before composing anything, partition the working tree into the smallest set of self-contained, logically-separate commits — one concern each. This is a required step, not an optional cleanup. See *Structuring changes into independent commits* below for how. 3. **Pick the type** from the dominant intent of the change (see table below). 4. **Pick a scope** (optional) — the area of the codebase touched, e.g. `parser`, `auth`, `api`. 5. **Write the description** — imperative mood, lowercase, no trailing period, kept short (aim for ≤ 50