deep-interview

<Use_When>

• 用户需要系统梳理相互关联的目标、范围、取舍与验收条件
• 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
• 活动工作流要求需求交接阶段；完整的既有规格可按下文复用 </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)
• 已有完整 PRD/plan 且用户要求直接执行；若活动 Autopilot 要求此阶段，则核对并复用规格后交接 </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
• Quick / Standard 只追问会改变实现或验收的缺口；答案已明确时继续收敛，不逐条要求用户举证。
• Deep 模式才要求至少一次明确的 pressure pass，追问关键假设或取舍；可复用当前任务已完成且仍有效的追问证据。
• 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
• Brownfield preflight 先读取适用的 AGENTS.md 与目标附近的代码或契约；仅在存在相关缺口时查阅 README、ADR、术语表或历史快照，可复用未变化的已读材料。
• 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.
• 核对可查明的当前行为；文档与代码冲突时说明证据，只有无法从既有需求确定预期且会改变结果时才提问。
• 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, read accessible source documents in bounded portions and record a faithful prompt-safe summary with source references. Ask the user only for inaccessible material or a decision-bearing ambiguity that cannot be resolved from those sources.
• The oversized initial-context summary gate requires a recorded faithful summary before scoring or handoff; an agent-authored summary satisfies it when the source is available. It is not an automatic user-summary request.
• 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
• 提问时给出相关仓库证据与待决定的具体取舍；符合既有授权的常规实现选择可直接说明并继续。
• 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] — 仓库推断或模式证据，注明置信度；优先补充可查证据，只将影响结果且无法自行确定的决策交给用户。
  • [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.
• 用户决定产品范围与实质取舍；已明确的需求和授权仍然有效。常规技术选择依据仓库契约解决，不能仅因发现可用模式就再次请求确认。
• 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 after each answer once a faithful context summary is available. A user-facing source request counts toward the profile's round cap; display ambiguity as not scored until the summary exists. If the cap is reached without it, report the incomplete intake and do not crystallize an execution-ready spec.
• 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>