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 specialised agents plans it, builds it, reviews it, deploys a preview, tests it against the acceptance criteria, and leaves a pull request ready for a human to merge.

Merging is always yours. Everything before it is what SHIP does.

Two ways to hand work over

The same pipeline runs either way. What differs is where the work comes from, and that is usually a question of who is handing it over.

Ticket to PR

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

This is the path for a product manager, a designer, or anyone who works in the tracker rather than in a terminal. The issue is the whole interface, so there is no CLI to install and no token to create. It works with Linear or GitHub Issues.

Agent to PR

You are already in your editor with a coding agent. You have just written a spec, or just finished a branch. You 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 is the path for developers. The hand-off creates the mission, so there is no ticket to open first. Your own coding agent can drive all of this for you, because SHIP ships a skill that teaches it how.

Both at once

Most teams end up using both, and a project does not have to choose. A mission filed from a ticket can be steered from the CLI, and a mission created from the CLI shows up 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 produces a plan. It is skipped when you hand over a plan yourself.
• 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 it.
• Reviewer reads the diff against the plan and raises 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, and it is skipped when a change has nothing to preview.
• QA exercises the acceptance criteria against that environment, or against the app built and served locally when there is no preview to deploy, and collects proof of what it checked.

A failing gate loops back to the builder with the feedback rather than ending the mission. Retry limits decide how long that goes on before a human is pulled in.

Get started

Point your coding agent at one URL:

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

It installs the CLI, writes the skill locally, and tells you what it needs from you. Full walkthrough: Getting started.

What you configure

Everything the agents do is configuration rather than code. You choose the harness and model each role runs on, and you can change that per project or per mission; one credential is enough to run a whole mission, and running a mixed fleet is a setting rather than a rewrite. You can extend how each role behaves with your own instructions, which layer on top of SHIP's charter for that role instead of replacing it. Retry and oscillation limits decide how long the agents keep working a problem before handing it back. And preview deploys run in your own delivery pipeline, so there is no cloud credential to hand us.

All of it lives in one ship.yml at your repository root, with a published schema your editor can validate against.

Built to be checked

Agents never hold your credentials. A sandbox is given a scoped, single-use callback token, while the platform holds the real keys and calls the provider on the sandbox's behalf.

Every run is on the record. SHIP persists the full agent session, the assembled prompt, token usage and cost before the agent reports back, then surfaces them per mission and per stage.

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