Interview Me

Interview Me

Overview

What people ask for and what they actually want are different things. They ask for "a dashboard" because that's what one asks for, not because a dashboard solves their problem. They say "make it faster" without a number to hit.

The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in.

This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: idea-refine generates variations from an idea, spec-driven-development writes the requirements down, doubt-driven-development stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.

Workflow notes: For an active track, read docs/tracks/<track-id>/notes.md at phase entry or resume and update it when useful context changes or before handoff. Capture observations, tentative ideas, outcomes, blockers, and next actions with evidence links. Follow the memory-management running-note and document-metadata protocols; honor explicit read-only or file-scope limits and keep writes outside pinned verification or release targets.

When to Use

Apply this skill when:

• The ask is missing at least one of: who the user is, why they want it, what success looks like, what the binding constraint is
• The request is conventional rather than specific ("build me X", "make it faster") and you can't unpack the convention without guessing
• You're tempted to start with assumptions you haven't surfaced
• The user hasn't said which value they're optimizing for when two reasonable ones are in tension (simplicity vs. flexibility, cost vs. speed)
• The user explicitly invokes: "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking"

When NOT to use:

• The ask is unambiguous and self-contained ("rename this variable", "fix this typo")
• The user has explicitly asked for speed over verification
• Pure information requests ("how does X work?", "what does this code do?")
• Mechanical operations (renames, formats, file moves)
• You already have ≥95% confidence; re-read the stop condition below before assuming you don't

Loading Constraints

This skill needs a live, responsive user. Do not invoke in non-interactive contexts like CI pipelines, scheduled runs, /loop, or autonomous-loop. If you're in one of those and the ask is underspecified, flag that as a blocker for the user instead of guessing.

The Process

Step 1: Hypothesize, with a confidence number

Before asking anything, write down your current best read of what the user wants in one sentence, plus an honest confidence number (0–100%):

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

The number forces honesty. If you wrote down a high number but can't actually predict the user's reactions to the next three questions you'd ask, the number is wrong. Start at the confidence level you can defend.

When confidence is below ~70%, append a brief reason on the same line — what's still unresolved or missing. This tells the user exactly what the interview needs to surface, and prevents the number from being a vague signal.

Step 2: Ask one question at a time with clear choices

Format:

Q (Blocking / Non-blocking): <one focused question; work blocked or answer needed by when>
A. <choice> — <practical consequence>
B. <choice> — <practical consequence>
READ: <your best hypothesis and brief reason, if supported>

Default to 2–3 choices and use an available interactive question tool; otherwise use a short labeled list. Allow a custom answer. For a decision where you have a supported lean, put that option first and mark it Recommended, with a short reason tied to the user's priorities. A hypothesis about their audience or experience is not a recommendation about what that fact should be. Use a focused free-text prompt when choices would distort the answer. Label the question Blocking and name the work awaiting its answer, or Non-blocking and state when the answer is needed. Wait for the user to react before asking the next dependent question.

Why one at a time, not a batch:

• The user can't react to your hypotheses if you bury them in a list
• Batches encourage skim-reading and surface answers
• The third question often depends on the answer to the first; asking them all at once locks in the wrong framing
• The user's energy for thinking carefully is finite; spend it one question at a time

Why attach a guess:

• The user reacts faster to a wrong guess than they generate an answer from scratch
• It commits you to a hypothesis you can be visibly wrong about, which keeps you honest
• It surfaces your assumptions, which is what the interview is meant to expose

The risk here is a polite user agreeing with your guess to be agreeable. Mitigate by offering credible alternatives, welcoming corrections, and stating uncertainty honestly. Never deliberately offer a misleading guess to provoke disagreement.

Step 3: Listen for "want vs. should want"

The most dangerous answers are the ones where the user says what a thoughtful answer sounds like rather than what they actually want. Watch for:

• Answers that pattern-match best-practice talk ("I want it to be scalable", "clean architecture") without specifics
• Answers that defer to convention ("the way most apps do it", "the standard approach")
• Phrases like "I should probably…", "I think I'm supposed to…", "good engineering practice says…"
• Buzzwords as goals — when "modern", "scalable", "robust" are the answer instead of a specific outcome

When you hear these, the question to ask is:

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

That single question often does more work than the previous five.

Step 4: Restate intent in the user's own words

When your confidence is high, write back what you now think the user wants. Keep it tight (5–8 lines), use their language where possible, and structure it so the user can confirm or correct line by line:

Here's what I now think you want:

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

Yes / no / refine?

Including "Out of scope" is non-negotiable. Half of misalignment is silent disagreement about what is not being built.

Step 5: Resolve Remaining Intent

Use the user's answers, corrections, and delegated judgment to establish actionable intent. A clear instruction to proceed or choose within stated constraints is authorization; do not demand a particular word or reject delegation as uncertainty. Resolve routine reversible choices and record them in the restatement.

Ask another question only when a material outcome, audience, constraint, or trade-off remains unresolved and cannot be inferred responsibly. Silence does not answer a required question. When the user corrects the goal, update the restatement; do not repeatedly reconfirm an unchanged decision. A requested interview ends with its intent summary; an end-to-end assignment continues into the selected workflow within scope.

The 95% Confidence Stop

