ship

name	ship
description	Use when asked to ship, build, implement, fix, or deliver a change end-to-end — "ship X", "get it out", "build this", a tracker ID plus a fix request, or any feature/bugfix meant to land in main.

Ship

Overview

Take a request from message to merged-and-documented. The deliverable of a ship is a squash-merged PR that passed review and green CI with the merge authority's explicit approval in this conversation, followed by a documentation sync. "Ship it" grants urgency, not merge authority.

Operator config

If config.md exists in this skill directory, read it first — it sets the parameters below. Without it, use the defaults.

Parameter	Meaning	Default
merge_authority	Who approves merges. Agents never merge on their own.	The human operator in the conversation
dispatch_model	Model policy for every dispatched agent, reviewer, and workflow agent() call	Inherit the session model
tracker	Issue tracker for tickets, verified-close, and follow-ups	Whatever the repo uses; skip tracker steps if none
spec_paths	Where written specs/plans live	docs/superpowers/specs/, docs/superpowers/plans/
sensitive_paths	Diff areas that escalate review effort to xhigh	Payments, auth/credentials, data migrations
build_check	The build that matches CI's strictness	The project's production build command
docs_to_sync	Docs checked in the post-merge sync	CLAUDE.md plus every file it references

The pipeline

1. Pre-flight. git fetch; confirm a clean, current main. Work on a feature branch in the main checkout — never commit to main. Leave unrelated untracked files alone (usually the operator's in-progress work from another workstation). Model check: the coordinating session runs on whatever model it was launched with and can't be changed from inside the skill — if dispatch_model policy conflicts with the session model, tell the operator up front so they can switch or relaunch before the ship proceeds.
2. Entry point. Does a written spec or plan exist? Check spec_paths and the tracker issue (a ticket that pins down the concrete fix counts). If yes → step 3. If no → REQUIRED SUB-SKILL: superpowers:brainstorming, then superpowers:writing-plans — no matter how small the feature looks. Small-looking features hide exactly the scope questions (which rows? which columns? sensitive fields?) that brainstorming exists to surface; "I'll note my assumptions in the PR" is a plan you didn't show anyone.
3. Execute the plan. REQUIRED SUB-SKILL: superpowers:subagent-driven-development — not inline execution. Every agent a ship dispatches follows dispatch_model: implementation subagents, task reviewers, fix subagents, and workflow agents all get the policy model explicitly — if the policy names a model, never let a dispatch silently inherit the session model instead. Only the coordinating session itself (in-session planning and judgment) stays on whatever model it was launched with.
4. Review loop — REQUIRED, never optional. Run /code-review at high effort. Fix every meaningful finding — correctness, security, data integrity, behavior; anything beyond pure style nits — then re-run /code-review at high and repeat fix → re-review until a full pass returns nothing meaningful. The exit condition is a clean pass, not "I fixed everything from the last pass." Escalate the loop to xhigh when the diff touches sensitive_paths. Reviews follow dispatch_model too: when /code-review launches a workflow, pin every agent() call in the persisted workflow script to the policy model (edit the script file, then launch/relaunch it); any inline or subagent reviewer gets the policy model in its dispatch. Refactor-candidate detection — REQUIRED once the loop has run 2+ passes: look across all passes so far; if two or more meaningful findings landed in the same area (same file, module, or subsystem), that area is fragile — file a tracker issue titled Refactor candidate: <area> listing each clustered finding (pass it came from, file:line, one-line description) so a later ship can take the refactor as its own scope. Then dispatch one agent (per , like all ship dispatches) to assess the area — what the repeat findings share, what a refactor would look like, rough size — and paste its assessment into the issue. Do NOT expand the current ship to do the refactor; the issue is the deliverable.

Red flags — STOP and back up

• About to gh pr merge without the merge authority's approval given in this conversation
• "They said ship it / it's a solo repo, so I'll merge myself"
• Skipping /code-review because the diff is small, it's late, or you already read your own diff
• Fixed review findings, then moved on to verify/PR without re-running /code-review
• Any dispatched agent, reviewer, or workflow agent() call ignoring dispatch_model or silently inheriting the session model against policy
• Skipping brainstorm/plan because "it's just a button"
• Calling the task done at merge — step 8 hasn't run
• Closing a tracker issue (or leaving an auto-close standing) without re-reading its scope list against what actually merged
• Review loop ran 2+ passes with 2+ findings in the same area and no refactor-candidate issue was filed

Rationalizations

Excuse	Reality
"They said 'get it out' — waiting on approval defeats the point"	Asking costs minutes; a bad merge into a live product costs users real money. Post the PR and ask.
"No reviewer is around at this hour"	/code-review IS the reviewer. Run it.
"Self-reviewing my diff covers it"	You wrote the bug; you'll re-read past it. The review loop exists because it keeps catching sensitive-path bugs the author missed.
"I fixed all the findings — a re-review will just come back clean"	The re-review is the proof it's clean. Fix commits introduce their own bugs; the loop ends on a clean pass, not on a prediction of one.
"A different model would do this dispatch better"	dispatch_model is the operator's explicit call, not a per-task judgment. Follow the policy on every dispatch.
"One-button feature — planning is overhead"	No spec → brainstorm + plan. That's where the column/row/sensitive-data questions get answered before the code exists.
"I fixed the clustered findings, so the area is fine now"	The fixes patched symptoms; repeat findings in one area across passes are the fragility signal itself. Filing the refactor-candidate issue costs minutes and preserves the evidence.
"Nothing in the docs could have changed"	Checking is minutes. A ticket once sat wrongly open for a month because a doc mirror wasn't synced after a merge.

Companion skill

convoy runs multiple ship pipelines as parallel, continuous lanes over a ranked queue. Convoy requires ship; every ship rule applies inside each lane.