interview

<Use_When>

• The user brings a fuzzy idea/feature/spec and wants the ambiguity pinned down into concrete requirements before planning or building.
• Before /autopilot or /ralplan, when the request is too ambiguous for the non-interactive Phase 1 intake (which stops PHASE1_AMBIGUOUS) — run this first to produce the spec.md it will reuse.
• analyst or /autopilot Phase 1 reported ambiguity above threshold and you want to close the gaps interactively rather than rewrite the idea by hand.
• The user would rather be asked targeted questions with candidate answers than free-write a full spec.
• Trigger phrases (EN): "clarify this", "ask me what you need to build this", "interview me to nail down the requirements", "/interview".
• Trigger phrases (KO): "이거 애매한데 질문해서 정리해줘", "요구사항 명확히 해줘", "모호한 부분 짚어서 스펙으로 만들어줘". </Use_When>

<Do_Not_Use_When>

• The request is already unambiguous — skip clarification and go straight to /ralplan or /autopilot.
• The user wants to reach their OWN design decisions by being questioned, without being handed candidate answers or a finished spec — that is buddy:socratic-interview (it keeps the pen in their hand; this skill resolves the ambiguity for them and emits an artifact).
• The user just wants it built now ("그냥 만들어줘", "just build it") — go to /autopilot or /ralph.
• It is a simple factual lookup (an API signature, how a library behaves) — answer directly.
• A vetted plan already exists and only execution remains — use /ralph or /team. </Do_Not_Use_When>

<Why_This_Exists> The orchestration pipeline's Phase 1 intake is deliberately non-interactive: analyst scores the idea's ambiguity and, if it is above --threshold, /autopilot stops PHASE1_AMBIGUOUS and asks for a clearer idea or a pre-written spec.md — it will not interview in-loop. That leaves a gap: someone has to turn the fuzzy idea into that clearer spec. This skill is that step. It reuses the same analyst decomposition the pipeline already trusts, but adds the interactive resolution loop autopilot intentionally omits — asking the user to settle each ambiguity via AskUserQuestion with concrete options — and emits the exact spec.md the pipeline consumes. It is the front door to the pipeline for anything that starts vague. (For sharpening your own thinking without being handed answers, that is a different goal — see buddy:socratic-interview.) </Why_This_Exists>

<Execution_Policy>

• Always run the analyst decomposition first — do NOT hand-roll the ambiguity analysis. analyst is the sanctioned engine for requirement decomposition, assumption classification (Stated/Inferred/Speculative), clarity scoring, and gap-with-clarifying-question output.
• Resolve open points via AskUserQuestion. Give each question 2–4 concrete candidate answers grounded in analyst's assumptions/gaps and the codebase — the user picks rather than free-writing a spec.
• A marked default is allowed here. Unlike buddy:socratic-interview, this skill exists to resolve ambiguity, so it MAY mark a sensible default (Recommended) (place it first) where one clearly fits — e.g. an assumption analyst labeled Inferred with an obvious conventional default. Never fabricate a default where the choice is genuinely open; leave those to the user.
• Batch independent clarifications into a single AskUserQuestion call (up to 4 questions). Sequence questions only when a later one genuinely depends on an earlier answer — then ask the blocking one first and re-carve the next from the answer.
• Trust "Other" as the escape hatch. AskUserQuestion always offers free-text "Other"; do not fabricate a "none of these" option.
• Prioritize by leverage. Resolve the ambiguities that most reduce aggregate ambiguity first (lowest-clarity dimensions, gaps blocking the most requirement units). Do NOT ask about points already settled by $ARGUMENTS or the codebase.
• Fold every answer into the spec as a concrete requirement, constraint, or acceptance criterion; record which prior assumption or gap it resolved.
• Stop at the gate. Stop when residual ambiguity is low (mirror the pipeline gate: 1 − weighted clarity ≤ --threshold, default 0.2) or when the user chooses to stop. Never force completion.
• Read-only on the user's code. Read to ground the questions; never modify source. The only sanctioned write is the clarified spec.md.
• Conduct the interview (question + option text) and write the spec in $LANGUAGE; structural headers (## Goal, ## Requirements, ## Constraints, ## Acceptance Criteria) stay English per repo convention — only their content is translated.
• Output placement: slug context (--slug=<slug> or an active hand-off slug) → write .dt-handoff/<slug>/spec.md with descriptor frontmatter and tell the user it is ready for /autopilot / /ralplan. Free-standing (no slug) → present the spec inline; write a file only if the user names a path or accepts a derived slug (confirm once). Never auto-commit or open a PR. </Execution_Policy>