AI prototype to production: get a reviewed, tested pull request

An AI prototype reaches production when it passes the same checks as any other change. Those checks are a plan with acceptance criteria, your CI, a review against your repository's rules, a preview and a test with proof. Then a person merges it. SHIP runs those checks as one mission today. You start it from an issue, from a spec with ship delegate plan, or from the prototype's pull request with ship delegate pr. A workspace where non-engineers describe and change prototypes in SHIP is in early access.

Compare a prototype with a production change

A prototype answers one question: does the idea work? A production change must answer more questions, and each one needs a check that the author of the change did not write. The table lists those checks and where SHIP runs each one, in the order of the SHIP introduction.

A failed check sends the work back to the Builder with the feedback. The mission stops by itself after two rounds that fail the same way, and it shows Needs attention with the reason (Retry limits).

Write the prototype up as an issue

An issue is the right start when the person with the idea works in your tracker. Write what the prototype does and how you will know that it does it. Acceptance criteria written as checkboxes are what QA tests against, so make them exact.

Export bookings as CSV for a date range

The prototype shows an Export button on the bookings page.

- [ ] GET /api/export?type=bookings returns CSV and requires a signed-in session
- [ ] Optional from and to parameters keep only bookings inside the range, both ends inclusive
- [ ] Columns, in order: Starts, Class, Member, Email, Status

On a Linear project, assign the issue to SHIP. On GitHub Issues, comment @SHIP on it from an account with write access to the repository (how work reaches SHIP). The mission reports its plan, its review and its test result on the issue. Nobody who files the issue needs a SHIP login.

Hand over a spec from your terminal

A spec is the right start when you already know how the prototype should behave. Save it as Markdown, with the same acceptance criteria, and hand it over:

ship delegate plan --title "Export bookings as CSV" --file docs/export-spec.md

SHIP skips the Planner and builds from your spec (Command reference). If you give --title and no issue, SHIP creates the issue for you and starts the mission on it.

Send the prototype's pull request for review

An AI app builder that pushes to GitHub often leaves you with a branch and a pull request. Open the pull request first, then run this command from the branch:

ship delegate pr

If the GitHub CLI is installed, the command finds the pull request from the branch. If it is not installed, pass --pr with the number. You do not need an issue: SHIP names the mission after the pull request. If CI fails, the Builder fixes the failure first. Then the Reviewer reads the diff, and QA tests the change. The Builder pushes its fixes to the same branch, and SHIP does not open a second pull request (Agent to PR).

To add a concern for this one prototype, such as a security pass, give the Reviewer extra instructions:

ship delegate pr --pr 418 --prompt-file security-review.md --prompt-mode extend

With --prompt-mode extend, the Reviewer reads your repository's own review rules first and your file after them.

Hold the mission for an engineer

Checkpoints let an engineer read a stage's result before the mission continues. Set them in ship.yml at the repository root:

# yaml-language-server: $schema=https://letsship.ai/schema/ship.yml.json
version: 1

deployments: {}

agents:
  planner:
    checkpoint: true
  reviewer:
    checkpoint: true

With this file, every mission holds after the plan and after the review (Human in the loop). A reply on the issue with the change you want sends the agents back. QA cannot be a checkpoint, because the pull request at the end is already the last gate.

Three more controls apply to every prototype, and you do not set them:

• The Reviewer and QA read their instructions from your main branch, never from the pull request. A prototype cannot change the rules that SHIP uses to check it (Agent prompts).
• SHIP blocks a change under .github/workflows/ that nobody asked for, before the commit exists (Connect GitHub).
• A preview deploys only through your own delivery pipeline, with your own credentials (Deployments).

Read the proof, then merge

When the mission finishes, the issue or the mission page holds the plan, the review verdict and the QA verdict. The mission's artifacts hold what QA checked, such as a trace of the test session or a screenshot of the change. From a terminal, ship status prints the stage, the review and test state and the pull request.

SHIP marks the pull request ready after review and QA, and the merge is yours. Auto-merge is off unless you turn it on for a project or a mission. Each mission also has a spend limit. A mission stops at $5 by default, and pauses at 2 credits or 6 agent-hours until a member of your organization approves more (LLM credentials).

Open prototyping to people outside engineering

Today, a product manager or a designer starts a prototype from an issue, and the steps above take it to a pull request. A workspace where non-engineers describe a prototype and change it in SHIP, without a tracker, is in early access. Governed prototyping describes it, and every prototype from it will go through the same checks that this page describes.