Skip to main content
ClaudeWave
Skill336 estrellas del repoactualizado 6d ago

split-and-ship

Split and Ship executes an approved split plan by creating separate Git branches, commits, and pull requests for each change group specified in the plan. Use this skill when asked to ship a split plan, create separate PRs from grouped changes, or split changes into independent or stacked branches. The skill manages the working tree, restores files selectively from a stash for each group, applies commit rules, and creates or updates PRs with appropriate base branches.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/tobihagemann/turbo /tmp/split-and-ship && cp -r /tmp/split-and-ship/claude/skills/split-and-ship ~/.claude/skills/split-and-ship
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# Split and Ship

Ship an approved split plan as separate branches, commits, and PRs.

## Context

A split plan must exist in the conversation. The plan specifies an ordered list of groups, each with a name, file list, and branch topology (stacked or independent).

## Step 1: Prepare Working Tree

1. Detect the default branch: `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'`
2. Check the current branch and whether a PR already exists for it using `gh pr view`
3. Save all staged changes, then unstage everything (`git reset`)
4. Stash all changes including untracked files (`git stash --include-untracked`) so files can be selectively restored per group

Verify `git stash list` shows the saved changes before proceeding.

## Step 2: Ship Each Group

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

For each group:

1. **Determine branch**: If the current branch already has a 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:
   - Independent group: branch from the default branch
   - Stacked group: branch from the previous group's branch
2. **Restore and stage** this group's files from the stash (`git checkout stash -- <files>` restores and stages in one operation). For files with hunks belonging to different groups, restore the file, then use Edit to remove the hunks that belong to later groups before staging. After committing, reset the working tree (`git checkout -- .`) to clean up before the next group.
3. **Commit and push**: run the `/commit-rules` skill to load commit message rules, commit the staged changes following them, then `git push`
4. **Create or update PR**:
   - Staying on existing branch with a PR: run the `/update-pr` skill
   - New branch: run the `/create-pr` skill targeting the appropriate base (default branch for independent groups, previous group's branch for stacked groups)

## Step 3: 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

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

## Rules

- Run the `/commit-rules` skill before every commit; do not commit without loading it first.
- Never lose uncommitted work. If any step fails (commit hook, push, PR creation), stop and report the failure, which groups have been shipped, and that the stash still contains all changes for recovery.
- Stacked PRs target the previous group's branch. Independent PRs target the default branch.
- For stacked groups, the PR description should note the dependency chain.
- Don't reference `.turbo/` content (filenames, requirement IDs, shell references, headings) in branch names. `.turbo/` is gitignored, so these references would be opaque to anyone reading without local copies.
answer-reviewer-questionsSkill

For each reviewer question on a PR, recall implementation reasoning and compose a raw answer. Use when the user asks to \"answer reviewer questions\", \"draft answers to PR questions\", or \"explain reviewer questions\".

apply-findingsSkill

Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\".

auditSkill

Project-wide health audit pipeline that fans out to all analysis skills in parallel, evaluates findings, and produces a unified report at .turbo/audit.md. Use when the user asks to \"audit the project\", \"run a full audit\", \"project health check\", \"audit my code\", \"codebase audit\", or \"comprehensive review\".

changelog-rulesSkill

Shared changelog conventions and formatting rules referenced by $create-changelog and $update-changelog. Not typically invoked directly.

code-styleSkill

Enforce mirror, reuse, and symmetry principles to keep new code consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.

codex-execSkill

Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".

codex-reviewSkill

Run AI-powered code review using the codex CLI. Use when the user asks to \"codex review\", \"run codex review\", or \"review a commit with codex\".

commit-rulesSkill

Shared commit message rules and technical constraints referenced by $stage-commit and $commit-staged. Not typically invoked directly.