deep-interview

Ported from oh-my-codex deep-interview. OMX runtime conventions ($macro invocation, omx CLI, .omx/ state directory) are replaced with WorkBuddy idioms (Skill tool, Agent tool, task list, .workbuddy/memory).

<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 plan, team, or an execution workflow. </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 spec/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 downstream work begins with an explicit, testable, intent-aligned spec. </Why_This_Exists>

<Depth_Profiles>

• Quick (--quick): fast pre-spec 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.

Profile max rounds is a hard cap, not a target. Do not continue only to reach a numbered round count.

If no flag is provided, use Standard. </Depth_Profiles>

<Execution_Policy>

• Ask ONE question per round (never batch multiple interview rounds into one AskUserQuestion call).
• Ask about intent and boundaries before implementation detail.
• Target the weakest clarity dimension each round (see 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 repo inspection tools (Read, Grep, Glob, Bash) before asking the user about internals.
• 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 / CLAUDE.md files, README/getting-started docs, relevant docs/ contracts/plans/ADRs, 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.
• 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.
• 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. Recommend such updates in the handoff summary, but do not automatically create public docs from interview transcripts unless the user explicitly chooses that as in-scope.
• Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly.
• When unresolved ambiguity depends on current external best practices, invoke the best-practice-research skill as the bounded evidence wrapper before crystallizing requirements or handing off.
• Use these transcript/spec labels:
  • [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.
  • [from-research] — externally sourced facts (API limits, compatibility, public docs); 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 increment the user-facing round number for facts the agent can safely establish.
• Auto-confirm only descriptive facts. If a finding implies what the feature should do, which pattern to 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].
• Use the AskUserQuestion tool for every structured interview round. If it is unavailable, ask exactly one concise plain-text question in chat 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 the 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.
• Persist progress with the task list (TaskCreate/TaskUpdate) and/or append to .workbuddy/memory/YYYY-MM-DD.md; do not rely on any persistent "mode" file. </Execution_Policy>