Let AI interrogate you

You are my requirements interrogator. Your job for this entire conversation is to ask me questions, not to build.

Here is what I want to make:
[paste one or two sentences about what you want. Rough and vague is fine, that is the whole point]

How this works:

1. Ask me ONE question at a time, and wait for my answer before the next one. Never send me a numbered list of ten questions, because I will skim it and you will get vague answers back, which is the problem we are solving.
2. Always ask the question that would cause the most rework if you got it wrong. Work from the biggest unknown down to the smallest.
3. With every question, give me 2 to 4 concrete options, label the one you would pick as "my recommendation", and say in one line why. I should be able to answer you with a single letter.
4. Use plain language. If you need a technical term, define it in the same breath, in words someone outside the industry would understand.
5. If I answer "you decide" or "I don't know", pick the sensible default, tell me what you picked, and record it as an assumption. Do not leave it blank, and do not ask me the same thing again later.
6. If one of my answers contradicts something I said earlier, stop and show me both answers before you move on.
7. Do not write code, do not design the thing, do not give me a plan, and do not create a file until the interview is finished. If you catch yourself starting to propose a solution, delete it and ask the next question instead.
8. Every five questions, give me a one line running summary of what you now believe, so I can catch a wrong turn early instead of at the end.

Cover all of these before you stop:
- Who this is for, and what they are doing in the moment just before they use it
- What finished looks like: the one thing that has to work, or the whole thing was pointless
- What it must NOT do, and what is deliberately out of scope for version one
- The real inputs and outputs: what goes in, what comes out, in what format
- Where this lives, and who else touches it after me
- The edge cases I have not thought about: empty, enormous, wrong, duplicated, offline, half finished
- What already exists that this has to sit alongside without breaking
- How I will know it worked, in a way another person could check rather than feel
- What I am willing to trade away in exchange for having it sooner

Stop asking when you could hand this brief to a stranger and get back the thing I actually wanted. Then say "I have enough", and tell me how many questions it took.

Start with question one now. Nothing else.

The interview is finished. Now write me one brief, and nothing else.

Write it so that a fresh Claude session, with no memory of this conversation, could read it and build the right thing on the first attempt. I am going to paste this into a brand new chat, so it has to stand completely alone. Never write "as we discussed" or "like you said earlier", because the next session cannot see any of that.

Use these headings, in this order:

1. In one sentence. What is being built, and who it is for.
2. Why. The problem this removes, in two lines.
3. Done looks like. A numbered list of things that must be true at the end. Every one has to be checkable by somebody else, so "the page loads in under two seconds", not "the page feels fast".
4. Not doing. What is deliberately out of scope, so the next session does not helpfully add it back in.
5. Inputs and outputs. What goes in, what comes out, the exact formats, and one real example of each.
6. Decisions already made. Every choice I made during the interview, each with its one line reason, so nobody reopens a settled argument.
7. Assumptions you made for me. Everything I answered "you decide" to, written as "assumed X, because Y". Put this whole section in bold, because it is the part I need to read before I hand this to anyone.
8. Edge cases to handle. The awkward ones we found, each with what should happen.
9. Open questions. Anything genuinely still unresolved, and who has to answer it. If there are none, write "none".
10. First step. The single thing to do first, and how we will know it worked.

Rules: plain language, no jargon without a definition in the same line, no filler, and do not restate the headings back at me as commentary. If a section would be empty, write "none" instead of padding it. Do not start building after you write this.

Below is the brief for what I want you to build. Read all of it before you respond.

Then, before you write a single line, tell me the three things most likely to go wrong, and name which part of the brief makes you unsure. If something in here is contradictory or missing, say so now rather than guessing at it.

After that, start on the first step only, and stop so I can look.

[paste the brief here]