Introduction

What is SHIP?

SHIP is an agent platform that runs the software development lifecycle end to end. You hand over a piece of work, and a fleet of specialized agents plans it, builds it and reviews it. The agents then deploy a preview, test the change against the acceptance criteria and leave a pull request ready for a human to merge.

The merge is always your decision. SHIP does everything before it.

Two ways to hand work over

The same pipeline runs either way. The difference is where the work comes from, and that usually depends on who hands it over.

Ticket to PR

Someone files an issue and mentions @SHIP on it. The mission starts from the issue, reports its progress there and opens a pull request that closes the issue.

This path suits a product manager, a designer or anyone who works in the tracker and not in a terminal. The issue is the whole interface, so you do not install a CLI or create a token. It works with Linear or GitHub Issues.

Agent to PR

You are in your editor with a coding agent, and you just wrote a spec or finished a branch. Hand it over from there:

ship delegate plan --title "Rate-limit the search endpoint" --file docs/plan.md
ship delegate pr                 # review, test, and drive the branch you just pushed

This path is for developers. The hand-off creates the mission, so you do not open an issue first. Your coding agent can do all of this for you, because SHIP publishes a skill that teaches it how.

Both at once

A project can use both paths, so it does not have to choose. You can send instructions from the CLI to a mission that started from an issue. A mission that you create from the CLI shows on the same board, with the same logs, verdicts and costs. See Ways of working.

How a mission runs

work handed over → Planner → Builder → CI → Reviewer → Preview deploy → QA → PR ready to merge

• Planner reads the request, the repository and the acceptance criteria, then writes a plan. If you hand over a plan yourself, SHIP skips the Planner.
• Builder implements the plan in an isolated sandbox, runs your formatter, linter and tests before it pushes, and opens the pull request.
• CI is your own pipeline. When it fails, the Builder gets the failure back and works on a fix.
• Reviewer compares the diff with the plan and reports blocking and non-blocking findings.
• Preview deploy puts the change on a live environment, deployed by your own pipeline with your own credentials. You configure it per project. If a change has nothing to preview, SHIP skips this step.
• QA tests the acceptance criteria against that environment and collects proof of what it checked. If there is no preview to deploy, QA tests against the app built and served locally.

If a gate fails, the feedback goes back to the Builder and the mission continues. Retry limits decide how long the loop runs before SHIP stops and asks a human for help.

Get started

Point your coding agent at one URL:

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

The agent installs the CLI, writes the skill locally and tells you what it needs from you. Getting started has the full walkthrough.

What you configure

Everything the agents do is configuration, not code. You choose the harness and model for each role, and you can change them per project or per mission. One credential is enough to run a whole mission. A mixed fleet is a setting, not a rewrite.

You can extend how each role behaves with your own instructions. SHIP adds them after its own charter for that role and does not replace the charter. Retry and oscillation limits decide how long the agents work on a problem before they give it back to a human. The preview deploys run in your own delivery pipeline, so SHIP never needs a cloud credential from you.

All of it is in one ship.yml at your repository root. Your editor can validate the file against the published schema.

Built to be checked

Agents never hold your credentials. SHIP gives each sandbox a scoped, single-use callback token. SHIP keeps the real keys and calls the provider for the sandbox.

SHIP records every agent run. Before an agent reports back, SHIP stores its full session, the assembled prompt, the token usage and the cost. You can read them per mission and per stage.

Nothing is available only through the console. Every capability is in the API and the CLI. The console is one client of the same API that your agents call. Your own assistants can call it too, over MCP or directly.