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

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.

Phase 0: Preflight Context Intake

1. Parse {{ARGUMENTS}} and derive a short task slug.
2. Inspect the repo for an existing context snapshot under .omw/deep-interview/context-{slug}-*.md; load it if present.
3. If the provided initial context is too large for safe prompt use, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.
4. If no snapshot exists, create a minimum context snapshot with: task statement, desired outcome, stated solution, probable intent hypothesis, known facts/evidence, constraints, unknowns, decision-boundary unknowns, likely codebase touchpoints, relevant repo docs/rules inspected, terminology or doc/code conflicts, and summary status (not_needed / needed / recorded).
5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round: governing AGENTS.md/CLAUDE.md, README/docs (especially contracts, plans, ADRs), existing .omw/ snapshots and planning artifacts, and project-local glossary/context files.
6. Save the snapshot to .omw/deep-interview/context-{slug}-{timestamp}.md (UTC YYYYMMDDTHHMMSSZ).

Phase 1: Initialize

1. Parse {{ARGUMENTS}} and depth profile (--quick|--standard|--deep).
2. Detect project context: use repo inspection tools to classify brownfield (existing codebase target) vs greenfield. For brownfield, collect relevant codebase context before questioning.
3. Create a task list entry for the interview (e.g. "Deep interview: ") to track progress. Announce kickoff with profile, threshold, and current ambiguity (start 1.0).

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

If the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request.

Target the lowest-scoring dimension, respecting stage priority:

• Stage 1 — Intent-first: Intent, Outcome, Scope, Non-goals, Decision Boundaries.
• Stage 2 — Feasibility: Constraints, Success Criteria.
• Stage 3 — Brownfield grounding: Context Clarity (brownfield only).

Follow-up pressure ladder after each answer:

1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim.
2. Probe the hidden assumption, dependency, or belief that makes the claim true.
3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?
4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior.
5. Stress-test the boundary with one concrete scenario or edge case.
6. If the answer still describes symptoms, reframe toward essence / root cause.

Prefer staying on the same thread for multiple rounds when it has the highest leverage.

Maintain a Breadth Ledger across independent ambiguity tracks (scope, constraints, outputs, verification, brownfield integration, deliverables). Stay deep on the current thread until pressure-tested, then zoom out only when another material track remains unresolved.

Maintain a Docs/Terminology Ledger for brownfield interviews (sources inspected, canonical vs conflicting terms, doc/code mismatches, opt-in durable-doc follow-ups).

Detailed dimensions:

• Intent Clarity — why the user wants this.
• Outcome Clarity — what end state they want.
• Scope Clarity — how far the change should go.
• Constraint Clarity — technical or business limits that must hold.
• Success Criteria Clarity — how completion will be judged.
• Context Clarity — existing codebase understanding (brownfield only).

Non-goals and Decision Boundaries are mandatory readiness gates. Ask about them early and keep revisiting them until explicit.

2b) Ask the question

Use the AskUserQuestion tool for every interview round (one question per round). Present:

Round {n} | Target: {weakest_dimension} | Ambiguity: {score}%

{question}

For bounded single-choice rounds (e.g. handoff lane selection), provide 2–4 options via AskUserQuestion. For bounded multi-select (e.g. out-of-scope items, acceptance checks), enable multi-select. Keep options concrete; only allow a free-text "Other" when the answer genuinely cannot be enumerated.

2c) Score ambiguity

Score each weighted dimension in [0.0, 1.0] with justification + gap.

Greenfield: ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)

Brownfield: ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)

Readiness gate:

• Non-goals must be explicit.
• Decision Boundaries must be explicit.
• A pressure pass must be complete (at least one earlier answer revisited with an evidence/assumption/tradeoff follow-up).
• A practical closure audit must pass: another question would change execution materially, not merely polish wording.
• If either gate is unresolved, continue below threshold only with a final closure question that names the unresolved gate.
• If ambiguity is <= 0.10, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.

2d) Report progress

Show weighted breakdown table, readiness-gate status (Non-goals, Decision Boundaries), and the next focus dimension. Append a short note to .workbuddy/memory/YYYY-MM-DD.md if useful.

2e) Round controls

• Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened.
• Dialectic Rhythm Guard: after 3 consecutive non-user or confirmation answers ([from-code][auto-confirmed], [from-code], or [from-research]), the next material user-facing round must solicit direct human judgment ([from-user]).
• Round 4+: allow explicit early exit with risk warning.
• Hard cap at profile max_rounds; never treat this cap as a desired interview length.

Phase 3: Challenge Modes (assumption stress tests)

Use each mode once when applicable:

• Contrarian (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions.
• Terminologist (brownfield, when a key term is fuzzy/overloaded/conflicts): force a canonical meaning against existing project language.
• Simplifier (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope.
• Ontologist (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing.

Track used modes in the task list / memory to prevent repetition.

Phase 4: Crystallize Artifacts

When threshold is met (or user exits with warning / hard cap):

1. Write interview transcript summary to .omw/deep-interview/interview-{slug}-{timestamp}.md.
2. Write execution-ready spec to .omw/deep-interview/spec-{slug}.md.

Spec should include:

• Metadata (profile, rounds, final ambiguity, threshold, context type).
• Context snapshot reference/path.
• Prompt-safe initial-context summary when oversized context was provided.
• Clarity breakdown table.
• Intent, Desired Outcome, In-Scope, Out-of-Scope / Non-goals, Decision Boundaries (what WorkBuddy may decide without confirmation), Constraints, Testable acceptance criteria.
• Assumptions exposed + resolutions.
• Pressure-pass findings.
• Brownfield evidence vs inference notes.
• Docs/Terminology Ledger.
• Scenario/edge-case pressure findings.
• Optional durable documentation recommendations (opt-in, public-safe).
• Technical context findings.
• Full or condensed transcript.

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.

1. plan (Recommended when architecture/test-shape review is still needed) — Input: .omw/deep-interview/spec-{slug}.md. Invoke the plan skill (skill: plan). Do not repeat the interview; refine architecture/feasibility around the clarified intent.
2. team (Coordinated parallel implementation) — Invoke the team skill (skill: team) or spawn parallel agents via the Agent tool, using the spec as shared execution context. Best for large, multi-lane, blocker-sensitive tasks.
3. Direct execution (single owner) — Spawn one Agent to implement against the spec's acceptance criteria, or continue in-session. Use the task list to track completion checkpoints.
4. Refine further — Re-enter the interview loop to resolve the highest-leverage remaining uncertainty.

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.

IMPORTANT: Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. Do NOT implement directly inside deep-interview.

If interrupted, rerun the deep-interview skill with the same arguments. Resume from the context snapshot under .omw/deep-interview/context-{slug}-*.md and continue the round log recorded in .workbuddy/memory/YYYY-MM-DD.md.

Recommended Pipeline

deep-interview -> plan -> execution (Agent tool / team)

• Stage 1 (deep-interview): clarity gate.
• Stage 2 (plan): feasibility + architecture gate.
• Stage 3 (execution): implementation + verification.