How to take a raw idea and turn it into a reviewed spec and a build-ready implementation plan, without writing a line of production code until the thinking is done.
This guide accompanies Spec-Driven Development for Dummies: Go Beyond Vibe Coding, a free Maven lightning lesson:
maven.com/p/424204/spec-driven-development-for-dummies-go-beyond-vibe-coding
Future free sessions are on the calendar at zeroemdashes.com/maven.
The fastest way to waste an afternoon is to start coding a feature you haven't designed. Unexamined assumptions are cheapest to fix while they're still words on a screen, and most expensive once they're baked into files and tests.
This guide walks the exact path one session took: from "let's brainstorm some new skins for my game" to a committed spec and a ten-task, test-driven implementation plan. The example is a visual skin for a Flutter game, but the process is the point, not the skin.
Before any code, a structured back-and-forth that turns a vague idea into a concrete design. The rule that makes it work: one question at a time. Multiple-choice where possible, open-ended where needed, always building on the last answer. The process skill runs first and decides how to approach everything after it.
The idea started as "brainstorm new skins." The first direction offered (elemental, urban, organic, dark-fantasy) got rejected outright. Then "something blue, underwater", but a near-identical skin was already specced, so the next question surfaced that overlap instead of charging ahead. That redirected to green / nature → jungle → dappled canopy. Each turn narrowed by exactly one decision.
A visual companion: a local browser page where mockups, palette swatches, and side-by-side options render live. It's a tool, not a mode. Accepting it means it's available. Every question still gets decided on its own merits.
Theme clusters, jungle moods, four Snark designs, three ground treatments, and the final three-part design were all shown as rendered mini-scenes with real colour. Picking became pointing at a card. Scope and approach questions, like which background technique to use, stayed in the terminal as plain trade-off lists.
Once the design is agreed section by section, it gets written down as a real document and committed to git. The spec is the contract: colour values, file names, behaviours, and acceptance criteria, all explicit. No "TBD", no "handle edge cases."
The validated design became a dated spec file with a palette table, per-component rendering notes, a full file list, and a checklist of acceptance criteria. It was committed before any review so there was a clean baseline to diff against.
An immediate, manual pass over the spec you just wrote, against a fixed checklist. Cheap, fast, and it catches the obvious before a heavier review spends effort on it.
The self-review confirmed the two pollen systems were intentionally distinct, all colours were explicit hex, and scope was a single skin. It read clean, which is exactly the point. The cheap pass clears the deck so the expensive pass finds the real problems.
A specialist agent reads the spec and the real source files it depends on, then reports blocking issues versus suggestions. It has fresh context and no attachment to the spec, so it checks claims the author takes for granted.
An engineering-review agent read the spec alongside the actual interface and the reference implementation. It returned a YELLOW verdict with three hard blockers, every one of them a thing that reads fine but cannot be built as written.
All three were fixed in the spec and re-committed as a separate diff, so the correction history is legible.
The corrected spec becomes a step-by-step implementation plan written for someone with zero context. Bite-sized tasks, test-driven, full code in every step, a commit at the end of each. No "implement the rest" hand-waving.
The spec became a ten-task plan, each task a single file or behaviour, every step carrying the actual code to paste. A final self-review against the spec caught two colour overrides the plan had missed and added them before the plan was committed.
The idea becomes a chain of committed, reviewable files. Pick up the thread anywhere.
A human reads and approves the two artifacts that carry every decision, the spec and the plan, before any code is built. The AI drafts. You decide.