Menu
Use only when the user explicitly asks for an interview, grilling, or intent-discovery conversation; do not invoke it for ordinary ambiguity.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use only when the user requests a code review or a dedicated pre-merge review; do not add it automatically after implementation.
Use only when the user explicitly requests simplification or a behavior-preserving clarity refactor.
Use only when the user requests context/rule optimization or an explicit session-recovery and handoff task; never use solely because a session starts.
Use only when the user explicitly requests documentation, an ADR, or an architecture-decision record; not for routine implementation notes.
Use only when the user explicitly requests adversarial review or a named high-risk decision needs an independent challenge; never for every unfamiliar task.
Use only when the user explicitly asks to ideate, refine an idea, or stress-test a plan before committing to it.
| name | interview-me |
| description | Use only when the user explicitly asks for an interview, grilling, or intent-discovery conversation; do not invoke it for ordinary ambiguity. |
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.
Apply this skill when:
When NOT to use:
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.
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.
Format:
Q: <one focused question>
GUESS: <your hypothesis for the answer, with the reasoning that produced it>
Wait for the user to react before asking the next question.
Why one at a time, not a batch:
Why attach a guess:
The risk here is a polite user agreeing with your guess to be agreeable. Mitigate by being visibly willing to be wrong, and occasionally guess in a direction you expect the user to push back on.
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:
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.
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.
The gate is an explicit "yes." The following are not yes:
If they correct you, fold the correction in and restate. Loop until you get an explicit yes.
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?"
The output of this skill is a confirmed statement of intent: the restate from Step 4, with an explicit yes from Step 5. 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), offer to save it to docs/intent/[topic].md. Only save if they confirm.
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: When you say "how are we doing?", who's asking — you alone, the engineering team in standup, or up the chain (e.g., your manager, an exec, a board)?
GUESS: engineering team in standup, because "we" usually scopes that way and standups are where this question gets asked. If it's for execs the metrics and the framing change a lot.
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: Is the gap that you don't know which experiments exist, or that you can't see their results in one place?
GUESS: the second one. You have a list of experiments somewhere, but their results live in five different tools, and reconciling them by hand is what you're tired of.
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.
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.| Rationalization | Reality |
|---|---|
| "The ask is clear enough" | If you can't write the user's desired outcome in one sentence right now, the ask isn't clear. Run Step 1 before deciding. |
| "Asking too many questions wastes their time" | Time wasted by 4–6 targeted questions is small. Time wasted by building the wrong thing is enormous, and the user is the one bearing that cost. |
| "I'll figure it out as I build" | Switching costs after code exists are 10x what they are now. Discovery during implementation is rework. |
| "They said 'whatever you think,' so I should just decide" | "Whatever you think" is delegation, not decision. Re-ask with two concrete options as a choice. |
| "I should give them several options to pick from" | Options work when the user knows what they want and is choosing between trade-offs. They don't know what they want yet. Listing options widens the search; asking narrows it. |
| "If I attach my guess, I'm leading them" | Leading is the point. Reacting is faster than generating from scratch. The risk is sycophancy, not leading; mitigate by being visibly willing to be wrong. |
| "We've talked enough, I get it" | Test it: can you predict their reaction to the next three questions? If not, you don't get it yet. |
| "The user said yes, we're done" | If the yes followed a vague restate or an open-ended "sounds good," the yes is hollow. Restate concretely and re-confirm. |
After applying interview-me:
idea-refine, spec-driven-development) was framed in terms of the confirmed intent, not the original underspecified ask