split-worktree-commits

name	split_worktree_commits
description	Split a multi-finding worktree into per-finding commits via non-interactive `git add -p`. Use when an `/improve` or `/review` pass has edited several distinct findings into the worktree together and they need to land as separate commits. Refuses to run on secret-rendering templates.

Split worktree commits

You have a worktree with N independent edits across one or more files. Land each finding as its own commit without losing the just-tested state.

Pre-flight checks (always)

1. Run git status and git diff --stat. Confirm the changed files match the findings list the user is working from.
2. Refuse to operate on template files that render secrets (e.g. templates/*.j2 referencing *_password / *_token / *_secret) — secret-rendering templates must be staged whole-file or not at all, so a partial hunk can never leak a rendered secret into an unrelated commit. If such a file is in the changeset, stage it whole-file in its own commit before invoking this skill on the rest.
3. Confirm working tree state is otherwise clean (no unrelated uncommitted changes you didn't introduce).

Recipe — one finding at a time

For each finding the user wants to commit separately:

1. Identify which file(s) and which hunk(s) belong to this finding. If the user hasn't told you, ask.
2. Build the answer string for git add -p: one character per hunk in file order. y = stage, n = skip. If two adjacent hunks should be split apart, prepend s before answering y/n on the split halves.
   • Example: a file with 4 hunks, where you want to stage hunks 1 and 3 only → printf 'y\nn\ny\nn\n' | git add -p <file>.
3. Run the git add -p invocation.
4. Always run git diff --staged and visually verify the staged content matches your intent. The printf pattern bypasses interactive confirmation that would otherwise catch a miscount.
5. If the staged diff doesn't match → git reset HEAD <file> and retry. Do not revert the worktree to redo the edits from scratch — wastes effort, loses tested state, and risks dropping comment/decision detail.
6. Show the user the staged diff and the proposed commit message. Wait for approval.
7. git commit with a one-line subject + short body explaining the finding. Follow the repo's commit conventions (AGENTS.md/CLAUDE.md if present); default to a short imperative subject, prefixed with the role/area when useful.
8. After commit: git status confirms the remaining hunks are still unstaged in the worktree.

When hunks merge into one (and you want them split)

Git auto-merges hunks within ~3 unchanged lines of each other into a single hunk. If you need finer granularity:

• Answer s first when prompted on a merged hunk to split it, then answer y/n on the resulting smaller hunks.
• This shifts the answer-character count, so plan the printf string accordingly.

Bail-out conditions

Stop and escalate to the user (do not silently continue) if:

• The first git status shows files you don't recognize from the findings list.
• Any file in the changeset matches the secret-rendering-template pattern above.
• git diff --staged after a git add -p doesn't match the intended hunk set after one retry.
• A pre-commit hook fails. Do not --no-verify; fix the underlying issue and create a new commit.