You're done when you can answer yes to this:

Can I predict the user's reaction to the next three questions I would ask?

If yes, you have shared understanding. Stop interviewing and produce the restate. If no, you're not done; ask the next question.

This is a checkable test, not a vibe. It also has a floor: if you've gone several rounds and still can't predict, that's information about the ask, not a reason to keep grinding. Stop and tell the user: "I've asked X questions and I still can't predict your reactions. Something foundational is missing. Want to step back?"

Output

The output of this skill is a confirmed statement of intent: the restate from Step 4, with material intent resolved in Step 5 and delegated choices identified. That's the deliverable. Specs, plans, and task lists are downstream; they consume the intent this skill produces.

If the user wants the intent to persist (a multi-session project, a handoff to another collaborator), save it to docs/intent/[topic].md when persistence is already authorized by the request. A conversational interview alone does not require saving a file or another permission prompt.

For an authorized saved brief, add one YAML header with type: Intent Brief, a descriptive title, and a one-sentence description, using the memory-management document-metadata profile. Record confirmation of intent separately from document maturity; do not infer implementation approval or create a track just to save the brief. The conversational restatement needs no header.

Example

A short before-and-after.

Without interview-me:

User:  build me a dashboard for our metrics
Agent: <starts proposing chart libraries and layouts>

The agent has assumed: who it's for, what metrics, what "for our team" means, what success looks like. None of these are stated. Every assumption is a place the user can later say "that's not what I meant."

With interview-me:

User: build me a dashboard for our metrics

Agent:
HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" came to mind because that's the conventional answer.
CONFIDENCE: ~30% — missing: who it's for, what "metrics" are, and what success looks like

Q (Blocking): Who needs this view? This determines which information to show and needs answering before design.
A. Just me — organize information for personal decisions.
B. Engineering team — support shared discussion in standup.
C. Leadership — summarize outcomes for reporting.
READ: Possibly the engineering team because you said "our metrics," but that is uncertain. A different audience is welcome.

User: It's actually for me. I keep losing track of which experiments are running and what their early signal looks like.

Agent:
Updated read: not a team dashboard at all. It's a personal experiment tracker. Confidence: ~60% — still missing: what "early signal" means and what done looks like.

Q (Blocking): Which gap matters most? Selecting the first useful feature depends on this answer.
A. Finding which experiments exist — collect an inventory.
B. Seeing results together — combine their early signals.
READ: Possibly B because you mentioned signals; correct me if neither fits.

User: First one actually. I literally don't have a list. They're spread across different docs.

Agent: <continues>

Two questions in, the agent has discovered the actual ask isn't "a dashboard." It's "a list." Different artifact, different scope, different work. The dashboard would have been wrong.

Interaction with Other Skills

• idea-refine: downstream. If the confirmed intent is "I want X but I don't know how to scope it," hand off to idea-refine to generate variations against the now-explicit intent.
• spec-driven-development: downstream. If the confirmed intent is concrete ("I want X for Y users with Z success criteria"), hand off to spec-driven-development to write it down.
• planning-and-task-breakdown: two hops downstream of this skill (after the spec).
• doubt-driven-development: opposite end of the timeline. Interview-me is pre-decision intent extraction; doubt-driven is post-decision artifact review. Both catch divergence, but at different moments.
• source-driven-development: orthogonal. Interview-me clarifies what the user wants; SDD verifies framework facts. They don't compete.

Common Rationalizations

Red Flags

• Three or more questions in a single message: that's batching, not interviewing
• A decision question with no clear choices or no reason for a supported recommendation
• Presenting an uncertain hypothesis as a fact, or inventing a lean to fill the format
• Rejecting delegated judgment and asking the same resolved question again
• Proceeding while a material intent question remains unresolved, or exceeding an interview-only request
• Questions framed as "what would be best practice?" instead of "what do you actually want?"
• The user gives a sophistication-signaling answer ("scalable", "clean", "modern") and you accept it without probing whether it's what they actually want
• Three or more rounds without your confidence visibly rising: you're asking the wrong questions, step back and reframe
• A confidence number below ~70% with no reason attached: the user can't help close the gap if they don't know what's missing
• Saving outside authorized scope or presenting an agent assumption as human approval
• Skipping the "Out of scope" line in the restate (silent disagreement about non-goals is half of misalignment)

Verification

After applying interview-me:

• An explicit hypothesis with a confidence number was stated in the first turn
• Every confidence number below ~70% was accompanied by a one-line reason (what's still unresolved or missing)
• Questions were asked one at a time with clear choices where useful, custom answers allowed, and honest hypotheses distinguished from recommendations
• Supported recommendations appeared first with a brief reason; factual questions did not prescribe an answer
• At least one "what would you actually want if you didn't have to justify it?" probe ran when the user gave a sophistication-signaling or convention-signaling answer
• A concrete restate (Outcome / User / Why now / Success / Constraint / Out of scope) was written back to the user
• Material intent is resolved from actual answers or authorized delegation; no new confirmation was required for an unchanged decision
• At the stop point, the agent could predict reactions to the next three questions it would ask
• Any handoff to a downstream skill (idea-refine, spec-driven-development) was framed in terms of the confirmed intent, not the original underspecified ask