curate-commitslisted

# Curate the Working Tree into Logical Commits One commit per idea. A commit that touches four unrelated things is a commit nobody can revert, bisect, or review. This skill never edits code. It only stages, commits, and reads. ## Step 0 — Establish the ground truth Run `"${CLAUDE_PLUGIN_ROOT}"/scripts/staged-summary.sh`. It prints the branch, the staged/unstaged/untracked split, per-file churn, the hunk headers (which name the enclosing function for each change), and the last ten commit subjects. Read the last ten subjects carefully. **The repository's existing convention wins** over any default. If history uses `feat(scope): thing`, match that. If it uses bare imperative subjects, match that instead. Do not impose Conventional Commits on a repo that has never used them. If the tree is clean, say so and stop. If the current branch is the repository's default branch (`main`/`master`), say so in the Step 3 plan and offer to create a branch first. Don't create one silently. ## Step 1 — Group the changes by intent Read the actual diff for anything the hunk headers leave ambiguous. Then group every changed hunk into commits. - Group by **why**, not by directory. A rename that spans six files is one commit; two unrelated fixes in one file are two commits. - A refactor and a behaviour change never share a commit. If a file has both, that file gets split across two commits with `git add -p`. - New files with no dependants can usually ride with the change that first uses the