Use when the user wants to insert a branch at a specific position in an existing stack, not at the tip, or runs /gs-insert.
You are implementing /gs-insert. This inserts a new branch at a chosen position in an existing stack, stages and commits any pending changes, updates stack metadata, and rebases all downstream branches. No pushing, no PRs.
git status --porcelain
If the output shows merge conflicts (lines starting with UU, AA, DD), stop and tell the user to resolve conflicts before inserting a branch.
Staged and unstaged changes are fine — they will be handled in step 7.
Follow the stack discovery pattern (git config only, no fallback). Build the ordered branch list from root to tip.
Get the current branch:
git rev-parse --abbrev-ref HEAD
Display the full stack graph with numbered insertion points between each adjacent pair of branches. Mark the current branch with (you are here). Example:
Stack:
<root-branch>
↓ ← [1] insert here
stack/03-use-date-locale
↓ ← [2] insert here
stack/04-locale-support ← (you are here)
↓ ← [3] insert here
stack/05-data-table-meta
Insertion position [1] means between <root-branch> and the first stacked branch. The last position means between the last branch and the tip (appending to the end of the stack).
Ask:
Where should the new branch be inserted? Enter a number from the list above.
Wait for the user to choose a number. Store:
<branch-above> — the branch immediately above the insertion point<branch-below> — the branch immediately below (may be null if inserting at the tip)Read CLAUDE.md (if present) for branch naming conventions. Also look at recent branch names for patterns:
git branch --sort=-committerdate | head -20
Suggest a branch name consistent with the project convention. Ask the user to confirm or provide a different one. Wait for confirmation before proceeding.
<branch-above>Switch to the branch above the insertion point and create the new branch from its HEAD:
git checkout <branch-above>
git checkout -b <new-branch>
Follow the safe staging flow pattern. Show the user what will be staged, warn on sensitive files, and stage by name. If there are no changes, ask whether to create an empty branch (skip step 8, continue with metadata update) or cancel; on cancel, undo with git checkout <branch-above> && git branch -D <new-branch>.
Inspect the staged diff:
git diff --cached --stat
git diff --cached
Suggest a commit message following the project's conventions (Conventional Commits: type(scope): message). Check CLAUDE.md for any project-specific commit conventions.
Show the suggestion and ask the user to confirm or edit it. Wait for confirmation.
Once confirmed, commit:
git commit -m "<confirmed-message>"
Do NOT add Co-Authored-By lines. Do NOT add 🤖 Generated with Claude Code lines.
Record the new branch's parent:
git config git-stack.<new-branch>.parent <branch-above>
If <branch-below> exists, update it to point to the new branch:
git config git-stack.<branch-below>.parent <new-branch>
Rebase each branch below the insertion point in order (closest first, down to the tip). For each downstream branch <downstream>, transplant it from its old parent to its new parent using --onto:
git rebase --onto <new-parent> <old-parent> <downstream>
Where <new-parent> is the branch immediately above it in the updated stack, and <old-parent> is the branch that was immediately above it in the old stack (before the insertion). For the first downstream branch, <old-parent> is the branch that was previously above the insertion point (i.e. <branch-above>), and <new-parent> is the newly inserted branch.
Follow the conflict handling pattern. Pause on genuine conflicts — list conflicted files, show the user, wait for resolution.
After all rebases, return to the new branch:
git checkout <new-branch>
Run the project's verification commands as defined in CLAUDE.md (e.g., pnpm typecheck, pnpm lint) on each affected branch (the new branch and all rebased downstream branches). For each branch, check it out before running verification:
git checkout <branch>
# run verification commands
Work through branches from the one closest to <root-branch> to the tip. After verification, return to the new branch:
git checkout <new-branch>
If no verification commands are found in CLAUDE.md, skip this step.
Report any failures. Do not proceed past failures — ask the user to fix them first.
Show a summary:
/gs-submit to push and open PRs, or /gs-log to see the full stack.Co-Authored-By lines to commits.🤖 Generated with Claude Code lines.CLAUDE.md and existing patterns).gh is not required — this is entirely local./gs-create.git-stack.<new-branch>.parent <branch-above>.<branch-above> is <root-branch>. <branch-below> is the first stacked branch — update its parent to point to the new branch, then rebase all downstream.git rebase --continue).git status shows merge conflicts before starting, stop and tell the user to resolve conflicts first.git checkout <new-branch> lands correctly.