Phaser

Reads

Everything above it: vision.json, feature_specs.json, stack.json, and — when they exist — code_review.json, ai_features.json, design/manifest.json, and design/mock.html. The stack arrives as the approved component list; the specs arrive per feature; the mock is cited by path for the coding agent to match. In a revision round, the code review of the implemented system and the delta from the vision.

Web search, if enabled, for the canonical documentation of every standard, protocol, or SDK a phase names.

Asks

Eight steps, in the prompt's order:

1. Analyze the inputs.
2. Clarify. If drafting would force a guess — a key feature's details, an integration target, the deployment shape, a conflict between vision and stack — Phaser asks, one question per turn, and only what it needs. If the inputs are complete, it skips this step. A question that presents options ends by asking which one; a question whose answer would add a dependency names the dependency in the option, so choosing it approves it.
3. Steel Thread. The simplest architecturally live version of the app. This is Phase 1.
4. Determine N. Each significant feature vertical is typically its own phase; more smaller phases are preferred over fewer large ones.
5. Draft phases. Title, summary, instructions, risk assessment, and verification per phase.
6. Present. The set, for your yes or your edits.
7. Revise. If you ask for changes, the affected phases are revised and the full list is presented again before any JSON is generated.
8. Output. On your yes, every phase is emitted at once as JSON, which Spec4 validates against the phase schema and renders into the Markdown phase files.

Stack fidelity. The stack is the approved component list. If a phase needs a component, library, or service not in it, Phaser may not add it on its own, not even when the choice seems obvious. It stops and asks — what it is, why it's needed, what it adds — and on your yes records a stack_addition in stack.json with the same join keys StackAdvisor uses. A companion an approved component can't run without — the client SDK for an approved managed service, a system binary an approved library invokes — is gathered with the others into a single confirmation rather than asked one at a time. StackAdvisor

Two checks before the set is yours. After the model emits a phase set, Spec4 validates it deterministically: every phase against the schema; the set for completeness, numbered 1 to k with none missing; and coverage — every MVP feature is declared by some phase, an excluded feature by none, and infrastructure is stood up no later than the first phase that needs it. A failure goes back to the model with the specific fault named, and you can reply try again or point at the phase to fix. What the plan deliberately doesn't build — deferred features, excluded ones — is listed under Not built by these phases so nothing drops silently.

Then, on a greenfield set, an advisory seam check: a second model call extracts a data-flow graph from the phases — which phase creates each table, which reads it; which defines each endpoint, which consumes it; which features each phase covers — and deterministic checks look for a table read before it's created, an endpoint called before it's defined, a feature no phase covers. Findings are shown alongside the ready phases. They never block, and they never trigger a retry.

Writes

phases/phase1.md through phase{k}.md. Each file is the phase as JSON frontmatter followed by the same content rendered as Markdown for the coding agent:

• Title and summary — what the phase does, and what it does not do yet.
• Feature specifications — the spec of every feature this phase builds, from feature_specs.json and ai_features.json, inlined verbatim by Spec4 and declared authoritative. The coding agent never reads a spec from a pointer.
• Tech stack — the entries routed to this phase from stack.json: every entry that serves a feature the phase declares, plus every foundational entry. Routed by Spec4, not chosen by the model.
• Instructions — numbered, one actionable step each, specific enough that a coding agent can't misinterpret them.
• Risk assessment — the likely execution bottlenecks and the places an AI coder tends to hallucinate, each with a mitigation.
• Verification — the exact command or observable that proves the phase is done, followed by the non-functional acceptance block: every goal a routed stack entry claims, threaded here by Spec4 from satisfies_nfr. Goals claimed only by foundational entries land in the final phase.
• References — the canonical documentation links, from live search.

The last phase's final instruction is touch .spec4/v{N}/IMPLEMENTED, appended by Spec4. Phase 1 of Spec4's own first round is quoted in full on the front page; the spec preamble and an NFR block from later phases are on the Artifacts page.

Buttons

Phaser depends on the mock and not the manifest, since it hands the mock to the coding agent by path.

Across rounds

Nothing carries forward. In a revision round Phaser is told to treat everything in the code review as built and in place, and to plan only the new or changed surface named in the delta. The new phases are numbered from 1 as a self-contained set; Phase 1 is an integration thread that wires the new surface into the existing code, not a from-scratch steel thread; no phases are emitted for unchanged features. AI features are partitioned by introduced_in_version, so only this round's are planned, and the coverage check looks only at those. The seam check is skipped, since a revision's graph is partial by design. Rounds

In Spec4's own rounds

6 calls, about 231k tokens, and $1.72 in v0; 4 calls, 189k, and $1.70 in v1; 4 calls, 242k, and $2.09 in v2 — seam checks included — all on claude-opus-5, the one agent Spec4's rounds always ran on a stronger model than the default. Phaser was the first or second largest line in every round because it holds every upstream artifact in context while it drafts. Its single largest call, the v2 draft, was 73k tokens over 4 minutes 18 seconds.