Coding agents

A coding agent in your repository can send work to the SHIP agent team the same way that you can. The agent installs the CLI and the SHIP skills. After that, you can ask for delegate plan, delegate pr or any other SHIP command in the conversation.

This page covers the two agents that the skills are 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 setup document and installs @lets-ship/cli. Then it runs ship init to write the SHIP skills into .claude/skills/, and asks you for a SHIP_API_TOKEN. Each copy has a stamp with the version of the CLI that wrote it. A later session can then see when a copy is older than the CLI and write it again.

You can also install the skills with the skills CLI, from the website or from GitHub:

npx skills add https://letsship.ai
npx skills add letsship/skills

The skills include the setup skill, so the agent can still install the CLI and ask you for a token.

Claude Code loads those files as skills automatically in the next session. Codex reads AGENTS.md. If you want Codex to load the skills without a request from you, refer to them in AGENTS.md:

## Delegating to SHIP

When asked to hand work to SHIP, follow .claude/skills/ship-delegate/SKILL.md.
For any other SHIP task, read the matching .claude/skills/ship-*/SKILL.md first.

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 SHIP agent team 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 agent team 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 agent team 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.