<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-planskill 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 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
exploreagent 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, orteam. 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>
Phase 1: Initialize
- Parse the user's idea from
{{ARGUMENTS}} - Detect brownfield vs greenfield:
- Run
exploreagent (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
- Run
- For brownfield: Run
exploreagent to map relevant codebase areas, store ascodebase_context - 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": []
}
}
- Announce the interview to the user:
Starting deep interview. I'll ask targeted questions to understand your idea thoroughly before building anything. After each answer, I'll show your clarity score. We'll proceed to execution once ambiguity drops below 20%.
Your idea: "{initial_idea}" Project type: {greenfield|brownfield} Current ambiguity: 100% (we haven't started yet)
Phase 2: Interview Loop
Repeat until ambiguity ≤ threshold OR user exits early:
Step 2a: Generate Next Question
Build the question generation prompt with:
- The user's original idea
- All prior Q&A rounds (conversation history)
- Current clarity scores per dimension (which is weakest?)
- Challenge agent mode (if activated -- see Phase 3)
- Brownfield codebase context (if applicable)
Question targeting strategy:
- Identify the dimension with the LOWEST clarity score
- Generate a question that specifically improves that dimension
- State, in one sentence before the question, why this dimension is now the bottleneck to reducing ambiguity
- Questions should expose ASSUMPTIONS, not gather feature lists
- If the scope is still conceptually fuzzy (entities keep shifting, the user is naming symptoms, or the core noun is unstable), switch to an ontology-style question that asks what the thing fundamentally IS before returning to feature/detail questions
Question styles by dimension:
| Dimension | Question Style | Example |
|---|---|---|
| Goal Clarity | "What exactly happens when...?" | "When you say 'manage tasks', what specific action does a user take first?" |
| Constraint Clarity | "What are the boundaries?" | "Should this work offline, or is internet connectivity assumed?" |
| Success Criteria | "How do we know it works?" | "If I showed you the finished product, what would make you say 'yes, that's it'?" |
| Context Clarity (brownfield) | "How does this fit?" | "I found JWT auth middleware in src/auth/ (pattern: passport + JWT). Should this feature extend that path or intentionally diverge from it?" |
| Scope-fuzzy / ontology stress | "What IS the core thing here?" | "You have named Tasks, Projects, and Workspaces across the last rounds. Which one is the core entity, and which are supporting views or containers?" |
Step 2b: Ask the Question
Use AskUserQuestion with the generated question. Present it clearly with the current ambiguity context:
Round {n} | Targeting: {weakest_dimension} | Why now: {one_sentence_targeting_rationale} | Ambiguity: {score}%
{question}
Options should include contextually relevant choices plus free-text.
Step 2c: Score Ambiguity
After receiving the user's answer, score clarity across all dimensions.
Scoring prompt (use opus model, temperature 0.1 for consistency):
Given the following interview transcript for a {greenfield|brownfield} project, score clarity on each di