Coding agents

A coding agent in your repository can send work to the fleet the same way that you can. The agent installs the CLI and loads the skill document. After that, you can ask for delegate plan or delegate pr in the conversation.

This page covers the two agents that the skill is tested with. An assistant that connects to the platform directly, and does not run shell commands in your repository, uses MCP instead.

Set the agent up once

Say this to the agent:

set up https://letsship.ai/SKILL.md

The agent fetches the document and installs @lets-ship/cli. Then it runs ship init to write a local copy at .claude/skills/ship-delegate/SKILL.md, and asks you for a SHIP_API_TOKEN. The local copy has a stamp with the version of the CLI that wrote it. A later session can then see when the copy is older than the CLI and fetch it again.

Claude Code loads that file as a skill automatically in the next session. Codex reads AGENTS.md. If you want Codex to load the skill without a request from you, refer to the skill in AGENTS.md:

## Delegating to SHIP

When asked to hand work to SHIP, follow .claude/skills/ship-delegate/SKILL.md.

Scenario: you just finished planning together

You and the agent agreed on an approach and wrote it down. You do not want the agent to implement it. You want the fleet to implement it, so that the agent stays free.

You: Write that plan to docs/rate-limit.md and delegate it to SHIP against SHIP-412.

The agent writes the file. Then it runs:

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

The agent reports the mission and a console link. The fleet skips the Planner, and the Builder works from your spec.

If the plan names the files that it expects to change, the agent can pass them, so that the Builder does not have to guess:

ship delegate plan SHIP-412 --file docs/rate-limit.md --file-plan docs/rate-limit.files.json

Scenario: the agent finished a branch and you want it merged

The agent made the change locally and pushed it. You do not want to supervise review, CI and tests.

You: Open the PR and hand it to SHIP.

The agent opens the pull request itself, because SHIP opens no pull request for a branch that you hand over. Then it runs:

ship delegate pr SHIP-412

If gh is available, ship detects the pull request for --pr from the current branch. From this point, the fleet reviews and tests the pull request and makes it ready for you to merge. The agent no longer needs to keep the context.

Scenario: review came back and you disagree

The Reviewer asked for a change that you do not want. You may want to re-run the mission, but a re-run is the one thing that does not work. A re-run checks the unchanged pull request again against the verdicts that it already has, and correctly does nothing.

You: Tell SHIP to keep the current Node range and override nopt instead.

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

The instruction goes to the agents and starts the Builder again on the open pull request. The reply tells what SHIP recorded and what the instruction will cause. A good agent reads that line before it reports success. An instruction to a merged pull request starts no agent, and the reply says so.

Scenario: this one needs a security review

The change makes an endpoint public, and the repository's usual conventions for the Reviewer do not cover that.

You: Delegate the PR, but have the reviewer go over it for security as well.

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. Ask for replace only when the mission is a different job from the repository's normal review.

When not to delegate

• Do not delegate in the middle of a change. Finish the change, or stop work on it, so that the hand-off contains complete work and not a half-applied edit.
• Do not delegate before you write down the decisions. The delegate plan command builds what the spec says, and a vague spec produces a vague diff. The fastest way to waste a mission is to delegate decisions that you did not make yet.
• Do not delegate to send feedback. Use ship instruct for feedback. A second delegation creates a second mission that competes with the first one.