菜单
Execute an approved split plan, shipping each change group separately as its own branch and PR or as sequential commits on the current branch. Use when the user asks to "split and ship", "ship the split plan", "create separate PRs", or "split changes into branches".
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/tobihagemann/turbo --skill split-and-ship命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Survey the codebase for analogous features, reusable utilities, and existing patterns relevant to a proposed change, reading any source the task names outside this repo. Returns structured findings without writing code. Use when the user asks to "survey patterns", "find existing patterns", "look for analogous features", "check how similar things are done", "find prior art for this change", or needs pattern context before planning a change.
Survey the codebase for analogous features, reusable utilities, and existing patterns relevant to a proposed change, reading any source the task names outside this repo. Returns structured findings without writing code. Use when the user asks to "survey patterns", "find existing patterns", "look for analogous features", "check how similar things are done", "find prior art for this change", or needs pattern context before planning a change.
Critically assess external feedback (code reviews, AI reviewers, PR comments) and decide which suggestions to apply using adversarial verification. Use when the user asks to "evaluate findings", "assess review comments", "triage review feedback", "evaluate review output", or "filter false positives".
基于 SOC 职业分类
正在显示 SKILL.md
| name | split-and-ship |
| description | Execute an approved split plan, shipping each change group separately as its own branch and PR or as sequential commits on the current branch. Use when the user asks to "split and ship", "ship the split plan", "create separate PRs", or "split changes into branches". |
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.
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.
At the start, use TaskCreate to create a task for each phase:
Detect the repository state:
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'gh pr view)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:
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.
Take this step only when the user chose separate branches and PRs.
git reset)git stash --include-untracked) so files can be selectively restored per groupVerify git stash list shows the saved changes before proceeding.
Use TaskCreate to create a task for each group. Process groups in order.
For each group:
AskUserQuestion to confirm the proposed branch name and create it from the appropriate base:
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 unwanted hunks before staging: 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). After committing, reset the working tree (git checkout -- .) to clean up before the next group./commit-rules skill to load commit message rules, commit the staged changes following them, then git push/update-pr skill/create-pr skill targeting the appropriate base (default branch for independent groups, previous group's branch for stacked groups)Then use the TaskList tool and proceed to any remaining task.
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.
git reset)git stash --include-untracked) so files can be selectively restored per groupVerify git stash list shows the saved changes before proceeding.
Run the /commit-rules skill to load commit message rules. Use TaskCreate to create a task for each group. Process groups in order.
For each group:
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.git checkout -- .) to clean up before the next group.git push)Then use the TaskList tool and proceed to any remaining task.
/commit-rules skill before every commit; do not commit without loading it first..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.