smart-commitlisted

# Smart Commit Inspect the working tree, **classify every change first**, group into logical commits, then handle each commit separately with explicit user approval. **Never commit without user confirmation. Never lump unrelated changes into one commit.** --- ## Workflow ### Step 1 — Snapshot the working tree Run all three commands and keep the output in context: ```bash git status --short git diff --stat HEAD git diff --cached --stat ``` If both staged and unstaged areas are empty, tell the user there is nothing to commit and stop. ### Step 2 — Read the full diff ```bash # Staged changes git diff --cached # Unstaged changes git diff ``` Skim hunks to understand *what* changed, not just *which* files. Treat both staged and unstaged as candidates — classification covers everything. ### Step 3 — Classify ALL changes (REQUIRED FIRST STEP) This step is mandatory before any staging or committing decision is made. Map **every changed file** (staged or unstaged) to a conventional-commit type: | Type | When to use | |------------|-------------| | `feat` | New user-visible feature or capability | | `fix` | Bug fix or incorrect behavior corrected | | `refactor` | Code restructuring with no behavior change | | `perf` | Performance improvement | | `test` | Adding or updating tests only | | `docs` | Documentation, comments, README only | | `style` | Formatting, whitespace, lint — no logic change | | `chore` | Build scripts, deps, tooling, c