Capabilities

The Commands page covers how each command behaves. This one is about the jobs people reach for it to do.

Ship a spec you just finished writing

You have spent an hour deciding how something should work. The decisions are made; what is left is typing. delegate plan skips the planner entirely and builds from your spec as written, so the fleet implements your decisions rather than re-deriving its own.

ship delegate plan SHIP-412 --file docs/plan.md

This is the hand-off with the highest leverage, because the expensive part, the thinking, is already done and the cheap part is what gets delegated.

Get a finished branch to merge

You built something locally and you do not want to chase it through review, CI and QA yourself.

ship delegate pr SHIP-412

The fleet reviews the diff, runs the tests, and drives it toward merge. If CI is red when you hand it over, fixing that comes first, so you do not need to green it up before delegating.

Run a lane that the repository does not carry

Most reviews should follow the repository's conventions. Occasionally one mission needs a different lens: a security pass on an endpoint that just became public, an API-compatibility check before a release.

ship delegate pr SHIP-412 --prompt-file security-review.md --prompt-mode extend

extend keeps the repository's own reviewer conventions and adds the lane on top. Nothing is committed, and the lane applies to this mission only, so a one-off concern does not become a permanent rule everyone pays for.

A/B a harness or model on identical work

Configuration is a first-class axis: cost, latency and outcome are attributed back to the harness/model/prompt combination that produced them. Running the same work two ways gives you a comparison rather than an opinion.

ship delegate pr SHIP-412 --harness claude-code
ship delegate pr SHIP-413 --harness codex

Because a prompt override is folded into the same configuration identity, "repo layer only" and "repo layer plus a security lane" are distinct series too, rather than being averaged together.

Correct a mission without restarting it

A restart re-checks an unchanged pull request against verdicts it already has, concludes nothing changed, and does nothing, which looks like success while your feedback goes nowhere. An instruction is the channel that carries new information.

ship instruct SHIP-412 -m "Keep the current Node range, override nopt instead"

Use --note for background a later agent should have without starting any work now.

Drive it from CI or a script

Every command takes --json, and exit codes are distinct enough to branch on: 2 usage, 3 forbidden, 4 not found, 5 precondition, 6 onboarding incomplete.

if ship status "$ISSUE" --json | jq -e '.summary.testState == "passed"' >/dev/null; then
  echo "ready"
fi

A token can be bound to a single project and given only the scopes the script needs, so an automation holds narrower authority than the person who created it.

Let a coding agent do all of it

The CLI is designed to be driven by an agent as much as by a person, which is what ship init and the hosted skill document are for. See Coding agents for worked hand-offs with Claude Code and Codex. An assistant that talks to the platform directly, rather than by running commands in your repository, connects over MCP instead.