From an Idea to a PRD

PROPOSAL.md is what you decided, in your own words. PRD.md is the same decisions, expanded until an AI agent can build from them. This page covers both steps: practicing the interview when you build for a client, then the prompt that turns your proposal into a PRD.

If you are building for someone else#

Skip this section when the project is your own idea.

Theo runs a swing dance club and will not get bored. Practice your interview questions on him first. Paste the block below into any AI chat, then interview it the way you will interview the person you are actually building for. What comes out of the real interview goes into PROPOSAL.md.

This is practice for the questions, and it does not replace the conversation with your real client. Everything you write down has to come from that conversation.

How to use it#

1. Open a new chat and paste the whole block below.
2. Ask your first question. Keep going until you can name who visits the site and the one thing they need to do there.
3. When an answer is vague, follow up. A vague answer usually means the question was vague.
4. Afterwards, look at what you still do not know. Those are the questions to bring to your real client.

The prompt#

You are Theo, who runs a swing dance club at a college. A student is
interviewing you to build the club a website. Stay in character.

What you know (reveal only when asked about it directly):
- Most visitors are students who saw a flyer and are deciding whether to come
  to one lesson. A few are alumni looking for the spring showcase date.
- What you want most: more people at the Tuesday beginner lesson.
- Sign-ups run through a Google Form you already have.
- Practices are Tuesday and Thursday, 7 to 9 p.m., in the recreation center.
- You have about 40 photos from last year's showcase. Most are blurry, and
  four of them are good.
- You would love a members area where people log in and see their attendance.
- The club has no logo. Someone made one in Canva two years ago and nobody
  can find the file.

How you answer:
- One or two sentences. Never volunteer what you were not asked.
- You do not know web terms. If the student uses one, ask what it means.
- A vague question gets a vague answer ("Something fun, I guess").
- Sometimes answer "I don't know, what do you think?"
- Never write the website, the plan, or the questions for the student.

What to watch for#

The answers you get will have the same four problems a real interview has, and each one has a move:

Turn the proposal into a PRD#

Open your agent and attach PROPOSAL.md and your sketch. Paste the project's requirements from its Canvas page, then everything inside the block. A project with no spec, such as your personal site, needs two or three lines of your own in their place: what it is built with, and when it is due.

If your agent is not working, the interview runs in any chat, including ChatGPT or Claude in a browser. Do it there, then create PRD.md in the repo yourself, paste what came back, and commit it. The project needs PRD.md in the repo. Which window it was written in makes no difference.

The States section follows Scott Hurff's UI Stack: a page that changes with its data has five states, the ideal one in normal use, and the empty, error, partial and loading states around it. Your project's spec says which of them it requires.

Read PROPOSAL.md, the project requirements I pasted above, and any sketch I
attached. Interview me so we can write a PRD. Do not create or edit any file
until I say "write it".

- Ask in rounds of at most three numbered questions. For each one, give your
  recommended answer and one line on why. Then stop and wait for me.
- Settle focus first: who uses this, and the one thing they must be able to
  do. Do not ask about colors or fonts until that is settled.
- Version 1 has to fit the project requirements: the tools they allow, the
  limits they set, and the due date. If an idea needs something they rule out,
  such as a server, a database, logins or payments, suggest a stand-in that
  fits and put the full feature on a Later list.
- Keep version 1 to what I can build and check by the due date.
- Never invent content or data. If I do not have something, record it as
  missing and who will provide it.
- If a question can only be answered by seeing something, say so, and suggest I
  try two quick versions instead of guessing.

When I say "write it", write PRD.md with these sections: Goal, Audience and key
action, Features (what version 1 does, as pages, screens or steps), Content and
data (have / missing / from whom), Look (one line pointing to DESIGN.md,
without repeating its values), States (if the page changes with its data,
what it shows in each of the five UI Stack states: ideal, empty, error,
partial and loading; leave out a state the page cannot reach), Checks (three
to five things a user must be able to do), Out of scope, Later.

Save it if you will use it again#

Your next project will need this interview again, in its own repo. Save the block as .github/skills/prd-interview/SKILL.md, with these three lines above it:

---
name: prd-interview
description: Interview me about PROPOSAL.md and the project requirements, then write PRD.md.
disable-model-invocation: true
---

Commit it, then paste that project's requirements and type /prd-interview in the chat box. Your agent will create the file for you if you ask it to.

While it interviews you#

• Change at least one recommendation every round, or state why you accept it. What you accept without thinking becomes the agent's decision.
• Correct every assumption it makes about your client or your users.
• When the questions stop teaching you anything, type "write it". The prompt keeps the agent from touching a file before that.
• Read the PRD before you save it. Delete anything you did not decide.

Last updated: Wednesday, 10/14/2026