Coding agents

A coding agent working in your repository can hand work to the fleet the same way you can. It installs the CLI, loads the skill document, and then delegate plan / delegate pr become things you can simply ask for in conversation.

This page covers the two agents the skill is tested against. An assistant that talks to the platform directly, rather than by running shell commands in your repository, connects over MCP instead.

Set the agent up once

Say this to the agent:

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

It fetches the document, installs @lets-ship/cli, 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 is stamped with the CLI version it was written by, so a later session can tell when it has fallen behind and re-fetch.

Claude Code loads that file as a skill automatically on the next session. Codex reads AGENTS.md; point it at the skill from there if you want it loaded without being asked:

## 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 have worked out an approach and written it down. You do not want the agent to implement it. You want the fleet to, so 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 runs:

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

It reports back the mission and a console link. The planner is skipped; the builder works from your spec.

If the plan names the files it expects to touch, the agent can pass them so 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 has made the change locally and pushed it. Review, CI and QA are work you would rather not supervise.

You: Open the PR and hand it to SHIP.

The agent opens the pull request itself (the platform never pushes or opens PRs for you), then:

ship delegate pr SHIP-412

--pr is auto-detected from the current branch when gh is available. From here the fleet reviews, tests and drives toward merge, and the agent can stop holding the context.

Scenario: review came back and you disagree

The reviewer asked for a change you do not want. The instinct is to re-run the mission; that is the one thing that will not work, because a re-run re-checks an unchanged PR against verdicts 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 reaches the agents and puts the builder back on the open pull request. The reply says what it recorded and what it will cause; a good agent reads that line before reporting success, because an instruction against a merged PR dispatches nothing and says so.

Scenario: this one needs a security review

The change makes an endpoint public, and the repository's normal reviewer conventions 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

extend keeps the repository's own reviewer conventions and adds the lane after them. Ask for replace only when the mission is genuinely a different job from the repository's normal review.

When not to delegate

• Mid-change. Finish or stop first, so the hand-off carries a complete artifact rather than a half-applied edit.
• When you have not written the decisions down. delegate plan builds what the spec says. A vague spec produces a vague diff, and the fastest way to waste a mission is to hand over thinking you have not finished.
• To send feedback. That is ship instruct, not a second delegation. Delegating again creates a second mission competing with the first.