01 · Intake

Free sample

Is this one task? What is the smallest useful version? Is the pipeline even worth it?

pipeline/01-intake.md · 2.0 KB

pipeline/01-intake.md

# Stage 01 — Intake

**Goal:** find out whether this is one task, and what is missing, before
spending anything on it.

**Output:** a short triage. No spec, no plan, no code.

---

## Prompt

```
I want to build: [one or two sentences, however vague]

Do not write a spec, a plan, or any code. Answer only these:

1. IS THIS ONE TASK?
   If it is more than one, split it and list them in dependency order.
   For each, say whether it could ship independently.

2. WHAT IS THE SMALLEST USEFUL VERSION?
   The subset that delivers real value on its own. Be aggressive — I would
   rather ship a third of this and learn something.

3. WHAT DO YOU NEED FROM ME?
   Facts you cannot get from the codebase: product decisions, external
   constraints, access, existing behaviour I have not described.
   Ask questions, do not guess at answers.

4. WHAT ALREADY EXISTS?
   Search the codebase for anything that solves part of this. Quote file and
   line. If something close exists, extending it is usually right.

5. IS THE PIPELINE WORTH IT?
   If this is small enough that a scoped single request would do, say so.
   I will take that answer.
```

---

## Reading the output

**If it split the task**, run the pipeline on the first piece only. Do not
run it on all of them in parallel; the later pieces will change once the
first one is real.

**If question 3 has more than about five items**, the request was too vague.
Answer them and re-run intake rather than pushing forward.

**If question 4 found something close**, read that code yourself before
continuing. Extending an existing thing needs a different spec than building
a new one.

**If question 5 says the pipeline is overkill**, believe it. Skipping
straight to a scoped request is the correct outcome about a third of the time.

## Common failure

Answering the questions in your head instead of in writing. The written
answers become the input to stage 02, and vague answers there produce a vague
spec, which produces exactly the outcome the pipeline exists to prevent.

That was one of 19 files

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

# Stage 01 — Intake **Goal:** find out whether this is one task, and what is missing, before spending anything on it. **Output:** a short triage. No spec, no plan, no code. --- ## Prompt ``` I want to build: [one or two sentences, however vague] Do not write a spec, a plan, or any code. Answer only these: 1. IS THIS ONE TASK? If it is more than one, split it and list them in dependency order. For each, say whether it could ship independently. 2. WHAT IS THE SMALLEST USEFUL VERSION? The subset that delivers real value on its own. Be aggressive — I would rather ship a third of this and learn something. 3. WHAT DO YOU NEED FROM ME? Facts you cannot get from the codebase: product decisions, external constraints, access, existing behaviour I have not described. Ask questions, do not guess at answers. 4. WHAT ALREADY EXISTS? Search the codebase for anything that solves part of this. Quote file and line. If something close exists, extending it is usually right. 5. IS THE PIPELINE WORTH IT? If this is small enough that a scoped single request would do, say so. I will take that answer. ``` --- ## Reading the output **If it split the task**, run the pipeline on the first piece only. Do not run it on all of them in parallel; the later pieces will change once the first one is real. **If question 3 has more than about five items**, the request was too vague. Answer them and re-run intake rather than pushing forward. **If question 4 found something close**, read that code yourself before continuing. Extending an existing thing needs a different spec than building a new one. **If question 5 says the pipeline is overkill**, believe it. Skipping straight to a scoped request is the correct outcome about a third of the time. ## Common failure Answering the questions in your head instead of in writing. The written answers become the input to stage 02, and vague answers there produce a vague spec, which produces exactly the outcome the pipeline exists to prevent.