Idea → Product

You already have the idea. The trouble is that it lives in your head as a feeling, and an agent cannot read feelings. It reads text. Everything you leave out, it fills in for you — confidently, in code, in about ninety seconds.

This module is one page of writing and one prompt. It is the cheapest work in the whole course, because everything you get wrong here gets multiplied by every line the agent writes afterwards.

The agent builds what you wrote, not what you meant

Ask for “a sign-up page for our event” and you will get one. You will also get a login form nobody asked for, a phone-number field you did not want, an invented event with an invented date, and a save button that writes to a variable which disappears when the tab closes. None of that is the model malfunctioning. Each one is a decision you did not make, so it made the decision for you, in a fraction of a second, without mentioning it.

Module 3 gave you the habit: decide before you prompt. This module gives you the artifact. A decision you made in your head is not a decision the agent can read, and a decision you made in a chat window three sessions ago is already gone. One page, on disk, present at the start of every build — that is the whole trick.

Nothing in the right-hand column needs a bigger model. It needs a page that already existed when the session started.

Five questions that fit on one page

A PRD is a product requirements document. The name is corporate; ignore the name. For what you are building this month it is one page, five answers, written before anything exists, saved as PRD.md next to your code. Some tools and some later modules call the same file SPEC.md. Same page, different label — pick one name and use it everywhere.

Problem. One sentence about the pain, not the feature. “Seats fill up in a Telegram thread and nobody knows who is actually coming” is a problem. “We need a sign-up form” is already a solution, and it smuggles in decisions you have not examined yet.

User. Specific enough to picture one person. A student in Astana, on a phone, on mobile data, deciding right now whether she has a seat. Her constraints — small screen, slow connection, no patience — are requirements wearing a disguise.

The one job. Borrow the jobs-to-be-done framing here: people do not want your product, they hire it to get a job done, and they fire it the moment something does that job faster. Your user is not hiring a sign-up page. She is hiring certainty that she has a seat. Write that job as one sentence in her words. If the sentence contains the word “and”, you probably have two jobs — keep the one that hurts more and push the other into the not-building list.

Definition of done. One or two sentences describing something a stranger or a script could run to prove the thing works. This is the hardest of the five, so it gets its own section below.

Not building. The things you are deliberately leaving out. It is the section people skip, and the one that pays.

The most valuable section is the one about what you will not build

Every line in that list is a decision the agent no longer gets to make on your behalf. It is also the only part of a PRD that gets shorter as you get better at this, because you learn which things actually needed to be there.

A first build you can finish in one sitting looks roughly like this: one page, no login, no payments, no admin panel, data kept in the browser or in one file, deployed by dragging a folder. Everything else is version two. And when the plan the agent hands back is bigger than you expected, the fix is unglamorous: cut the must-have list in half and ask again.

Write “done” in words a stranger could act on

Module 3 argued that done has to be checkable. This is where that lands on the page, in the exact sentences you type.

Weak. The sign-up should feel fast and look clean. An agent will cheerfully claim both, and you have nothing to argue with.

Strong. A person who has never seen the page opens the link on a phone, types a name and an email, presses one button, and sees a confirmation. You open the list and the name is there. Two people signing up in the same second do not overwrite each other.

Three sentences, no adjectives, each one a thing somebody can do standing in front of you. Notice the last one — it is the clause nobody writes and the bug everybody ships. Anthropic’s Claude Code guide describes a good spec the same way: self-contained, naming the files and interfaces involved, stating what is out of scope, and giving one end-to-end verification step. Your one page can carry all three.

Hand it over: read, ask, plan, do not code

Here is the hand-off. It is short, and it is the reason the rest of the page was worth writing.

Read PRD.md. Do not write any code yet.

1. Tell me back, in five lines, what you understood: the problem, the user,
   the one job, my definition of done, and what is out of scope.
2. Ask me exactly 3 questions — the three points in the PRD where guessing
   wrong would cost the most. One at a time.
3. After I answer, write PLAN.md:
   - ordered steps, each small enough to verify on its own
   - the files each step creates or changes
   - the check that proves that step works
   - what you will NOT touch
   - any assumption you are making that I should confirm

Stop there and wait for my approval. If a step turns out to be wrong while you
are implementing it, stop and update the plan instead of improvising.

Three questions, not “any questions”. A hard limit forces the agent to rank, and the three it picks tell you which parts of your page are thin — free information about your own thinking. You review a twenty-line plan instead of a four-hundred-line diff, which is the entire return on the page you just wrote. Module 7 runs this prompt against a real agent, in plan mode, on your own machine.

Spec-driven development is a dial, not a religion

When people turn this one page into a whole toolchain, they call it spec-driven development. GitHub’s Spec Kit is the best-known version: open source under MIT, Python 3.11 or newer, installed with uv tool install specify-cli and started with specify init my-project --integration copilot. Its commands run in order — /speckit-constitution for project principles, /speckit-specify for what and why, /speckit-plan for the technical approach, /speckit-tasks for work items, /speckit-implement to build, and /speckit-converge to re-check progress against the spec, repeating implement and converge until it reports that it has converged (github.com/github/spec-kit). It moves fast — seven releases landed between 1 and 21 September 2026 — so read the README, not last year’s tutorial.

You do not need any of that today. Module 3 gave you the sizing rule; Birgitta Böckeler’s other finding is the one that matters here. Testing these toolkits, she reported that the elaborate process created a false sense of control, because the agent still skipped some instructions and over-applied others (martinfowler.com, 15 Oct 2025). More markdown is not more certainty. One page you genuinely reread beats six templates you generated and skimmed.