dev-deep-interview

name	dev-deep-interview
description	Socratic questioning to crystallize vague requirements into a testable spec. Use when input is ambiguous, when the user asks for "deep interview", or before dev-autopilot if the brief is too broad. Pairs with @echo-analyst.

Dev Deep Interview

Derived from oh-my-claudecode (MIT, Yeachan Heo). Adapted for the EvoNexus Engineering Layer.

Deep Interview transforms vague ideas into concrete, testable specifications through Socratic questioning. It is the front gate of any high-stakes work — refusing to proceed until ambiguity is below an acceptable threshold.

Use When

• User has a vague idea ("build me something cool", "improve performance", "fix the UX")
• Before dev-autopilot when input lacks file paths, function names, or concrete anchors
• User explicitly asks for "deep interview", "interview me", "ask me questions first"
• High-stakes work where the cost of misunderstanding is high (auth, billing, migrations)

Do Not Use When

• User has already provided a detailed spec or plan
• Task is trivially clear (typo fix, single-line change)
• User says "just do it" or "skip the questions"

Goal

Drive ambiguity below 20% before any code or plan is generated. Output a spec that an executor agent can implement without further clarification.

Workflow

Phase 1 — Initial Assessment

Read the user's input. Score it on these dimensions (1-5 each, 5 = clear):

• Domain clarity: do you understand WHAT this is about?
• Scope: do you know what is in/out of scope?
• Success criteria: do you know what "done" looks like?
• Constraints: do you know technical/business limits?
• Stakeholders: do you know who cares and what they want?

If average ≥ 4: skip interview, proceed. If average < 4: enter interview loop.

Phase 2 — Socratic Loop

Ask one question at a time using AskUserQuestion (with 2-4 multiple-choice options when possible). Each question must:

• Target the lowest-scoring dimension
• Be answerable in under a sentence (or by clicking an option)
• Eliminate at least one ambiguity

Common question types:

• Scope: "Should X be included or out of scope?"
• Trade-off: "Optimize for speed or simplicity?"
• Stakeholder: "Who is the primary user — admin, customer, internal?"
• Constraint: "Any budget/time/tech constraints?"
• Success: "How will we know this worked?"

Stop the loop when all dimensions ≥ 4 OR after 8 questions (whichever first — long interviews lose user patience).

Phase 3 — Spec Output

Write the spec to workspace/projects/specs/[C]deep-interview-{name}.md with this structure:

# Deep Interview Spec — {topic}

**Date:** {iso}
**Ambiguity score:** {avg}/5

## Context
[1-2 sentences on the problem and why it matters]

## In Scope
- [item 1]
- [item 2]

## Out of Scope
- [explicit non-goals]

## Success Criteria
- [testable criterion 1]
- [testable criterion 2]

## Constraints
- [tech / business / time]

## Open Questions
- [items where ambiguity remains, with risk level]

## Suggested Next Step
- `dev-autopilot` (if all dimensions ≥ 4)
- `dev-plan` (if some dimensions still < 4 but you want to start scoping)
- Manual implementation (if the spec is small enough)

Rules

• One question at a time. Never batch.
• Use clickable options (AskUserQuestion) whenever possible.
• Don't ask codebase facts — spawn @scout-explorer to look them up.
• Stop at 8 questions. Longer kills user patience.
• Always output a spec file, even if interview was short.

Pairs With

• @echo-analyst — for deeper requirements gap analysis after the interview
• dev-autopilot — natural next step once spec is ready
• dev-plan — if you want to scope further before execution

Failure Modes To Avoid

• Interrogation: 15 questions in a row. Stop at 8.
• Codebase questions: "What framework do you use?" → look it up yourself.
• Vague answers accepted: "I want it fast" → push: "Faster than what — the current 2s, or the user-perceived 200ms?"
• No spec output: interview without persistence is wasted.