菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when you need to fix, correct, or update content in an earlier commit. Absorbs staged changes into correct stack commits INSTEAD of running git absorb or git commit --fixup via Bash. Prevents: missed dry-run preview, leftover staged changes going unnoticed, forgetting to restack. Falls back to guided manual amend when absorb cannot route hunks.
Use when you need to plan commits, restructure a stack, or commit uncommitted work as organized atomic commits. Builds a stack from a description, uncommitted work, or existing commits INSTEAD of manual git rebase -i, git reset --soft, or ad-hoc git move sequences. Prevents: wrong commit ordering, forward references, git move -F panics, untested intermediates.
Use when you need to push, submit, or create pull requests for a commit stack. Syncs, validates, and pushes INSTEAD of manual git sync + git submit + PR/MR creation. Handles branch creation, stacked PR/MR creation with correct base branches.
Use when you need to audit, analyze, or review stack quality before restructuring. Produces a structured summary with per-commit classification, philosophy audit, and violation flags. Output feeds directly into /stack-plan restructure mode. Use INSTEAD of manual git log inspection.
Use when you need to run tests or formatters across every commit in a stack. Use INSTEAD of manual git test run or looping git checkout + test. Prevents: untested commits, wrong parallelism settings, cache misunderstandings.
| 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 | false |
| compatibility | Requires git-branchless |
Split a large commit into multiple smaller, atomic commits. Target commit defaults to HEAD if not specified.
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.
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:
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:
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 # or git add <specific-files>
git commit -m "descriptive message for this group"
Repeat for each logical group. Each commit must:
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()'
If the user wants to restructure multiple commits (not just split one), use
/stack-plan instead.
git revise -c <hash> for two-way splits: Splits a commit into
exactly two pieces in-memory (no checkout). Select hunks for the first
commit; remainder becomes the second. Faster for simple splits, but
limited: no 3+ way splits, no binary files, no empty file additions.
Requires git restack afterward.git add -p to split
hunks within the file