# Turn the spec you wrote into a verified pull request

> Spec-driven development with AI agents: hand SHIP your Markdown spec in one command and get back a pull request built to it, reviewed and tested.

Available now, for developers.

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.

Hands your spec to the Builder as written and skips the Planner. No issue yet? Pass --title instead of SHIP-412.

```
ship delegate plan SHIP-412 --file docs/plan.md
```

## Write the decisions down once

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.
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.
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.

## 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.

## 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. [CLI capabilities](https://letsship.ai/docs/cli/capabilities)

### 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. [Coding agents](https://letsship.ai/docs/cli/coding-agents)

### 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.

Source: https://letsship.ai/platform/spec-driven-development