The earlier chapters each left you with a piece: user stories, a scope line, the app's parts, its data, its non-functional targets. Scattered across notes and your head, those pieces are useless to an agent that reads before it builds. This chapter assembles them into one short document, the spec, that your agent works from.
A spec is the one document your agent builds from1.6.1
A spec is a single short document describing what the software must be and do. If you have heard the term "PRD", short for product requirements document, that is the same idea under a heavier name.
Your agent needs it as its single source of truth: the one thing it reads before building, so it does not guess and invent details you never wanted. Without it, every ambiguity becomes a coin flip you did not get to call.
Short and living, not forty pages1.6.2
A spec is not an exhaustive contract you write once and freeze. It is a working document you keep tight and update as you learn.
| Forty-page document | Living spec |
|---|---|
| Written once, out of date by week two | Edited whenever scope or data changes |
| Covers every edge case up front | Covers the shape; details emerge in the build |
| Nobody rereads it | Short enough to reread before each task |
Aim for something you and the agent can both hold in your head. A page or two beats a chapter nobody keeps current.
Assemble the sections you already have1.6.3
Each section maps to a Plan chapter you already worked through. You are not writing new material here, you are collecting it.
- Problem and audience: the problem and who it is for.
- Scope: the MVP as must-have user stories.
- Main pieces: the app's components and its modular shape.
- Data model: the entities and how they relate.
- Non-functional targets: speed, security, and scale you committed to.
Template:
# [Product name] ## Problem & audience ## Scope (MVP user stories) ## Main pieces & structure ## Data model ## Non-functional targets
Keep it in the repo, next to the code1.6.4
Put the spec in the project itself, as a plain markdown file the agent can open every time. A spec living in a chat window or a separate doc is one your agent cannot reliably read.
Keeping it beside the code means every edit to scope or data lands in the same place the build happens. The spec and the software drift apart the moment they live in different homes.
Do this now: create spec.md in your project and fill the five section headings above with what you produced in the earlier chapters. A later chapter turns this spec into instructions your agent builds from.
