Interview

Interview

What people ask for and what they want are different things. Close that gap before it costs a plan or a PR.

What this skill is - and isn't

Interview extracts want. --grill walks an existing plan or idea. --wayfinder charts a multi-session decision map. Those are modes of this skill, not other skills. This skill does not invent approaches, write build phases, or touch production source. If the user already knows the outcome and is choosing between designs in one session, that is vd:brainstorm.

Hard rules

Default and --grill (want / walk-an-idea). --wayfinder uses the map rules in references/wayfinder.md instead.

1. One question per message. Batching is a survey, not an interview. Why: a stacked list gets a polite yes, not a decision.
2. State a hypothesis + confidence before asking. Attach your best guess and a recommended answer. Why: reacting is faster than generating from scratch, and a visible guess is easy to correct.
3. Never ask a fact you can look up. Repo layout, current stack, existing APIs, prior ADRs - read them. Why: the user's job is decisions, not research.
4. Explicit yes on a concrete restate. "Sounds good", "whatever you think", and silence are not yes. Why: a hollow yes becomes the wrong PR.
5. Out of scope is mandatory. Half of misalignment is silent disagreement about what is not being built.
6. No options, no plan, no code until the restate is confirmed. Why: options widen the search; this skill narrows it.
7. Non-interactive is a blocker, not a guess. CI, vd:auto-loop, ultracook --auto / exec: write the missing slots and stop. Do not invent the user.

Modes

Detect --grill from the flag or "grill this", "stress-test my plan". Detect --wayfinder from the flag or "chart this", "wayfinder", "work the map", "this is huge", "we'll be at this for a while". If both could apply, --wayfinder wins (it will call --grill on individual tickets). Announce the mode in the first reply.

Workflow

--wayfinder does not use this loop. Follow references/wayfinder.md.

0. Interactive check

If there is no live user (CI, scheduled, auto-loop, ULTRACOOK_EXEC=1): stop. List the missing slots (who / why / success / constraint / out of scope). Do not fill them in.

If the ask is already a typo, rename, or a self-contained one-liner and you can write the restate at ≥95% confidence: write it, ask once, and skip the loop.

1. Hypothesize

One sentence + an honest 0-100% number:

HYPOTHESIS: You want a standup answer to "how are we doing?", and "dashboard" was the convention that came to mind.
CONFIDENCE: ~30% - missing: who it's for, which metric, what success looks like

If you cannot write that sentence, you do not understand the ask yet. Do not skip to questions.

Confidence below ~70% must name what is missing.

2. Ask one question

Prefer A/B/C when the answer space is bounded. Always attach your recommended answer.

Q: Who is this for on Monday morning?
A) The person running standup (recommended - matches "how are we doing?")
B) Leadership reviewing a weekly pack
C) Individual ICs checking their own numbers

On Claude Code, AskUserQuestion with one question. Elsewhere, the same prompt in plain text. Wait.

Do not ask "what would be best practice?". Ask what they actually want.

3. Probe convention and sophistication

When the answer is a convention ("a dashboard", "make it scalable", "clean architecture", "modern"):

If you didn't have to justify this to anyone, what would you actually want?

One probe is enough. Then return to Step 2.

4. Restate

When confidence is high, write this back - their words, 6 lines:

Here's what I now think you want:

- Outcome:      <one line>
- User:         <who benefits>
- Why now:      <what changed>
- Success:      <how we know it worked>
- Constraint:   <the binding limit>
- Out of scope: <what we are explicitly not doing>

Yes / no / refine?

5. Confirm

The gate is an explicit yes. These are not yes:

--grill: the session is done when every blocking decision has a recommended answer the user accepted. Same yes gate on the final restate.

6. Write and hand off

Feature-first repos - claim a feature first. If the hook context shows Feature: none, run workbench new <slug> once, then use the paths it prints. Skip when a feature is already active.

Write to the injected Reports: path: interview-{YYYYMMDD-HHMM}-{slug}.md. Do not write the file before the yes.

# Intent: {title}

- Outcome:
- User:
- Why now:
- Success:
- Constraint:
- Out of scope:
- How decided: yes | no

## Notes
{only decisions the user actually made}

Then hand off. Do not start the next skill until they pick one, unless they already said "then plan" / "then brainstorm" / "then wayfinder":

Rationalizations to catch

Red flags

• Three or more questions in one message
• A question with no hypothesis attached
• Accepting "whatever you think" as terminal
• A spec, plan, or option list before the yes
• Skipping Out of scope
• Confidence below 70% with no reason
• Saving the intent file before the yes
• Opening a 12-phase plan instead of switching to --wayfinder

Verification

Default / --grill:

• Hypothesis + confidence in the first turn
• One question at a time, each with a recommended answer
• Facts looked up, not asked
• Convention/sophistication answers probed once
• Six-line restate including Out of scope
• Explicit yes (not "sounds good")
• Intent file written to Reports: only after the yes
• Handoff named (vd:brainstorm / --wayfinder / vd:plan / user-requested --quick)

--wayfinder: follow the verification list in references/wayfinder.md.

Workflow position

Typically follows: a vague ask, vd:ultracook when want is unclear, or a user saying "interview me" / "grill me" / "chart this"

Typically precedes: vd:brainstorm (how) or vd:plan (steps). --wayfinder precedes vd:plan per cleared chunk.

Compares to: vd:brainstorm Phase 1 asks clarifying questions to frame options. Default interview refuses options until want is confirmed. --grill walks an existing idea. --wayfinder charts many sessions of decisions once the destination is named.