commitlisted

## Step 1 - Read staged changes If output is empty: respond "No staged files. Run `git add <files>` first." and stop. ## Step 2 - Determine commit type Classify based on staged files: | Staged files | Type | |---|---| | Source code correcting broken behaviour | `fix` | | Test files only (`__tests__/`, `e2e/`, `tests/`, `test_*.py`, `*_test.go`, `*Tests.swift`, `*Test.kt`, `*Test.java`, `src/test/`) | `test` | | Docs only (`docs/`, `README.md`) | `docs` | | Context/config files (`.claude/`, `CLAUDE.md`, `MEMORY.md`, pipeline, skills, settings) | `chore` | | Restructuring without behaviour change | `refactor` | When code + tests are staged together, type follows the code change (`feat` or `fix`). **BREAKING CHANGE**: if a migration drops a column, renames a table, removes an API field, or changes a response shape - append `!` after type/scope AND add a `BREAKING CHANGE:` footer line explaining the impact. ## Step 3 - Determine scope Derive from the primary functional area of the staged changes: - Infrastructure: `auth` · `proxy` · `db` · `api` · `email` - Horizontal: `ui` (UI-only, no domain logic) · `context` (pipeline.md, CLAUDE.md, skills, rules) - Omit scope if changes span >3 unrelated areas or are truly cross-cutting ## Step 4 - Write description Rules: - Imperative mood: `add`, `fix`, `update`, `remove` - never past tense - Max 72 characters total including `type(scope): ` - No period at end ## Step 5 - Body (include when useful) Include a body when: - The r