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.
1.7.1A spec is a document your agent builds from
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.
1.7.2Short and living, not forty pages
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.
1.7.3Assemble the sections you already have
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
1.7.4Keep it in the repo, next to the code
Put the spec in the project itself, its repo (the folder that holds all your code), 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.
This prompt assembles the spec from what you already wrote:
Act as a senior engineer assembling my spec. Pull the
pieces I already have (user stories, MVP scope, the five
components, the data model, the non-functional targets)
into one short spec.md in my specs folder. Keep it tight
and skimmable, a living document, not forty pages.
My pieces (paste them, or point to the files in specs):
Do this now: paste the prompt, point your agent at your specs folder, and let it assemble spec.md. A later chapter turns this spec into instructions your agent builds from.
