Specify before you prompt

I'm going to build something, and I don't want any code yet.

Your job in this conversation is to interrogate my thinking, not to design a
solution and not to agree with me. Ask one question at a time. Push back when
my answer is vague. If I give you a requirement that contradicts something I
said earlier, say so.

I'll answer as the domain expert. You are not the domain expert here — when
something depends on knowledge of my field, ask me rather than assuming.

Work through these, in order:

1. THE THING ITSELF
   - What am I actually building, in one sentence, with no adjectives?
   - What exists today, and why isn't it good enough?
   - What is explicitly NOT in scope? Make me name at least three things.

2. THE PEOPLE
   - Who touches this, and what were they doing five minutes before?
   - What are they actually trying to accomplish — not the feature they'd
     ask for, the outcome they want?
   - What do they already know? What will they never learn?
   - Who else is affected but never opens it?

3. WHAT "CORRECT" MEANS
   - How do I know an output is right? Be specific: exact match, a range, a
     judgment call, a human sign-off?
   - Where is "close enough" genuinely fine, and where is it not?
   - Who decides when we disagree about correctness?
   - What would a competent person in my field say if they saw this get it
     wrong?

4. HOW IT FAILS
   - Walk me through the ways this breaks. For each: how likely, how bad, and
     would we even notice?
   - Which failure is unacceptable — the one where I'd rather the whole thing
     refuse to run than produce that result?
   - What fails silently? That's the category I care about most.
   - What happens on the worst input someone could plausibly give it?

5. THE ONE RULE
   - Based on everything above, propose the single outcome this work must
     never violate. One sentence. I'll edit it.
   - Then: for each decision we've made, does it protect that rule or risk it?

6. DONE
   - What's the falsifiable test that proves this works? Not "it feels right."
   - What am I deliberately deferring, and where will I write that down so it
     isn't silently lost?

When we've been through all six, summarize back to me: the thing, the users,
the definition of correct, the failure modes ranked, the one rule, and the
acceptance test. Flag anything I was vague about. Then stop — still no code.

I'm about to run a pre-build specification conversation using the structure
below, and I want you to tailor it to my field first.

My field: [YOUR FIELD]
What I'm building: [WHAT YOU'RE BUILDING]
Who it's for: [WHO IT'S FOR]
What going wrong looks like: [WHAT GOING WRONG LOOKS LIKE]

Do three things:

1. Rewrite section 3 ("what correct means") using the actual standard of
   correctness in my field. Name the specific standard, tolerance, regulation,
   professional guideline, or accepted practice that governs it — not a
   generic "meets requirements." If my field has more than one and they
   conflict, ask me which applies.

2. Rewrite section 4 ("how it fails") as a structured failure-mode analysis in
   the style of an FMEA: for each failure, the mode, the effect on the person
   downstream, roughly how likely, and whether it announces itself or fails
   silently. Prioritize by "bad AND silent," not by likelihood alone. Draw on
   the failure modes that actually occur in my field — ask me if you don't
   know them.

3. Add a section 0 that establishes context before we start, using the frame
   most standard in my field for a new effort. If you're not sure which fits,
   offer me two and let me choose — for example a lean canvas if this is a new
   business, a jobs-to-be-done statement if I'm replacing an existing
   workflow, or a user-needs-and-design-inputs list if this is a regulated or
   safety-relevant product.

Then ask me the questions one at a time. Do not answer them for me, do not
propose a solution, and do not write code. If I give you a vague answer, tell
me it's vague and ask again.