commitslisted

# Feature Commits Split all current git changes into multiple atomic commits, each scoped to one feature or concern, following conventional commits best practices. ## When to Use - You have changes spanning multiple features or concerns in a single working tree - You want to produce a clean, reviewable commit history before pushing or opening a PR - You need commit messages that follow the Conventional Commits specification ## Procedure ### Step 1 — Gather All Changes Use `get_changed_files` to retrieve every staged and unstaged file with its diff. Also run `git status` in the terminal to get a complete picture of new/deleted/renamed files. ### Step 2 — Analyze and Group by Feature Read each diff and assign every file to a **logical group**. Apply these rules: | Signal | Rule | |--------|------| | Same feature folder or module | Group together | | Only docs / README changes | Separate `docs` commit | | Only config / tooling files (`.gitignore`, `package.json`, CI files) | Separate `chore` or `build` commit | | Style-only changes (whitespace, formatting) | Separate `style` commit | | Test files only | Separate `test` commit | | Bug fix in one module | Separate `fix` commit | | New capability in one module | Separate `feat` commit | | Refactor with no behavior change | Separate `refactor` commit | If a file touches multiple concerns, assign it to the **dominant** concern. Flag ambiguous files for user confirmation before committing. ### Step 3 — Draft Commit Plan Pr