Intent Interview
Use this as an interactive gate before research-briefing, the engineering Spec
step, or any expensive work, when what the user wants is not yet clear. It closes
the gap between what was asked and what is actually wanted while changing course is
still free.
When to use
- an ask is underspecified ("build me X", "research Y") with no who / why / success
- you notice yourself silently filling in ambiguous requirements
- the user invokes it ("interview me", "are we sure?", "stress-test my thinking")
- building the wrong thing would cost more than asking
When not to use
- the request is already specific, or the user gave a detailed plan that still holds
- trivial tasks answerable directly
- non-interactive runs with no user to answer — instead state assumptions and proceed
Method
Hypothesize. State your one-sentence best read of what the user wants, with a
confidence (0-100%). Below ~70%, name the missing field: who it is for, why now,
what success looks like, or the binding constraint.
Interview, one question at a time. Ask exactly one focused question per turn,
each with your current guess attached, then wait:
Q: one questionGUESS: your hypothesis and the reasoning behind it
Asking several questions at once defeats the purpose — the user should react to a
guess, not generate from scratch.
Probe want vs. should-want. When an answer sounds like convention or
buzzwords, ask once: "If you didn't have to justify this to anyone, what would you
actually want?"
Restate. Once you can predict the user's next few answers, write a six-line
restate in their words: Outcome / User / Why now / Success / Constraint /
Out-of-scope. The Out-of-scope line is mandatory.
Confirm. Gate on an explicit yes. "Sounds good", "whatever you think", and
silence are not yes.
Output contract
Produce a short visible section titled Intent Check:
Hypothesis and ConfidenceConfirmed intent — the six-line restateStatus — CONFIRMED | NEEDS-INPUT | BLOCKED-NON-INTERACTIVE
Hand the confirmed intent to research-briefing (research) or the engineering Spec
step. See references/intent-interview-template.md for the exact shapes.
Guardrails
- one question per turn, and always attach your guess
- never treat a non-answer as approval
- stop interviewing once you can predict the answers — do not over-question
- if no user can answer, state assumptions explicitly and proceed under them
Recommended templates
When this skill is involved, consider these workflow templates (install via
the workflow-templates artifact profile, or --with-deps to pull backing skills):
reversible-decision-memo -- Evidence-grounded decision record with named alternatives, source-cited rationale, reversibility class and trip-wires, and a fresh-context adversarial confirmation before the decision stands.
1---2name: intent-interview3description: Use when an ask is underspecified, or you catch yourself inferring what the user wants, before any brief, spec, plan, or code. Elicits the real intent one question at a time, each with your best guess attached, until you can predict the user's answers, then restates a confirmed intent for explicit sign-off.4---56# Intent Interview78Use this as an interactive gate before `research-briefing`, the engineering Spec9step, or any expensive work, when what the user wants is not yet clear. It closes10the gap between what was asked and what is actually wanted while changing course is11still free.1213## When to use1415- an ask is underspecified ("build me X", "research Y") with no who / why / success16- you notice yourself silently filling in ambiguous requirements17- the user invokes it ("interview me", "are we sure?", "stress-test my thinking")18- building the wrong thing would cost more than asking1920## When not to use2122- the request is already specific, or the user gave a detailed plan that still holds23- trivial tasks answerable directly24- non-interactive runs with no user to answer — instead state assumptions and proceed2526## Method27281. **Hypothesize.** State your one-sentence best read of what the user wants, with a29 confidence (0-100%). Below ~70%, name the missing field: who it is for, why now,30 what success looks like, or the binding constraint.312. **Interview, one question at a time.** Ask exactly one focused question per turn,32 each with your current guess attached, then wait:33 - `Q:` one question34 - `GUESS:` your hypothesis and the reasoning behind it3536 Asking several questions at once defeats the purpose — the user should react to a37 guess, not generate from scratch.383. **Probe want vs. should-want.** When an answer sounds like convention or39 buzzwords, ask once: "If you didn't have to justify this to anyone, what would you40 actually want?"414. **Restate.** Once you can predict the user's next few answers, write a six-line42 restate in their words: Outcome / User / Why now / Success / Constraint /43 Out-of-scope. The Out-of-scope line is mandatory.445. **Confirm.** Gate on an explicit yes. "Sounds good", "whatever you think", and45 silence are not yes.4647## Output contract4849Produce a short visible section titled `Intent Check`:5051- `Hypothesis` and `Confidence`52- `Confirmed intent` — the six-line restate53- `Status` — CONFIRMED | NEEDS-INPUT | BLOCKED-NON-INTERACTIVE5455Hand the confirmed intent to `research-briefing` (research) or the engineering Spec56step. See `references/intent-interview-template.md` for the exact shapes.5758## Guardrails5960- one question per turn, and always attach your guess61- never treat a non-answer as approval62- stop interviewing once you can predict the answers — do not over-question63- if no user can answer, state assumptions explicitly and proceed under them6465## Recommended templates6667When this skill is involved, consider these workflow templates (install via68the `workflow-templates` artifact profile, or `--with-deps` to pull backing skills):6970- `reversible-decision-memo` -- Evidence-grounded decision record with named alternatives, source-cited rationale, reversibility class and trip-wires, and a fresh-context adversarial confirmation before the decision stands.
hoanganhduc