/deep-interview

name: deep-interview
type: workflow
description: "Conducts a structured technical deep-dive to gather detailed requirements, constraints, and decisions from the user. Use when starting a complex feature or when the user wants to be asked structured clarifying questions before implementation."
argument-hint: "[--quick|--standard|--deep] [--autoresearch] <idea or vague description>"
pipeline: [deep-interview, omc-plan, autopilot]
next-skill: omc-plan
next-skill-args: --consensus --direct
handoff: .omc/specs/deep-interview-{slug}.md
level: 3
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
user-invocable: true
effort: 3
when_to_use: "Use when the user has a vague idea and wants structured requirements gathering before implementation, or says 'interview me', 'ask me everything', 'don't assume', or 'ouroboros'."

<Purpose> Deep Interview implements Ouroboros-inspired Socratic questioning with mathematical ambiguity scoring. It replaces vague ideas with crystal-clear specifications by asking targeted questions that expose hidden assumptions, measuring clarity across weighted dimensions, and refusing to proceed until ambiguity drops below a configurable threshold (default: 20%). The output feeds into a 3-stage pipeline: **deep-interview → ralplan (consensus refinement) → autopilot (execution)**, ensuring maximum clarity at every stage. </Purpose>

<Use_When>

• User has a vague idea and wants thorough requirements gathering before execution
• User says "deep interview", "interview me", "ask me everything", "don't assume", "make sure you understand"
• User says "ouroboros", "socratic", "I have a vague idea", "not sure exactly what I want"
• User wants to avoid "that's not what I meant" outcomes from autonomous execution
• Task is complex enough that jumping to code would waste cycles on scope discovery
• User wants mathematically-validated clarity before committing to execution

</Use_When>

<Do_Not_Use_When>

• User has a detailed, specific request with file paths, function names, or acceptance criteria -- execute directly
• User wants to explore options or brainstorm -- use `omc-plan` skill instead
• User wants a quick fix or single change -- delegate to executor or ralph
• User says "just do it" or "skip the questions" -- respect their intent
• User already has a PRD or plan file -- use ralph or autopilot with that plan

</Do_Not_Use_When>

<Why_This_Exists> AI can build anything. The hard part is knowing what to build. OMC's autopilot Phase 0 expands ideas into specs via analyst + architect, but this single-pass approach struggles with genuinely vague inputs. It asks "what do you want?" instead of "what are you assuming?" Deep Interview applies Socratic methodology to iteratively expose assumptions and mathematically gate readiness, ensuring the AI has genuine clarity before spending execution cycles.

Inspired by the [Ouroboros project](https://github.com/Q00/ouroboros) which demonstrated that specification quality is the primary bottleneck in AI-assisted development. </Why_This_Exists>

<Execution_Policy>

• Ask ONE question at a time -- never batch multiple questions
• Target the WEAKEST clarity dimension with each question
• Make weakest-dimension targeting explicit every round: name the weakest dimension, state its score/gap, and explain why the next question is aimed there
• Gather codebase facts via `explore` agent BEFORE asking the user about them
• For brownfield confirmation questions, cite the repo evidence that triggered the question (file path, symbol, or pattern) instead of asking the user to rediscover it
• Score ambiguity after every answer -- display the score transparently
• Do not proceed to execution until ambiguity ≤ threshold (default 0.2)
• Allow early exit with a clear warning if ambiguity is still high
• Persist interview state for resume across session interruptions
• Challenge agents activate at specific round thresholds to shift perspective

</Execution_Policy>

<Autoresearch_Mode> When arguments include `--autoresearch`, Deep Interview becomes the zero-learning-curve setup lane for `omc autoresearch`.

• If no usable mission brief is present yet, start by asking: **"What should autoresearch improve or prove for this repo?"**
• After the mission is clear, collect an evaluator command. If the user leaves it blank, infer one only when repo evidence is strong; otherwise keep interviewing until an evaluator is explicit enough to launch safely.
• Keep the usual one-question-per-round rule, but treat **mission clarity** and **evaluator clarity** as hard readiness gates in addition to the normal ambiguity threshold.
• Once ready, do **not** bridge into `omc-plan`, `autopilot`, `ralph`, or `team`. Instead run:
• `omc autoresearch --mission "<mission>" --eval "<evaluator>" [--keep-policy <policy>] [--slug <slug>]`
• This direct handoff is expected to detach into the real autoresearch runtime tmux session. After a successful handoff, announce the launched session and end the interview lane.

</Autoresearch_Mode>

<Steps>

Phase 1: Initialize

1. **Parse the user's idea** from `{{ARGUMENTS}}` 2. **Detect brownfield vs greenfield**:

• Run `explore` agent (haiku): check if cwd has existing source code, package files, or git history
• If source files exist AND the user's idea references modifying/extending something: **brownfield**
• Otherwise: **greenfield**

3. **For brownfield**: Run `explore` agent to map relevant codebase areas, store as `codebase_context` 4. **Initialize state** via `state_write(mode="deep-interview")`:

{
  "active": true,
  "current_phase": "deep-interview",
  "state": {
    "interview_id": "<uuid>",
    "type": "greenfield|brownfield",
    "initial_idea": "<user input>",
    "rounds": [],
    "current_ambiguity": 1.0,
    "threshold": 0.2,
    "codebase_context": null,
    "challenge_modes_used": [],
    "ontology_snapshots": []
  }
}

5. **Announce the interview** to the user:

> Starting deep interview. I'll ask targe