interview-me

Interview Me

Resolve the user's known unknowns by interviewing them, one question at a time, before any implementation.

Workflow

1. Build the question list silently. From the conversation, any blindspot-pass findings if that ran first, plus a quick scan of relevant code (for greenfield work with no code yet, the conversation alone), list the ambiguities in the task. For each, note which layer the answer would change: architecture/data model > scope/behavior > UX details > cosmetics. Sort by that impact; when one answer gates other questions, ask the gating question first. If the list holds 10+ architecture-level ambiguities, propose splitting the task instead of interviewing through it. Open by telling the user how many questions you plan to ask, architecture first.
2. Ask one question at a time. Use the structured question tool when available (in Cursor, the AskQuestion option card; in Claude Code, the AskUserQuestion tool). Never ask a bare open-ended "what do you want?". For decision questions:
   • Present 2-4 concrete options, recommended option first, marked "(recommended)" in its label.
   • Say why the answer matters (what it would change) and the trade-offs in the question body; keep option labels short.
   • Treat a free-text answer outside the listed options as a first-class answer. For fact questions (who the users are, how much data), ask openly — options, if offered, are "e.g." examples, never a forced choice.
3. Re-plan after every answer. The question list is a living document: drop questions the answer resolved, rewrite options it invalidated, add ambiguities it exposed. If an answer does not address the question, restate it once — that is not re-asking. If it introduces a new requirement, do not expand it that turn: batch-ask which of the new items are in or out of scope; after three consecutive turns of new requirements, pause the interview and re-scope the task. If the user changes a requirement mid-interview, say which earlier decisions it affects, update those, and rebuild the remaining list.
4. Stop early. End the interview once remaining unknowns would not change the approach — typically 3-7 questions. At question 7, if approach-changing unknowns still remain, stop asking one-by-one: lay out the remaining list in a single message, let the user pick what to settle now, and record the rest as assumptions. Never pad with questions you could answer yourself from the code; go read the code instead.
5. Deliver the decision record. Summarize in chat, in the language of the conversation, as a compact decision record ("known knowns") with three parts: decisions made; assumptions (defaults chosen in place of an answer); deliberately deferred unknowns, each with the assumption chosen for it. Classify by who chose: the user explicitly picked = decision; the user explicitly postponed = deferred; the agent defaulted = assumption. Write each decision on one line: chosen — why it matters — alternatives shown — depends on (which earlier decisions, if any). Before delivering, re-read the record for contradictions; the record reflects the latest state — when the user reverses a decision, rewrite its entry in place, never append a conflicting one. Keep it ready to paste into an implementation prompt or plan. If planning or implementation will happen in a later session (or the user asks), also write it to interview-decisions.md in the project root. Do not commit it unless the user asks; in a git repo, exclude it locally: n=interview-decisions.md; p="$(git rev-parse --git-path info/exclude 2>/dev/null)" && { mkdir -p "$(dirname "$p")" && { grep -qxF "$n" "$p" || echo "$n" >> "$p"; }; } 2>/dev/null || echo "note: could not exclude $n — leaving it untracked, never staging it" If planning comes next, hand this decision record to implementation-plan as its input.