commit-splitlisted

# commit-split Split uncommitted changes into atomic, reviewable commits. Two things matter: the user shouldn't have to classify contexts by hand (analysis and proposal are this skill's job), and the result must be verifiable (prove not a single byte of code differs before and after the split). Flow: **read state → analyze changes → propose a plan → user confirms → execute → verify losslessness**. Don't ask the user to classify anything before proposing. Analyze first, present a plan, let the user adjust it. ## Step 0. Read state ```bash git status --porcelain # change list; staged/unstaged/untracked git branch --show-current git log --oneline -20 # learn the commit message convention git rev-parse HEAD # record the starting point (used for verification) git diff HEAD | git patch-id --stable # fingerprint of the original change (used for lossless verification) ``` Stop on: merge/rebase in progress, or conflicted files. Report the state and halt. Watch out for: - **Changes already staged** — tell the user. The split can't preserve the existing staging, so get agreement on "unstage everything and re-split the whole thing", then run `git restore --staged .`. - **Untracked files** — include them in the plan table but mark them separately. If they look like build junk (logs, scratch files), suggest excluding them from the commits. ## Step 1. Analyze changes Read the full `git diff HEAD` and the contents of untracked files, then identify logical un