/split-and-ship

name: split-and-ship
description: "Ship an approved split plan as one branch and PR per change group, or as sequential commits. Use when the user asks to \"split and ship\" or \"create separate PRs\"."

Split and Ship

Ship an approved split plan so each change group becomes its own reviewable unit, either as a separate branch and PR or as a sequential commit on the current branch.

Context

A split plan must exist in the conversation. The plan specifies an ordered list of groups, each with a name, file list, and any dependencies on earlier groups.

Task Tracking

At the start, use `TaskCreate` to create a task for each phase:

1. Choose realization path 2. Ship the groups 3. Summarize

Step 1: Choose Realization Path

Detect the repository state:

• Default branch: `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'`
• Current branch name, and whether it tracks an upstream
• Whether an open PR exists for the current branch (`gh pr view --json state`); a closed or merged one counts as none

Sample the prevailing workflow from recent default-branch history (`git log --first-parent origin/<default-branch> -n 30 --pretty=%s`): judge whether changes mostly land through pull requests (merge-PR commits or `(#N)`-suffixed squash commits) or are committed directly to the default branch.

Output a one-line summary of the detected state as text. Then use `AskUserQuestion` to choose how to ship the groups:

• **Separate branches and PRs** — one branch and PR per group (Step 2)
• **Commit each group and push** — one commit per group on the current branch, then push (Step 3)
• **Commit each group only** — one commit per group on the current branch, no push (Step 3)

Recommend the option that fits this repo by listing it first and labeling it `(Recommended)`: a PR-based history recommends separate branches and PRs; a direct-commit history recommends committing each group on the current branch.

If the user declines (chooses the free-form "Other" option or asks to abort), leave the changes staged and do not commit.

Step 2: Ship as Separate Branches and PRs

Take this step only when the user chose separate branches and PRs.

Prepare the working tree

Stash all changes including untracked files (`git stash --include-untracked`) without unstaging first.

Verify `git stash list` shows the saved changes and `git status --short` lists nothing the stash should have taken before proceeding. Entries for a submodule, a nested repository, or files a stashed ignore rule had hidden may remain. When either check fails, stop and report where the changes now are.

Ship each group

Use `TaskCreate` to create a task for each group. Process groups in order.

A group is held when it builds on a group whose PR was handed over for editing and is neither posted nor cancelled yet, or when it builds on a held group. Leave a held group unshipped and continue with the next group.

For each group:

1. **Determine branch**: If the current branch already has an open PR and this group's changes align with the PR's purpose, stay on the current branch. Otherwise, use `AskUserQuestion` to confirm the proposed branch name and create it from the appropriate base:

• Group that builds on an earlier group: branch from that group's branch (stacked)
• Group with no dependencies: branch from the default branch (independent)

2. **Restore and stage** this group's files from the stash's staged snapshot (`git checkout 'stash^2' -- <files>` restores and stages in one operation). For files with hunks belonging to different groups, restore the file, use Edit to remove the unwanted hunks, then re-stage it (`git add <file>`): for an independent group, remove every other group's hunks; for a stacked group, remove only later groups' hunks (earlier groups' hunks are already in its base). Before committing a stacked group, check its staged diff against HEAD and restore from HEAD any earlier group's content it would revert. After committing, reset the working tree (`git checkout -- .`) to clean up before the next group. 3. **Commit**: run the `/commit-rules` skill to load commit message rules, then commit the staged changes following them 4. **Push and create or update PR**:

• Staying on existing branch with an open PR: run the `/pr` skill, then `git push`
• New branch: `git push -u origin <branch>`, then run the `/pr` skill targeting the appropriate base (default branch for independent groups, previous group's branch for stacked groups). When git reports that it could not write the upstream branch configuration, confirm the push landed with `git rev-parse --verify --quiet refs/remotes/origin/<branch>`, then run `git branch --set-upstream-to=origin/<branch>` via the Bash tool (`dangerouslyDisableSandbox: true`) before running the `/pr` skill

When held groups remain once every other group has shipped, output which groups are held, which handed-over PR each waits on, and that the stash holds their changes. Keep the stash and end the turn.

Once a handed-over PR is posted, take the groups it held through the same four steps in order, branching each from the current tip of the branch it builds on. When that PR is cancelled instead, use `AskUserQuestion` to ask whether to ship the groups it held stacked on its branch, which has no PR, or to leave them unshipped.

Clean up and summarize

1. Drop the stash 2. Check out the last created branch 3. Output a summary table: group name, branch, PR URL, and base branch. For a group whose PR was not posted, print the handed-over body file path in place of the URL.

Then use the TaskList tool and proceed to any remaining task.

Step 3: Ship as Commits on the Current Branch

Take this step only when the user chose to commit each group. This path stays on the current branch and creates no branches or PRs.

Prepare the working tree

Stash all changes including untracked files (`git stash --include-untracked`) without unstaging first.

Verify `git stash lis