Step 1
Draft the spec where you work
Write it as one Markdown file, in your own template or from a spec framework such as Spec Kit. Spell out the decisions, and list the acceptance criteria on the issue as a checklist.
Spec-driven development
Turn the spec you wrote into a verified pull request
Hand SHIP the spec you already wrote. Its agents build what you decided, then review and test the pull request with your spec in hand.
- For
- Engineers and tech leads who write the spec before the code.
- Instead of
- Implementing your own spec by hand, or supervising a coding agent while it does.
Answer 4 questions to request access. SHIP is invite-only for now.
ship delegate plan SHIP-412 --file docs/plan.mdHow it works
Write the decisions down once
Step 2
Delegate it in one command
Run ship delegate plan with the file and an issue, or with --title to create one, from your terminal or your coding agent. Add --file-plan to name the files the change should touch.
Step 3
Merge what matches the spec
Your CI runs, the Reviewer reads the diff with your spec in hand and flags where it departs, and the Tester verifies the issue's acceptance criteria. The pull request is ready for you once all three pass.
Capabilities
Keep the thinking yours
Skip the Planner when the plan is done
The Builder implements your decisions instead of re-deriving its own, so the thinking stays with you and the typing is what you delegate.
Name the files a change should touch
Pass a file plan beside the spec with --file-plan, and the Builder scopes its edits to the files you listed instead of choosing its own.
Add instructions for one mission
Pass --prompt-file with the spec to give the Builder extra instructions for that mission only. Add --prompt-mode extend to keep your repository's own conventions for the role.
Compare two agents on the same spec
Hand the same spec over as two missions with different --harness or --model flags, and read each mission's cost, duration and outcome.
Correct a mission without restarting it
Send an instruction with ship instruct, and the Builder picks the open pull request back up with your correction in hand.
FAQ
Frequently asked questions
What is spec-driven development?
Spec-driven development means writing the decisions and acceptance criteria down before any code, then building and checking the change against that written spec. SHIP takes the spec from there: its agents build it, review the diff and test the pull request.
Which spec formats does SHIP accept?
Any Markdown file: ship delegate plan --file reads it from your machine and hands it to the Builder as written. One file goes per mission, so a spec framework's output works once the parts you want built are in the file you pass.
What if my spec is vague?
SHIP builds what the spec says, so a vague spec produces a vague diff. When the decisions are not made yet, file the issue without a spec and let the Planner write the plan, with a planner checkpoint to hold it for you to read before anything is built.
Can my coding agent hand the spec over?
Yes: tell Claude Code, Codex or another coding agent set up https://letsship.ai/SKILL.md once, and handing over a spec becomes something you ask for in the conversation. The agent writes the file and runs ship delegate plan for you.
Do I need an issue to hand over a spec?
No: ship delegate plan with --title and --file creates the mission and starts it in one call. In a project with Linear or GitHub Issues, SHIP files the issue for you, and with no tracker the mission lives in the console.
Where do I put the acceptance criteria?
In a project with Linear or GitHub Issues, put them on the issue as a checklist under an Acceptance criteria heading: the Tester gates the pull request on those and reads your spec as the plan to follow. Criteria written only inside the spec file are read as part of that plan, so a departure from it is flagged rather than failed.
Hand over your next spec
Install the CLI and hand over the spec you already wrote.
Start your first mission
Answer 4 questions to request access. SHIP is invite-only for now.