Capabilities

The Commands page tells how each command works. This page shows the jobs that people use the CLI for.

Ship a spec you just finished writing

You took an hour to decide how something should work. You made the decisions, and the code is all that is left to write. With delegate plan, the fleet skips the Planner and builds from your spec as you wrote it. The fleet implements your decisions and does not make a plan of its own.

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

This hand-off gives the largest return, because you already did the expensive part, the decisions, and you delegate only the cheap part.

Get a finished branch to merge

You built something locally, and you do not want to manage review, CI and tests for it yourself.

ship delegate pr SHIP-412

The fleet reviews the diff, runs the tests and makes the pull request ready for you to merge. If CI fails when you delegate the branch, the fleet fixes the failure first. You do not have to make CI pass before you delegate.

Run a lane that the repository does not carry

Most reviews should follow the conventions of the repository. Sometimes one mission needs a different kind of review. Examples are a security review of an endpoint that is now public, and an API compatibility check before a release.

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

With extend, the Reviewer keeps the repository's own conventions and gets your instructions after them. Your instructions do not go into the repository. They apply to this mission only, so a one-time concern does not become a permanent rule that every mission must follow.

A/B a harness or model on identical work

You can compare configurations. SHIP attributes cost, latency and outcome to the combination of harness, model and prompt that produced them. If you run the same work in two ways, you get a comparison instead of an opinion.

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

A prompt override is part of the same configuration identity. So a mission with only the repository's instructions and a mission with extra security instructions are two separate series. Comparisons do not average them together.

Correct a mission without restarting it

A restart checks the unchanged pull request again against the verdicts that it already has. It finds that nothing changed, so it does nothing. That looks like a success, but the agents never get your feedback. An instruction sends new information to the agents.

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

Use --note to give background to a later agent. A note does not start any work now.

Drive it from CI or a script

Every command accepts --json. Each exit code has its own meaning, so a script can branch on it. The codes are 1 runtime error, 2 usage, 3 forbidden, 4 not found, 5 precondition, 6 unavailable and 7 build failed. Code 6 means, for example, that onboarding is not finished.

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

You can bind a token to one project and give it only the scopes that the script needs. Then the automation has less authority than the person who created the token.

Let a coding agent do all of it

An agent can use the CLI as well as a person can. The ship init command and the hosted skill document are there for this purpose. Coding agents shows example hand-offs with Claude Code and Codex. An assistant that connects to the platform directly, and does not run commands in your repository, uses MCP instead.