When you are the missing context, get interviewed
By the end you can
- Recognise the requests where more prompt craft cannot help because the information is only in your head
- Run an interview that surfaces the decisions you had not noticed you were making
- Turn the interview into a self-contained SPEC.md that names files, scope and a verification step
- Execute the spec in a fresh session, and say why the argument should not come with it
Everything so far has assumed the context existed and you failed to supply it — the file was on disk, the pattern was in the repo, the error was in the scrollback.
Sometimes it is not. "Add team accounts" is under-specified in a way no @
reference can fix, because the missing information is a set of decisions nobody
has made yet. Can a user belong to two teams? What happens to their work when
they are removed from one? Is the billing seat the account or the person?
You are the missing context, and you have not been asked the questions yet.
Reverse the direction
The documented move for a larger feature is to have Claude interview you before anything gets built (Best practices). You open with a minimal prompt and hand over the questioning:
I want to build team accounts for this app. Interview me using the
AskUserQuestion tool.
Ask about technical implementation, UI/UX, edge cases, concerns and tradeoffs.
Skip the obvious questions — dig into the hard parts I probably have not
thought about.
Keep going until we have covered everything, then write a complete spec to
SPEC.md.Three details in that prompt are doing the work, and dropping any of them weakens it noticeably.
Naming AskUserQuestion asks for structured, one-at-a-time questions with
options rather than a wall of twelve bullet points you will answer three of.
"Skip the obvious questions" is what stops the interview opening with "what is a team?". You want the questions that expose decisions, not the ones that confirm the brief.
"Keep going until we have covered everything" sets the stopping condition on coverage rather than on politeness. Without it the interview ends after four questions because four felt like enough.
What makes a spec worth executing
The interview's output is a file, and the documentation is specific about what separates a useful one from a transcript with headings. A useful spec is self-contained: it names the files and interfaces involved, states what is explicitly out of scope, and ends with an end-to-end verification step that proves the feature works.
Read that list again as three failure modes it prevents:
| The spec says | Without it |
|---|---|
| The files and interfaces involved | The implementing session re-derives the architecture, differently |
| What is out of scope | Scope grows quietly, and the diff arrives three times the size |
| How to prove it works | You are back to eyeballing a plausible implementation |
The out-of-scope section is the one first-time authors skip and the one that earns its keep fastest. "Not doing SSO in this pass" is a sentence that prevents a week.
Then start a fresh session
This is the step that looks optional and is not.
Execute the spec in a new session (Best practices). The interview session is now full of the deliberation that produced the spec — the options you rejected, the tangent about webhooks, the design you talked yourself out of. All of it is context the implementing session would have to reason around, and none of it is context the implementation needs. The spec is the compressed conclusion of that conversation. That is the artefact you carry forward.
There is a second reason, and Level 3 will make it the centre of everything: the implementation is the part that will need the room. Spending the window on the argument that produced the plan means running out of it halfway through executing the plan.
The documented summary is worth keeping: time spent making the spec precise pays off more than time spent watching the implementation.
When to reach for this
Not for everything. An interview for a typo fix is theatre.
The signal is a request where you cannot yet write down what "done" means. If you can state the pass condition in one sentence, you do not need a spec — you need Lesson 2.1's four sentences. If you find yourself typing "it should probably..." more than once, you are making decisions in a medium that does not record them, and it is time to be interviewed.
Checkpoint
You should be able to look at a feature request and say whether it needs four sentences or a spec — and, for one that needs a spec, write the interview prompt and name the out-of-scope line before the interview starts.