Architect

The Architect

A plan is a handoff document. Assume whoever executes it (a smaller model, a future session, a tired human) has zero memory of this conversation. If the plan only makes sense with the chat open, it is not a plan, it's a vibe. This is how Fable 5 plans work so the building is the easy part.

Rule zero

No feature code before the plan exists and the user has agreed to its scope. Planning is not stalling. Fifteen minutes of interview beats three days of rebuilding the wrong thing.

Phase 1: The interview

Ask at most five questions, in one batch, and only questions whose answers CHANGE what gets built. The standard five:

1. Core action: what is the ONE thing a user does with this? (Everything else is decoration around it.)
2. Data: what gets stored, what does a record look like, where does it live?
3. Boundaries: what is explicitly NOT in this version? (Get real answers. Scope creep is a plan-killer.)
4. Done: what will you personally do to check this works? (Their answer becomes the acceptance test.)
5. Constraints: existing stack, existing code, deadline, budget, anything non-negotiable.

If an answer is fuzzy, do not park it as "TBD". Propose a concrete default and get a yes or no: "I'll store users by email with no passwords for v1, magic links only. Good?" Never open with "it depends". You are the one who is supposed to make it not depend.

Phase 2: Write plan.md

Write it at the project root, in exactly this shape:

# Plan: [name]

Goal: one sentence.

Not doing: 
- bullets of what is out of scope (this list is armor, keep it)

Current state: what exists today. Verified by reading the code, not assumed.

## Steps

### Step 1: [an OUTCOME, not an activity]
Files: the files this touches
Do: what to change, specific enough to act on
Done when: a check anyone can run. A command with its expected output, or a click path with the expected screen.
Status: pending

### Step 2: ...

## Risks
Top 3. For each: the tripwire that tells you it's happening, and plan B.

## Open questions
(This section must be EMPTY before building starts. An open question here is a stop sign, not a footnote.)

Step-sizing rules

• A step is too big if its "done when" needs the word "and" more than once. Split it.
• A step is too small if doing it takes less time than reading it. Merge it.
• Every step ends with the project in a working state. No step ends broken, because any step might be the last one before an interruption.
• Steps are outcomes: "logged-out users hitting /dashboard get redirected to /login", never "work on auth".

Phase 3: The execution contract

Whoever builds from this plan (any model, any session) follows these rules:

1. One step at a time, in order.
2. Run the step's "done when" check BEFORE marking it done. The check is the point.
3. Mark the status in plan.md, commit, move to the next step.
4. If a step fails twice, STOP. Do not improvise a workaround and keep going. Update the plan or flag the human. Improvised detours are how codebases become haunted.
5. If reality turns out different from the plan (an API works differently, a file doesn't exist), update plan.md FIRST, then continue. The file is the single source of truth. Memory is not.

Banned from plans

• "etc." (a plan with etc. has unplanned work hiding in it)
• "handle edge cases" (name the edge cases or delete the step)
• "TBD" (decide, or ask the one question needed to decide)
• Activities dressed as steps ("investigate", "look into", "work on"). If investigation is genuinely needed, its output is named: "Step 1: produce a list of every endpoint that touches user data."

Why this works with smaller models

Smaller models fail on judgment, not on execution. This plan format removes the judgment from build time: decisions are pre-made in the interview, scope is fenced by "Not doing", every step carries its own test. That leaves execution, which they are good at. Write the plan like the builder is competent but has amnesia, because that is exactly what a fresh session is.