Menu
Full ship pipeline: /review + fix + /improve + fix + /merge in one command. Use when ready to ship a branch end-to-end.
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/drn/dots --skill shipThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
| name | ship |
| description | Full ship pipeline: /review + fix + /improve + fix + /merge in one command. Use when ready to ship a branch end-to-end. |
| disable-model-invocation | true |
Run the full review-fix-improve-fix-merge pipeline to ship the current branch.
$ARGUMENTS - Optional: flags to customize the pipeline (e.g., "skip-improve" to skip the improve phase)git branch --show-currentgit branch -r 2>/dev/null | grep -oE 'origin/(main|master)' | head -1git status --shortgit diff --stat origin/main...HEAD 2>/dev/null | head -50git diff --stat origin/master...HEAD 2>/dev/null | head -50You orchestrate a 6-phase pipeline to take the current branch from "done coding" to "merged into master." Each phase must complete before advancing to the next.
Phases: 0. Commit — commit any uncommitted changes so downstream phases see them
/review to get findings/improve)/merge to land the branch
5b. Switch worktree to default branch — hygiene step so follow-up work starts from the new tipIf any phase has nothing to do (no findings, no improvements), skip it and move on.
All phases must execute in a single unbroken sequence. After any sub-skill returns (/review, /merge) or any inline analysis completes, immediately proceed to the next phase. Never treat a sub-skill return or analysis report as the end of your task. The pipeline is only complete after Phase 5b finishes or an abort condition is hit.
First, git fetch origin <default-branch> (the branch found in "Base ref" above). The BEHIND/diverged detection below reads local knowledge of origin/master (git status, git log HEAD..origin/master) — if that ref hasn't been fetched recently, a remote that has moved on looks identical to "up to date," and the gap surfaces later as confusing failures (e.g. lint-pr/pre-pr failing on files this branch never touched, because --new-from-rev=origin/master diffed against a stale local ref) instead of being caught here where it's cheap to fix. This is a plain fetch, not a merge/rebase — it only updates remote-tracking refs, so it's always safe to run even mid-pipeline.
Before running review, ensure all changes are committed. The review phase uses git diff origin/master...HEAD which only sees committed changes — uncommitted work would be invisible to the reviewer.
Check git status --short. If there are staged or unstaged changes to tracked files (or untracked files that are clearly part of the work):
git add the modified/new filesThis applies whether or not the branch already has commits ahead of master. If there are no existing commits ahead of master but the working tree has uncommitted work, this phase produces the first commit — do not abort. The "no changes on branch" abort only fires when both the commit history AND the working tree are empty (checked after this phase runs).
If there are uncommitted changes AND existing commits ahead of master, commit the uncommitted changes as a separate commit to preserve the existing commit history.
If the branch is BEHIND origin/master (check git status output for "Your branch is behind 'origin/master' by N commits"), fast-forward first or the review will diff against a stale base. With uncommitted changes that overlap incoming files:
git stash push -u -m "ship phase 0" to set the work asidegit pull --ff-only to advance to origin/mastergit stash pop and resolve any conflicts (the pull may have moved code under your edits)make test (or project equivalent) to confirm the resolved tree is saneIf pull --ff-only fails because the branch has diverged (commits ahead AND behind), check whether the divergence is the post-squash-merge pattern: the branch has commits that were already squash-merged into master in a previous /ship. Detect this by comparing git log --oneline origin/master..HEAD against the most recent merge commit on master — if the local commit subjects match content that's already squash-landed, the resolution is to git reset --hard origin/master && git cherry-pick <new-commits> to drop the already-applied originals and keep only the new work. The local commits aren't lost (they remain on the remote feature branch), and a plain git rebase origin/master will conflict because the squashed master commit doesn't apply cleanly to the unmodified branch base. Confirm the reset+cherry-pick plan with the user before running it (it's destructive on local refs even though nothing is actually lost). For non-squash-merge divergence (true forking history), still stop and ask — don't auto-rebase.
If the working tree is clean, skip this phase.
Print:
Phase 0: committed uncommitted changes. (or "Phase 0: working tree clean — skipped.")
Invoke the /review skill to analyze the current branch changes. Wait for the full report.
Even if /rereview ran recently, still run /review. The two skills use different prompts and surface different patterns: /rereview is depth-first with three independent reviewers and tends to catch security and regression risks; /review is breadth-first and tends to catch consistency and asymmetry issues that depth-first review misses. They are complementary, not redundant. Do not skip Phase 1 just because /rereview was clean. Phase 2 acts on /review's findings only — any prior /rereview output is informational background, not a substitute for this phase's input.
If the review returns no blocking issues, no warnings, and no suggestions, print:
Review clean — skipping to Phase 3.
And skip directly to Phase 3.
Work through the review report systematically:
For each blocking issue in the review report:
If there are no blocking issues, skip to 2b.
For each warning in the review report:
For each suggestion or INFO-level finding in the review report:
After addressing all findings (blocking, warnings, and suggestions), run the full project quality gate (not just unit tests) to confirm nothing broke — for a Go project with a pre-pr-style make target, run the full gate (build/vet/fmt/lint/coverage), not just go test, since lint and coverage gates catch issues tests don't:
origin/<default-branch> and check whether the branch has fallen behind (see Phase 0's fetch step); a stale local origin/master ref makes a lint/coverage gate diff against the wrong base and surfaces pre-existing issues as if they were new. Rebase onto the fresh base and re-run before diagnosing further.Print a summary of what was addressed:
Phase 2 complete: fixed N blocking issues, N warnings, N suggestions. Tests passing.
Check if $ARGUMENTS contains "skip-improve". If so, skip to Phase 5.
PIPELINE CONTINUATION RULE: You are mid-pipeline. After the improve analysis completes, you MUST continue to Phase 4 and Phase 5. Do NOT stop, summarize, or wait for user input. The /ship pipeline is not complete until Phase 5 finishes.
Run the improve analysis inline using these abbreviated steps (do NOT invoke /improve as a separate skill):
Print:
Phase 3 complete: analyzed session, applied N improvements, N handoff prompts generated.
Immediately continue to Phase 4.
If Phase 3 produced code changes:
If Phase 3 produced no code changes, skip this phase.
Print:
Phase 4 complete: applied N improvements. Tests passing.
Invoke the /merge skill to land the branch into master.
Handle merge script exit codes as documented in the /merge skill (conflicts, nothing to merge, review blocked, errors).
If CI fails on tests unrelated to your PR, fix them inline as part of /ship rather than rebasing or treating the merge as blocked. Pre-existing flakes (timing-sensitive tests, data races on shared mutable state, environment-dependent assertions) are normal during a /ship cycle on a project with sparse CI history. Capture each fix as its own commit with a message that names the flake and the cause (e.g., "fix flaky-test sleep timing on slower CI" or "fix data race on shared buffer under -race") so the rationale stays clear in history. Then re-run /merge.
After /merge returns success, ensure the worktree is on the default branch so any follow-up work (or any other agent invoked next in this worktree) starts from the new tip rather than the squashed-out feature branch. This is belt-and-suspenders alongside /merge's own auto-switch — if /merge already switched (default for squash), this is a no-op; if the user passed --keep-branch or used --method rebase/--method merge, this still rescues the follow-up agent path.
Detect the default branch and switch. This is a simplified probe that only recognizes main / master — /merge itself uses the GitHub API (gh api repos/<slug>) for canonical detection and handles repos with non-standard default names. If your repo's default is something else (e.g., trunk), /merge's own auto-switch already handled it and this phase is a no-op; skip Phase 5b for those repos rather than relying on the fallback below.
DEFAULT_BRANCH=$(git branch -r 2>/dev/null | grep -oE 'origin/(main|master)' | head -1 | sed 's|origin/||')
[ -z "$DEFAULT_BRANCH" ] && DEFAULT_BRANCH="master"
git checkout "$DEFAULT_BRANCH" 2>/dev/null && git pull --ff-only origin "$DEFAULT_BRANCH"
If the checkout fails (uncommitted changes, no local default-branch ref, another worktree owns it, etc.), warn but do not abort — the pipeline is complete; this is hygiene. Print the current branch and a one-line note that follow-up work in this worktree should git checkout "$DEFAULT_BRANCH" (or git reset --hard origin/"$DEFAULT_BRANCH") before committing.
After the pipeline completes (or aborts), print:
# Ship Summary: {branch name}
| Phase | Status | Details |
|-------|--------|---------|
| Commit | {done/skipped} | {committed N files / working tree clean} |
| Review | {done/skipped} | {N blocking, N warnings, N suggestions found} |
| Address Review | {done/skipped} | {N blocking fixed, N warnings fixed, N suggestions applied} |
| Improve | {done/skipped} | {N improvements applied} |
| Address Improvements | {done/skipped} | {N commits} |
| Merge | {done/blocked/failed} | {PR URL or error} |
| Switch Worktree | {done/skipped/warned} | {current branch after switch, or warning} |
Based on SOC occupation classification
