#interview

The user knows more than they say. The interview's job is to surface what they never thought to mention by asking what they never thought to ask, until nothing new comes out.

#When to use

Use before defining a feature or spec, when kicking off a vague task, or when weighing a decision or trade-off. Invoke as /interview <topic>, or bare /interview to interview about the current conversation's work.

Not for: tasks already fully specified (just do them), or producing the deliverable itself (hand off after the interview).

#Workflow

• 1. Fix the topic: the argument if given, otherwise the current conversation's work. If neither is clear, the first question is what to explore.
• 2. Ask how to ground: the opening AskUserQuestion offers scanning available context (repo, conversation, memory) or going in blind. Scanned context may only prevent redundant questions and sharpen them with specifics. It must never frame the interview: follow the user's intent, not what already exists.
• 3. Run rounds of 2 to 4 questions drawn from the toolbox below. Use AskUserQuestion when answers are enumerable, since proposed options themselves reveal angles the user had not considered. Use freeform prose for open exploration.
• 4. Between rounds, synthesize in two short parts: "What I have" and "What is still fuzzy". Let the user correct misreadings before the next round.
• 5. Challenge weak answers: when an answer is vague, dodges, or contradicts an earlier one, follow up once before moving on. Never re-litigate clear answers.
• 6. Stop at saturation: when a full round adds nothing new, ask the closing question: "What matters here that I never asked about?" Only close after it.
• 7. Close by asking two things: what to produce (inline brief, context file, direct handoff into the task, or a combination) and which durable facts, if any, to save via the remember skill. Nothing is written silently.

#Question toolbox

Rotate techniques across rounds: consecutive rounds on the same one go stale.

• Assumption surfacing. State back the assumptions hidden in the request ("you seem to assume X") and ask which are wrong. The wrong one is usually the most informative.
• Pre-mortem. "It is six months later and this failed, or succeeded but disappointed you. What happened?" Surfaces risks and unstated quality bars.
• Inversion and non-goals. What must this NOT do, who is it NOT for, what would make the user reject a result that technically works.
• Goal laddering. Ask why they want this, then why that, until the underlying goal appears. Be ready for the answer to change the task itself.

Coverage map for judging saturation: goals, constraints, resources, people affected, history and prior attempts, success criteria, risks, scope edges. A dimension never touched is not saturated.

#Self-check

• At least one answer contained information absent from the original request, otherwise the interview added nothing.
• No question asked something already answered or already visible in scanned context.
• Each synthesis was confirmed or corrected by the user before the next round.
• The interview closed with the "what did I never ask about" question, not arbitrarily.
• The user chose the output form and the memory saves.

#Example

Input: /interview I want to migrate our auth to passkeys

Round 1 (assumption surfacing plus inversion): "You seem to assume every user has a device with an authenticator: what is the fallback?" and "Who must this NOT disrupt during rollout?". The second question surfaces a hidden constraint: a call-center flow that cannot use passkeys at all. That constraint reshapes the migration and was absent from the request.

At saturation the user picks "context file plus handoff": the brief (goals, constraints, non-goals, risks, open questions) is written to a file the user names, and the work starts from it.

#Traps

• Interrogation pacing. More than 4 questions per round overwhelms and answers get thin. Cap at 4, prefer 2 or 3.
• Anchoring on scanned context. Questions shaped by the existing code interrogate the implementation, not the intent. Context prevents redundancy only.
• Leading questions. A question that embeds the preferred answer extracts nothing. Offer genuinely open options.
• Accepting the first "I do not know". Reframe once or offer concrete options: "I do not know" often means the question was too abstract.
• Stopping on one quiet round. Politeness looks like saturation. Confirm with the closing question before ending.

#Adding a learning

Use the remember skill to fold interview lessons into this skill.