deep-interview

<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>

<Depth_Profiles>

• 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 $autoresearch mission readiness and .omx/specs/ artifact handoff

Profile max rounds is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.

If no flag is provided, use Standard.

<Mode_Flags>

• --autoresearch: switch the interview into autoresearch-intake mode for $autoresearch handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under .omx/specs/, and preserve the explicit refine further vs launch boundary for downstream skill intake. </Mode_Flags> </Depth_Profiles>

<Execution_Policy>

• Ask ONE question per round (never batch multiple interview rounds into one questions[] form)
• 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
• omx explore is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use omx sparkshell only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.
• Always run a preflight context intake before the first interview question
• For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable AGENTS.md files, README/getting-started docs, relevant docs/ contracts/plans/ADRs, existing .omx/context/ snapshots, and any project-local glossary/context files such as CONTEXT.md or CONTEXT-MAP.md when present.
• Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.
• Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.
• Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.
• Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.
• If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first
• The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff
• The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context
• Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current 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?"
• Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.
• When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use $best-practice-research as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.
• Use these transcript/spec labels only; never use them as omx question source values, and never replace the runtime source: "deep-interview" contract for user-facing deep-interview questions:
  • [from-code][auto-confirmed] — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.
  • [from-code] — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.
  • [from-research] — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.
  • [from-user] — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.
• Treat [from-code][auto-confirmed] and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call omx question, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.
• Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as [from-user] even when code or research facts are available.
• In attached-tmux Codex CLI, deep-interview uses omx question as the required OMX-owned structured questioning path for every interview round
• When invoking omx question through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with OMX_QUESTION_RETURN_PANE=$TMUX_PANE (or a concrete %pane value)
• If you launch omx question in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off
• Treat answers[] as the primary omx question success contract. For a single interview round, read answers[0].answer; use legacy top-level answer only as a compatibility fallback when needed.
• If the current runtime is outside tmux and cannot render omx question, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer
• Re-score ambiguity after each answer and show progress transparently
• Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.
• Treat max_rounds as a stop cap, not evidence that more rounds are needed.
• 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 only through the CLI/programmatic single-writer authority (omx state write/read --input '<json>' --json, backed by src/state/operations.ts). The MCP state server is a read-only projection and must never become a second writer. </Execution_Policy>