README

Free sample

The nine stages, the rules that make it work, and when the pipeline is overhead.

README.md · 2.3 KB

README.md

# Spec-to-Ship

The chained prompts that take a one-line idea to a reviewed pull request.

Agents fail on ambiguity long before they fail on syntax. This pipeline
removes the ambiguity first, then keeps the work bounded stage by stage.

## The pipeline

    01  Intake        Is this one task? Is it clear? What is missing?
    02  Spec          Write down what "correct" means. Adversarially.
    03  Risk pass     What breaks that is not obviously related?
    ── GATE ── a human answers the open questions ──────────────
    04  Plan          Files, order, verification per step
    05  Scaffold      Types, signatures, failing tests — no logic
    ── GATE ── the shape is agreed before logic exists ─────────
    06  Implement     One step at a time, verified between
    07  Self-review   Four passes, adversarial, in a fresh context
    08  Test backfill Behaviour, not coverage
    09  PR writeup    What changed, why, how it was verified

## Rules that make it work

**Each stage ends with output you read.** If you skip reading a stage's
output, delete that stage — it is costing tokens for nothing.

**Gates are where humans decide.** Two of them. Everything before gate 1 is
about surfacing decisions; nothing after gate 2 changes the shape.

**A new context per stage from 06 onward.** Carrying the spec conversation
into implementation is the single biggest cause of drift.

**Any stage can send you backwards.** Discovering in 06 that the spec was
wrong means going back to 02, not patching forward.

## When not to use this

Small changes. A typo fix, a one-line config change, a rename. The pipeline
is overhead below roughly "half a day of human work". Use `/repro` and a
scoped request instead.

## Using it

Each `pipeline/NN-*.md` is a prompt. Paste it, fill in the bracketed part,
read the output, decide whether to continue.

`templates/` holds the artefacts the stages produce — commit these to the
repo alongside the code. A spec that lives in a chat window is not a spec.

`examples/` walks three real shapes of work end to end. Read one before
running the pipeline for the first time; it is faster than reading the
stages in the abstract.

## Licence

Yours to use in any project, personal or commercial. Do not resell or
republish the files themselves.

That was one of 19 files

The rest of Spec-to-Ship is written the same way. $49 once, yours permanently, 14-day refund.

# Spec-to-Ship The chained prompts that take a one-line idea to a reviewed pull request. Agents fail on ambiguity long before they fail on syntax. This pipeline removes the ambiguity first, then keeps the work bounded stage by stage. ## The pipeline 01 Intake Is this one task? Is it clear? What is missing? 02 Spec Write down what "correct" means. Adversarially. 03 Risk pass What breaks that is not obviously related? ── GATE ── a human answers the open questions ────────────── 04 Plan Files, order, verification per step 05 Scaffold Types, signatures, failing tests — no logic ── GATE ── the shape is agreed before logic exists ───────── 06 Implement One step at a time, verified between 07 Self-review Four passes, adversarial, in a fresh context 08 Test backfill Behaviour, not coverage 09 PR writeup What changed, why, how it was verified ## Rules that make it work **Each stage ends with output you read.** If you skip reading a stage's output, delete that stage — it is costing tokens for nothing. **Gates are where humans decide.** Two of them. Everything before gate 1 is about surfacing decisions; nothing after gate 2 changes the shape. **A new context per stage from 06 onward.** Carrying the spec conversation into implementation is the single biggest cause of drift. **Any stage can send you backwards.** Discovering in 06 that the spec was wrong means going back to 02, not patching forward. ## When not to use this Small changes. A typo fix, a one-line config change, a rename. The pipeline is overhead below roughly "half a day of human work". Use `/repro` and a scoped request instead. ## Using it Each `pipeline/NN-*.md` is a prompt. Paste it, fill in the bracketed part, read the output, decide whether to continue. `templates/` holds the artefacts the stages produce — commit these to the repo alongside the code. A spec that lives in a chat window is not a spec. `examples/` walks three real shapes of work end to end. Read one before running the pipeline for the first time; it is faster than reading the stages in the abstract. ## Licence Yours to use in any project, personal or commercial. Do not resell or republish the files themselves.