Interview the user relentlessly about every aspect of the thing until you reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one by one. For each question, give your own recommended answer.
Ask one question at a time, waiting for the answer before the next. A batch of questions is bewildering and destroys the dependency order that makes the interview converge.
Look up facts; ask for decisions. If something can be settled by exploring the environment — filesystem, git history, the codebase, the web — go and settle it. The decisions are the user's: put each one to them and wait.
Do not act on the plan until the user confirms the shared understanding is reached.
Why one at a time
The mental model is a decision tree. An early answer reshapes which questions come next — a firehose of parallel questions throws away that structure and produces answers to questions that turned out not to matter.
Composing
This is a primitive, not a workflow. Reach for it from inside other work whenever a plan needs sharpening:
- Before
/plan— when the feature is still fuzzy./plandeliberately asks zero questions and researches code instead, so grill first when the decisions, not the code, are what's missing. - Before
/validate— when the idea itself hasn't been pinned down enough to score. - Inside
/stream— when a STREAM layer needs the user's judgement rather than analysis. - After
/diagnosePhase 3 — to pressure-test which hypothesis to chase.
Gotchas
- Recommendations are the point. A bare question makes the user do all the work; a question with your recommended answer lets them correct a draft, which is far faster.
- Asking what you could look up burns trust. Check the repo, the config, the git log first.
Don't
- Batch questions "to save time" — it costs more.
- Start building the moment the user answers the last question; confirm the shared understanding first.
Adapted from grilling by Matt Pocock (MIT, Copyright (c) 2026 Matt Pocock). See THIRD-PARTY.md.