Try this if
- You can describe what you want to build in a paragraph, including who it's for and what they do today instead.
- You're about to start a new project, and your agent will build from whatever you manage to tell it in the first session.
- You have a brief, notes or a long message about the idea and want it turned into requirements without saying it all again.
- You want the decisions you've already made numbered with a reason each, and the things you don't know yet named.
- Skip this recipe to edit a requirements document you already have.
You have an idea you can explain in a minute, so you open your agent and start building. Each session it fills the gaps you never talked about with a reasonable guess, and each guess is a decision nobody made on purpose.
A few weeks later the agent builds something you're sure you never asked for, and you can't show it what you did ask for. There's nothing to check the work against, so you can't tell whether the agent drifted or your own plan did.
What fixes it is being asked. Something interviews you about what you're making, one topic at a time, pushes on the parts that are thin, and writes the answers into a requirements document. That document becomes the record the project is built from, and the thing you and every later agent check the work against.
/prd-creator writes that document, known as a product requirements document, or PRD. Its first question changed after a test run. It was built to ask for your brief every time rather than quietly absorb it, and on that run it asked cold for what a thorough brief already answered. Now it drafts each answer from the brief and shows you the draft. Another run collided with a requirements file that already existed, which is why it now asks before writing over one.
It asks one topic at a time and argues with the thin parts
The recipe at the bottom of this page runs the same interview as one prompt you paste.
It starts with what you've already written, whether that's a brief, notes or a long message you sent someone. If it can see your project it looks for one and offers it by name without opening it, and it reads only once you say yes. From then on, where your material answers a question, it drafts the answer and shows you the draft to correct. It asks cold only where the material is thin, because asking for something your own brief already says reads as not having read it.
It works through eight topics in order. The order matters, because each one leans on the answers before it.
- What you already have.
- What the thing is, who the first version is for and what those people do today instead.
- The main thing a person does with it, as steps.
- What's in the first version, what you cut and what waits for later.
- What it's built with, only where you've actually decided.
- A read-back of your decisions.
- Brand and voice, if people read its words.
- How you'll know it works.
One topic at a time, and a summary before it moves on. It asks three questions a turn at most, and only one if the question is open-ended. After each topic it tells you in a few sentences what it captured and waits, so you correct a misunderstanding while the topic is still open rather than in the finished file.
It argues with you, inside a hard line. Before it asks you to choose, it tells you what the choice changes, because a decision you can't weigh gets an answer that isn't really yours. Where an answer is vague or contradicts something you said earlier, it says so and names where it would land. If a later answer contradicts your notes, it puts that to you as one question. It builds your version at its strongest before testing it. What it never does is pick your direction. It can attack a weak success measure, but it can't propose a strategy you didn't choose. And if you ask it to skip the questions and just write something from your notes, it says no, because the questions are where the document gets its value.
Your decisions get written down while you talk
It keeps two lists you don't see. Every time you say something that locks a future choice, like no accounts in the first version, it writes that down with a one-line reason and says nothing. Every time you say you don't know something, that goes on the other list. Stopping to ask "shall I record that" after every sentence would turn the conversation into an approval queue.
You see the list as one numbered batch. Partway through, it reads the whole list back and you confirm, edit or drop each one. Then it asks what you've committed to that it missed. A decision you make after that point gets confirmed in a sentence when you make it and joins the list.
It doesn't record your vague yes to its idea as your decision. If it recommends something and you say "sure," it writes that down as an open question with its recommendation attached. The document is meant to record what you chose, and a shrug at a suggestion isn't a choice.
Nothing is written until you approve the outline
It shows you the outline first. It names every section in plain words, says which ones it's leaving out and why, and waits for you to say go.
It flags what shouldn't be in a shared document. Things like a coworker named next to a criticism, a customer tied to something that went wrong or a date nobody has announced. A requirements document gets passed around, so each one is put to you, and you decide whether it stays, gets reworded or comes out. It never removes one on its own.
It won't write over a document you already have. If there's already a requirements file where it would write, it shows you what's different and asks, and it leaves the file alone if you don't answer clearly.
The section names are fixed. They stay as written so any agent that reads the document later can find each part by name. The decisions are numbered so they can be copied whole into a decisions log, the running file where a project records each choice and why it was made.
It tells you when you don't need the whole thing. Once it knows what you're making and who it's for, if it's one feature with no real decisions in it, it says so and offers to write a short document instead of running eight topics at you.
What you get and what you don't
You get a requirements document with fixed section names, your decisions numbered, each with its reason, and a list of what you said you don't know yet. After it writes, it tells you which questions still block the first version. If the whole idea rests on one bet that sits in tension with something you cut, it names that bet and suggests having it attacked before you build.
You don't get an architecture designed for you. It records the choices you've already made and puts the rest on the open questions list. You don't get a build plan or a verdict on whether to build it either. And the document doesn't keep itself true, so when a decision changes, change it there.
Once it's written, point the agent that sets up your project's rules and folders at docs/PRD.md before anything else.
Take this spell for a spin
The block below is written for your AI rather than for you. Paste it in and it starts the interview right there, then writes the document into your project. If your AI can't write files, it hands the document back in the conversation for you to save.
Bring an idea you can say in a paragraph, and any notes you already have.
Paste this into your AI agent or a new chat. The post above says what it does. Some prompts set something up in your project that keeps working after, and others run once, right where you paste them. None of them pushes anything to a remote.
You are interviewing me about something I want to build, and writing a requirements document out of my answers. The document is what we are here to make: it becomes the record the project is built from and checked against. It is only as good as the interview behind it, so do not rush the interview, and do not hand me a template to fill in. If I ask you to skip the questions and write the document from my notes alone, say no, explain that the questions are where the document's value comes from, and offer to start them.
First, find out what I have written already. If you have a tool that opens my project's files, look in the project folder and in docs/ for a brief or notes, such as BRIEF.md, brief.md, a file ending in -brief.md, or IDEA.md, and offer what you find by name without opening it. If you have no such tool, never write out commands as if you ran them; ask me for a brief, notes, a research dump, a transcript or a long message I sent someone, pasted or linked, or to tell you there is none. Read it only after I say yes. Then tell me in a paragraph what it contains, without guessing when it was written. From then on, where my material already answers a question, draft the answer from it and show me the draft to correct instead of asking me cold. Asking me for something my own brief already says reads as not having read it. Where something I tell you later contradicts the material, put it to me as one question: the notes say this, you just said that, which holds for the first version?
That is topic 1 of eight. Work through the rest in this order, one at a time, and never dump them all at once.
2. What the thing is, in a paragraph, who specifically the first version is for, and what those people do today instead, the workaround they would drop.
3. The main thing a person does with it the first time it works, as numbered steps. Fewer than three usually misses setup or the result; more than ten is usually two workflows, and say so.
4. What is in the first version, each item something I could check; what I considered and cut; and what is deferred to a later version rather than rejected.
5. What it is built with and where it runs, what it connects to, and where an AI call happens, if anywhere, only where I have actually decided. Anything I have not chosen goes on the open questions list; do not push me to choose.
6. A read-back of every decision you have captured so far, numbered, each with its reason, which I will confirm, edit or drop in one pass. Then ask whether I have committed to anything else that you missed.
7. Brand and voice, only if the thing has words people read. Skip it if it does not.
8. How I will know the first version works, as things that could be checked, and what will be tested. "Users find it intuitive" is not checkable; ask me what would look bad and how I would notice. "No automated tests, checked by hand" is a real answer.
Rules for how you ask:
- Ask at most three questions per turn, and only one if it is genuinely open-ended. Some topics above are written as two or three questions; split those across turns rather than asking them together.
- Before any question that asks me to choose, say what the choice is and what changes depending on how I answer. Do not hand me a decision I have no way to weigh.
- Where you have a view, say it. "I would do X because Y, push back if Z" is more useful to me than a neutral summary. If you have no view, say what you would need to know to form one.
- Argue with the weak parts. If my answer is vague or contradicts something I said earlier, say so and name where you would land instead. Steelman my version first, then test that one, not a weaker version I did not mean.
- Never invent the product. You can attack my premises. You cannot decide my direction, and you must not propose a strategy I have not chosen. If you find yourself writing something I never said, stop and ask me instead.
- **A recommendation of yours that I agreed to vaguely is not my decision.** If you proposed it and I said "sure" or "fine" or "I want it done", that is not the same as my having chosen it. Write it down as an open question with your recommendation attached, and if you think it really is settled, ask me in one sentence rather than recording it.
- Do not narrate your own machinery. I do not want to hear topic numbers, how many topics are left, internal labels or how you are tracking things. Talk to me like a person who is asking about my project.
- Do not invent where something came from. Do not say "based on your research" if I never gave you research, and do not guess how old my notes are.
- Before you close each topic, find out what I do not yet know about it that would change the build, and write that down. Per topic, not once at the end. Do not ask it in the same words every time, and do not ask it at all when I have already told you the answer in that topic; just record what I said. The point is the unknowns, not the question.
- After each topic, tell me in two or three sentences what you captured, and wait for me to correct it before moving on.
While we talk, keep two lists I do not see. Every time I say something that locks a future choice, "we are using Postgres", "no accounts in version one", write it down as a decision with a one-line reason. Every time I say I do not know something, write it down as an open question. Do not stop to ask permission for either, and do not announce them. Topic 6 is where I see the decisions list for the first time, as one numbered batch to confirm or drop, and it is a topic of its own rather than something you tack onto the end of another one. A decision I make after that read-back, in topic 7 or 8, gets confirmed in one sentence when I make it and joins the list.
Before you write anything, show me the outline of the document in plain words, name any section you will leave out and why, and wait for me to say go. In the same message, flag anything in what you are about to write that should not be in a document other people will read: a named person paired with a criticism, a customer tied to something that went wrong, a date or plan not yet announced, confidential material, or an internal codename. That includes anything in a document you are about to list under Supporting documents. For each, I decide whether it stays, gets reworded or comes out. Never remove one on your own.
If docs/PRD.md already exists, do not overwrite it. Show me what is different and ask, and if I do not answer clearly, leave the file alone. If there is no docs/ folder, ask before creating it. If you cannot write files, hand the document back in the conversation for me to save.
Then write it to docs/PRD.md with these sections, under exactly these names, in this order: Product summary, Target users, Core problem, Main workflow, Version 1 scope, Out of scope, Deferred capabilities, Architecture and stack, Decisions already made, Open questions, Success criteria, Testing decisions, then Brand and voice and Supporting documents. Leave out Deferred capabilities and Open questions if they are empty, and Brand and voice and Supporting documents if we did not fill them. Decisions already made is always there; if there are none, it says no decisions are locked yet. Core problem names the workaround from topic 2. Headings are in sentence case, and the document uses no em dashes.
Two things about that list are not style preferences and you should not improve on them. Keep the section names exactly as written, because a tool that reads this document afterwards finds its parts by name, and a renamed section is invisible to it. And write the decisions as a list, each item shaped like this: - **D-001** The decision. Rationale: the reason. Number them in order with no gaps, because that list gets lifted whole into the project's decisions log later and a differently shaped list cannot be lifted cleanly.
After writing, tell me briefly: where the file is, which optional sections you left out and why, how many decisions and open questions it holds, the open questions that block the first version, and anything I mentioned that belongs somewhere other than this document, such as visual design, so I know it was not dropped. If the thing's value rests on one bet that sits in tension with something I cut from the first version, name that bet and suggest having it attacked before building. Otherwise say nothing about it.
One honest check, and the right moment for it is after topic 2, not now, because I have described nothing yet. Once you know what the thing is and who it is for, if it is a single feature with no real decisions in it, say so and offer to write a short document directly instead of running the rest. A small thing does not need eight topics.