The GPT that interviews you before it writes a word

A coaching client needed a custom GPT to produce a long, structured narrative from a fixed 12-section outline. The first instinct with any generation tool is to accept a short prompt and let the model fill the gaps. That path produces confident text that says almost nothing the user actually meant.

We built the opposite. The GPT interviews the user section by section, asks 3–4 direct questions each time, and only writes once a section has enough real detail to write from.

TL;DR: Thin prompts make models guess. We replaced the guessing with a structured interview — fixed sections, a few pointed questions per section, and a readiness check before any generation. A related builder product added an optional suggestion step, gated so generation stays manual. Four bugs only appeared in live testing; all four shipped fixed.

The deliverable is a long narrative with a fixed 12-section structure. Every section has to reflect the user's own situation, not a generic template.

A short prompt cannot carry that. When the model has three sentences of input and twelve sections to fill, it invents the rest. The output reads fluent and specific, which is worse than reading obviously empty — the user has to hunt for the fabricated parts before they can trust any of it.

The business cost is rework. A draft built on invented detail is not a fast first draft; it is a slow correction exercise. The user ends up rewriting more than if they had started from a blank page.

The obvious fix is a longer prompt: tell the user to write more up front. That fails for two reasons.

First, people do not know what to include until they are asked. A blank instruction to "describe your program in detail" gets a paragraph; a direct question about one specific thing gets the fact you actually needed. The structure has to pull the detail out.

Second, one giant prompt collapses twelve distinct sections into a single wall of input. The model cannot tell which sentence belongs to which section, so it smears context across the whole narrative. Even a detailed prompt does not fix the mapping problem.

So the answer was not "ask for more text." It was "ask the right questions, in the right order, one section at a time."

We turned generation into an interview. The GPT walks the fixed 12-section structure in order. For each section it asks 3–4 direct questions, uses only the information the user provides, and generates that section only once it has enough detail to do so.

A simplified questionnaire drives the interview. Each section carries a one-line purpose statement plus its handful of questions. That questionnaire is what keeps the conversation specific instead of open-ended — the model is not improvising the interview, it is following a script that was designed to extract the right inputs.

The tradeoff we accepted is speed at the front. The user spends more time answering questions before seeing prose. In exchange, the prose is grounded in their answers, so the back-end rework drops. We moved effort from correcting output to supplying input, which is the cheaper place to spend it.

The mechanism is a gated pipeline. Nothing generates until the input for that stage exists.

The flow runs in five moves:

1. Fixed section list. The 12-section structure is fixed and ordered. The GPT never invents sections or reorders them; the structure is the contract for the whole narrative.
2. Per-section questions. For the current section, the GPT asks 3–4 direct questions drawn from the questionnaire, each tied to that section's one-line purpose. It uses only the answers the user gives — no borrowed detail from outside the conversation.
3. Readiness check. Before writing, the GPT checks whether the section has enough detail. If it does not, it keeps asking rather than filling the gap itself. This check is the thing that stops hallucination — an underfed section stays an open question, not an invented paragraph.
4. Optional suggestion step (prompt-suppress gate). In a related GPT-builder product, an optional step sits between the conversation stage and artifact generation. Admins configure the questions; the model generates suggestion options live; the user picks one or types their own; a "more" button loads extra options. A prompt-suppress gate keeps generation manual while this step is on — the step does not auto-trigger into generation. The user stays in control of when writing happens.
5. Generation. Only after readiness (and, where enabled, an explicit pick) does the section generate. In the builder product, the picked answers are stored and passed to the model at generation time, and the suggestion step reappears pre-filled on each regeneration — so a redo starts from the last choices instead of a blank slate.

The important property is direction of flow. Input always precedes output, and the gate between them is deliberate, not automatic. The suggestion step assists the user with options; it never decides on their behalf.

Component review looked clean. The interview logic, the form, the suggestion options, and the generation call all passed on their own. The failures showed up only when we ran the whole flow live.

Four bugs surfaced in live testing:

• Answers not reaching the model at generation time. The suggestion step collected picks, but they were not making it into the generation call — so the model wrote as if the step had never run.
• HTML escaping in the form. User input came back through the form escaped, corrupting the stored answers before they were ever used.
• JSON field-casing mismatch. A field-name casing difference between what one side wrote and what the other side read meant the payload silently did not line up.
• The "more" button staying disabled. The control that loads extra suggestion options never re-enabled, so users could not pull more options when the first set did not fit.

The through-line is that these are all integration bugs. Each piece was correct in isolation; the defects lived in the seams — data crossing a boundary, a payload being read on the far side, a control's state after an action. That is exactly the class of bug component review does not catch and only end-to-end testing exposes.

All four were fixed and shipped through dev and then main.

We measured this by the shape of the work, not a vanity metric.

The readiness check is the direct test: a section either has enough user-provided detail to generate, or it does not. When it does not, the GPT asks another question instead of writing. That is an observable gate — you can watch it hold generation back rather than paper over a gap.

The suggestion step is testable the same way. Picks are stored and passed at generation time, and the step comes back pre-filled on regeneration, so you can confirm a redo carries the previous choices forward instead of resetting. The prompt-suppress gate is verified by the negative: with the step on, generation does not fire until the user acts.

The clearest signal was the bug set itself. Four defects that all passed component review failed live. The measurement that mattered was end-to-end: run the real interview-to-generate flow and watch whether answers actually arrive at the model intact.

1. Ask before you generate. A structured interview beats a longer prompt. Direct, per-section questions pull out detail that an open instruction never will.
2. Make readiness a gate, not a suggestion. If a section lacks detail, the right move is another question — not a confident invention. A hard readiness check is what actually stops hallucination.
3. Keep the human in the generate step. A prompt-suppress gate that keeps generation manual means an assistive suggestion step stays assistive. Options help; they should not auto-decide.
4. Persist the picks and pre-fill the redo. Store chosen answers, pass them at generation time, and bring the step back pre-filled on regeneration. Regeneration should build on the last state, not restart from empty.
5. Trust only end-to-end testing for the seams. Every one of the four bugs passed component review and failed live. Integration defects hide at the boundaries; the only way to find them is to run the whole flow.