| name | stack-split |
| description | Use when you need to break up, split, or decompose a large commit into smaller atomic commits. Use INSTEAD of manual git rebase -i + edit or git reset HEAD^. Prevents: non-working intermediate commits, wrong split ordering, missed downstream restack. |
| argument-hint | [commit] |
| disable-model-invocation | true |
| compatibility | Requires git-branchless |
Split a large commit into multiple smaller, atomic commits. Target commit
defaults to HEAD if not specified.
Pre-flight
-
Load references — read references/git-branchless.md and
references/philosophy.md (relative to this skill's directory) before
proceeding.
-
Check branchless init:
if [ ! -d ".git/branchless" ]; then git branchless init; fi
-
Check for stale rebase state:
ls .git/rebase-merge .git/rebase-apply 2>/dev/null
If present, run git rebase --abort before proceeding.
Steps
-
Identify the target commit. If $ARGUMENTS is provided, use it.
Otherwise default to HEAD.
-
Analyze the commit to understand what it contains:
git show --stat <commit>
git show <commit>
Read the full diff. Identify logical groups following the ordering in
references/philosophy.md:
- Refactoring / cleanup (should be first)
- Type definitions / interfaces / schemas
- Core logic changes
- Edge cases / error handling
- Tests
Documentation belongs with the feature it documents, not as a separate
split. Dependencies and config files go in the commit that first uses them.
-
Propose a split plan to the user. For each proposed commit:
- One-sentence description
- Which files/hunks belong to it
- Why it's a separate concern
Wait for user approval before proceeding.
-
Perform the split using interactive rebase:
git rebase -i <commit>^
Mark the target commit as edit, then:
git reset HEAD^
This unwinds the commit but keeps all changes in the working tree.
-
Stage and commit each group in the agreed order:
git add -p
git commit -m "descriptive message for this group"
Repeat for each logical group. Each commit must:
- Be describable in one sentence
- Leave the codebase in a working state
- Target 50-200 lines
-
Complete the rebase:
git rebase --continue
-
Restack if there are downstream commits:
git restack
-
Verify the result:
git sl
Show the user the new stack. If a test command is available, run tests
across the new commits:
git test run -x '<test-command>' 'stack()'
Alternative: Full Stack Restructure
If the user wants to restructure multiple commits (not just split one), use
/stack-plan instead.
Tips
- Format changes should ALWAYS be a separate commit (they dominate diffs and
hide functional changes)
- If a file has both refactoring and new logic, use
git add -p to split
hunks within the file
- Prefer too many small commits over too few large ones — they can always be
squashed later
- Each commit message should explain WHY, not just WHAT