<Purpose>
Deep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.
</Purpose>
<Use_When>
The request is broad, ambiguous, or missing concrete acceptance criteria
The user says "deep interview", "interview me", "ask me everything", "don't assume", or "ouroboros"
The user wants to avoid misaligned implementation from underspecified requirements
You need a requirements artifact before handing off to ralplan, autopilot, ralph, or team
</Use_When>
<Do_Not_Use_When>
The request already has concrete file/symbol targets and clear acceptance criteria
The user explicitly asks to skip planning/interview and execute immediately
The user asks for lightweight brainstorming only (use plan instead)
A complete PRD/plan already exists and execution should start
</Do_Not_Use_When>
<Why_This_Exists>
Execution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.
</Why_This_Exists>
Quick (--quick): fast pre-PRD pass; target threshold <= 0.30; max rounds 5
Standard (--standard, default): full requirement interview; target threshold <= 0.20; max rounds 12
Deep (--deep): high-rigor exploration; target threshold <= 0.15; max rounds 20
Autoresearch (--autoresearch): same interview rigor as Standard, but specialized for omx autoresearch launch readiness and .omx/specs/ mission/sandbox artifact handoff
If no flag is provided, use Standard.
<Mode_Flags>
--autoresearch: switch the interview into autoresearch-intake mode for omx autoresearch handoff. In this mode, the interview should converge on a launch-ready research mission, write canonical artifacts under .omx/specs/, and preserve the explicit refine further vs launch boundary for downstream CLI intake.
</Mode_Flags>
</Depth_Profiles>
<Execution_Policy>
Ask ONE question per round (never batch)
Ask about intent and boundaries before implementation detail
Target the weakest clarity dimension each round after applying the stage-priority rules below
Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom
Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter
Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up
Gather codebase facts via explore before asking user about internals
When session guidance enables USE_OMX_EXPLORE_CMD, prefer omx explore for simple read-only brownfield fact gathering; keep prompts narrow and concrete, and keep ambiguous or non-shell-only investigation on the richer normal path and fall back normally if omx explore is unavailable.
Always run a preflight context intake before the first interview question
Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly
For brownfield work, prefer evidence-backed confirmation questions such as "I found X in Y. Should this change follow that pattern?"
In Codex CLI, prefer request_user_input when available; if unavailable, fall back to concise plain-text one-question turns
Re-score ambiguity after each answer and show progress transparently
Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning
Do not crystallize or hand off while Non-goals or Decision Boundaries remain unresolved, even if the weighted ambiguity threshold is met
Treat early exit as a safety valve, not the default success path
Persist mode state for resume safety (state_write / state_read)
</Execution_Policy>
Phase 0: Preflight Context Intake
Parse {{ARGUMENTS}} and derive a short task slug.
Attempt to load the latest relevant context snapshot from .omx/context/{slug}-*.md.
If no snapshot exists, create a minimum context snapshot with:
Task statement
Desired outcome
Stated solution (what the user asked for)
Probable intent hypothesis (why they likely want it)
Known facts/evidence
Constraints
Unknowns/open questions
Decision-boundary unknowns
Likely codebase touchpoints
Save snapshot to .omx/context/{slug}-{timestamp}.md (UTC YYYYMMDDTHHMMSSZ) and reference it in mode state.
Phase 1: Initialize
Parse {{ARGUMENTS}} and depth profile (--quick|--standard|--deep).
Detect project context:
Run explore to classify brownfield (existing codebase target) vs greenfield.
For brownfield, collect relevant codebase context before questioning.
Initialize state via state_write(mode="deep-interview"):
Announce kickoff with profile, threshold, and current ambiguity.
Phase 2: Socratic Interview Loop
Repeat until ambiguity <= threshold, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached.
2a) Generate next question
Use:
Original idea
Prior Q&A rounds
Current dimension scores
Brownfield context (if any)
Activated challenge mode injection (Phase 3)
Target the lowest-scoring dimension, but respect stage priority:
Decision Boundaries (what OMX may decide without confirmation)
Constraints
Testable acceptance criteria
Assumptions exposed + resolutions
Pressure-pass findings (which answer was revisited, and what changed)
Brownfield evidence vs inference notes for any repository-grounded confirmation questions
Technical context findings
Full or condensed transcript
Autoresearch specialization
When the clarified task is specifically about omx autoresearch, or the skill is invoked with --autoresearch, keep the interview domain-specific and emit launch-consumable artifacts without skipping clarification.
Required interview focus: mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further
Required launch artifacts under .omx/specs/autoresearch-{slug}/:
mission.md
sandbox.md
result.json
Launch-readiness rule: mark the draft as not launch-ready while the evaluator command still contains placeholder markers such as <...>, TODO, TBD, REPLACE_ME, CHANGEME, or your-command-here
Structured result contract:result.json should point to the draft + mission/sandbox artifacts and carry the finalized topic, evaluatorCommand, keepPolicy, slug, launchReady, and blockedReasons fields so omx autoresearch can consume it directly
Confirmation bridge: after artifact generation, offer at least refine further and launch; do not launch detached tmux until the user explicitly confirms launch
Handoff rule: downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step
Phase 5: Execution Bridge
Present execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, and any residual-risk warnings across the handoff.
1. $ralplan (Recommended)
Input Artifact:.omx/specs/deep-interview-{slug}.md (optionally accompanied by the transcript/context snapshot for traceability)
Invocation:$plan --consensus --direct <spec-path>
Consumer Behavior: Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.
Skipped / Already-Satisfied Stages: Requirements discovery, ambiguity clarification, and early intent-boundary elicitation
Expected Output: Canonical planning artifacts under .omx/plans/, especially prd-*.md and test-spec-*.md
Best When: Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable
Next Recommended Step: Use the approved planning artifacts with $autopilot, $ralph, or $team depending on the desired execution style
Consumer Behavior: Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.
Skipped / Already-Satisfied Stages: Initial requirement discovery and ambiguity reduction
Expected Output: Planning/execution progress, QA evidence, and validation artifacts produced by autopilot
Best When: The clarified spec is already strong enough for direct planning + execution without an additional consensus gate
Next Recommended Step: Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer a follow-up $team or $ralph lane as appropriate
Consumer Behavior: Use the spec's acceptance criteria and boundary constraints as the persistence target. Do not reopen requirements discovery unless the user explicitly asks to refine further.
Skipped / Already-Satisfied Stages: Requirement interview, ambiguity clarification, and initial scope-definition work
Expected Output: Iterative execution progress and verification evidence tracked against the clarified criteria
Best When: The task benefits from persistent sequential completion pressure and the user wants execution to keep moving until the criteria are satisfied or a real blocker exists
Next Recommended Step: Continue Ralph's persistence loop; if work expands into coordination-heavy lanes, hand off to $team and keep Ralph for verification continuity
Consumer Behavior: Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.
Skipped / Already-Satisfied Stages: Requirement clarification and early ambiguity reduction
Expected Output: Coordinated multi-agent execution against the shared spec, with evidence that can later feed a Ralph verification pass when appropriate
Best When: The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop
Next Recommended Step: Follow the team verification path when the coordinated execution phase finishes; escalate to a separate Ralph loop only when a later persistent verification/fix owner is still needed
5. Refine further
Input Artifact: Existing transcript, context snapshot, and current spec draft
Invocation: Continue the interview loop
Consumer Behavior: Re-enter questioning to resolve the highest-leverage remaining uncertainty
Expected Output: A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions
Best When: Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly
Next Recommended Step: Return to one of the execution handoff contracts above once the spec is sufficiently clarified
Residual-Risk Rule: If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.
IMPORTANT: Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. Do NOT implement directly inside deep-interview.
<Tool_Usage>
Use explore for codebase fact gathering
Use request_user_input / structured user-input tool for each interview round when available
If structured question tools are unavailable, use plain-text single-question rounds and keep the same stage order
Use state_write / state_read for resumable mode state
Read/write context snapshots under .omx/context/
Save transcript/spec artifacts under .omx/interviews/ and .omx/specs/
</Tool_Usage>
<Escalation_And_Stop_Conditions>
User says stop/cancel/abort -> persist state and stop
Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once
Max rounds reached -> proceed with explicit residual-risk warning
All dimensions >= 0.9 -> allow early crystallization even before max rounds
</Escalation_And_Stop_Conditions>
<Final_Checklist>
Preflight context snapshot exists under .omx/context/{slug}-{timestamp}.md
Ambiguity score shown each round
Intent-first stage priority used before implementation detail
Weakest-dimension targeting used within the active stage
At least one explicit assumption probe happened before crystallization
At least one persistent follow-up / pressure pass deepened a prior answer
Challenge modes triggered at thresholds (when applicable)
Transcript written to .omx/interviews/{slug}-{timestamp}.md
Spec written to .omx/specs/deep-interview-{slug}.md
Brownfield questions use evidence-backed confirmation when applicable