---
name: deep-interview
description: Socratic deep interview with ambiguity gating before Antigravity execution
argument-hint: "[--quick|--standard|--deep] [--autoresearch] <idea or vague description>"
---

<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 Omagy 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 "clarify first"
- The user wants to avoid misaligned implementation from underspecified requirements
- You need a requirements artifact before handing off to `/omagy:plan`, `/omagy:ralplan`, `/omagy:ultrawork`, `/omagy:ralph`, or `/omagy: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
- 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 scope should stop, which tradeoffs are unacceptable, and which
decisions still require user approval. This workflow applies Socratic pressure
and quantitative ambiguity scoring so Omagy execution 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`)**: Standard rigor specialized for `/omagy:autoresearch` validator-gated mission readiness, with `/omagy:autoresearch-goal` available for durable professor-critic goals

If no flag is provided, use **Standard**.

<Mode_Flags>
- **`--autoresearch`**: switch the interview into validator-gated autoresearch intake mode. Converge on a research mission, validation mode, completion artifact path, validator command or architect prompt, optional durable goal rubric, launch readiness, and explicit `refine further` vs `start autoresearch` vs `create/start autoresearch-goal` boundary. Do not migrate deprecated direct OMX `omx autoresearch` launch semantics into Omagy.
</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 is 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, evidence-focused, or tradeoff-focused follow-up.
- Gather codebase facts with `omagy explore` before asking the user about internals; use the `explorer` subagent only when the lookup is too broad for the bounded CLI.
- When unresolved ambiguity depends on current external best practices, official recommendations, standards, or version-aware upstream behavior, use `/omagy:best-practice-research` before treating that ambiguity as settled.
- Always run a preflight context intake before the first interview question.
- 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.
- Keep 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: 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.
- Use these transcript/spec labels only; never use them as `omagy question` `source` values, and never replace the runtime `source: "deep-interview"` contract for user-facing 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 `omagy 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 Antigravity CLI, use `omagy question` as the required Omagy-owned structured questioning path for every interview round.
- When invoking `omagy question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMAGY_QUESTION_RETURN_PANE=$TMUX_PANE` or a concrete `%pane` value.
- If you launch `omagy question` in a background terminal, immediately wait for that process to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off.
- Treat `answers[]` as the primary `omagy question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback.
- If the current runtime is outside tmux and cannot render `omagy question`, use Antigravity's native structured question surface 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.
- 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.
- Treat early exit as a safety valve, not the default success path.
- Persist mode state for resume safety with CLI-first state commands: `omagy state write/read --input '<json>' --json`.
</Execution_Policy>

<Steps>

## Phase 0: Preflight Context Intake

1. Parse `{{ARGUMENTS}}`, choose depth profile, and derive a short task slug.
2. Attempt to load the latest relevant context snapshot from `.omagy/context/{slug}-*.md`.
3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If oversized, 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/open questions
   - Decision-boundary unknowns
   - Likely codebase touchpoints
   - Prompt-safe initial-context summary status: `not_needed`, `needed`, or `recorded`
5. Save the snapshot through the artifact CLI:

```bash
omagy artifact write --input '{"path":".omagy/context/<slug>-<timestamp>.md","content":"<markdown context snapshot>"}' --json
```

Use UTC timestamps in `YYYYMMDDTHHMMSSZ` form.

## Phase 1: Initialize

1. Detect project context:
   - Classify **brownfield** when an existing repo/project target is in scope.
   - Classify **greenfield** when the idea is primarily new product or new workflow design.
   - For brownfield, collect relevant codebase context before questioning.
2. Read durable project facts when useful:

```bash
omagy memory read --json
omagy artifact list --json
```

3. Initialize state:

```bash
omagy state write --input '{"mode":"deep-interview","state":{"active":true,"current_phase":"deep-interview","interview_id":"<uuid>","profile":"standard","type":"greenfield|brownfield","initial_idea":"<user input>","rounds":[],"current_ambiguity":1.0,"threshold":0.2,"max_rounds":12,"challenge_modes_used":[],"current_stage":"intent-first","current_focus":"intent","context_snapshot_path":".omagy/context/<slug>-<timestamp>.md","prompt_safe_initial_context_summary_status":"not_needed"}}' --json
```

4. Announce kickoff with profile, threshold, current ambiguity, and the first focus dimension.

## Phase 2: Socratic Interview Loop

Repeat until ambiguity `<= threshold`, readiness gates pass, pressure pass is complete, user exits with warning, or max rounds are reached.

### 2a) Generate next question

If oversized initial context has no prompt-safe summary yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off until that summary answer is captured.

Use:
- Original idea
- Prior Q&A rounds
- Current dimension scores
- Brownfield context
- Activated challenge mode injection

Target the lowest-scoring dimension while 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.
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. If the answer still describes symptoms, reframe toward essence/root cause before moving on.

Maintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.

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 surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use Omagy-owned structured questioning through `omagy question`. Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer.

Present:

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

{question}
```

`omagy question` payload guidance:
- Deep Interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds.
- Use canonical `type` values. `type: "single-answerable"` is the default for one-path decisions; `type: "multi-answerable"` is the canonical bounded multi-select shape.
- Use `single-answerable` when exactly one answer should drive the next branch, options are mutually exclusive, or selecting more than one answer would blur the decision boundary.
- Use `multi-answerable` when multiple options may all be true at once and you need a bounded set of coexisting constraints, non-goals, risks, or acceptance checks.
- Keep options bounded and concrete. Set `allow_other:false` when the valid answers are known; leave `allow_other:true` only when the interview genuinely needs one user-supplied option.
- Read answers structurally from `answers[]`. For a normal single-round response, use `answers[0].answer` as the source of truth.

Canonical bounded single-choice payload:

```json
{
  "question": "Which execution lane should own this once the interview is complete?",
  "type": "single-answerable",
  "options": [
    {
      "label": "Plan first",
      "value": "plan",
      "description": "Need architecture and test-shape review before execution"
    },
    {
      "label": "Execute directly",
      "value": "ultrawork",
      "description": "Requirements are explicit enough for direct execution"
    },
    {
      "label": "Refine further",
      "value": "refine",
      "description": "Clarification is still needed before handoff"
    }
  ],
  "allow_other": false,
  "other_label": "Other",
  "source": "deep-interview"
}
```

Canonical bounded multi-select payload:

```json
{
  "question": "Which non-goals must stay out of scope for the first pass?",
  "type": "multi-answerable",
  "options": [
    {
      "label": "No UI redesign",
      "value": "no-ui-redesign",
      "description": "Keep layout and styling unchanged"
    },
    {
      "label": "No new dependencies",
      "value": "no-new-dependencies",
      "description": "Work within the existing toolchain"
    },
    {
      "label": "No API contract changes",
      "value": "no-api-contract-changes",
      "description": "Preserve external request and response shapes"
    }
  ],
  "allow_other": false,
  "other_label": "Other",
  "source": "deep-interview"
}
```

Canonical answer-shape reminders:

```json
{
  "answer": {
    "kind": "option",
    "value": "plan",
    "selected_labels": ["Plan first"],
    "selected_values": ["plan"]
  }
}
```

```json
{
  "answer": {
    "kind": "multi",
    "value": ["no-new-dependencies", "no-api-contract-changes"],
    "selected_labels": ["No new dependencies", "No API contract changes"],
    "selected_values": ["no-new-dependencies", "no-api-contract-changes"]
  }
}
```

### 2c) Score ambiguity

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

Greenfield:

```text
ambiguity = 1 - (intent * 0.30 + outcome * 0.25 + scope * 0.20 + constraints * 0.15 + success * 0.10)
```

Brownfield:

```text
ambiguity = 1 - (intent * 0.25 + outcome * 0.20 + scope * 0.20 + constraints * 0.15 + success * 0.10 + context * 0.10)
```

Readiness gates:
- `Non-goals` must be explicit.
- `Decision Boundaries` must be explicit.
- A pressure pass must be complete: at least one earlier answer has been revisited with evidence, assumption, or tradeoff pressure.
- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case.
- If any gate is unresolved, continue interviewing even when weighted ambiguity is below threshold.
- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec or ask a final closure question.

### 2d) Report progress

After each answer, show:
- weighted breakdown
- current ambiguity
- weakest dimension
- readiness-gate status (`Non-goals`, `Decision Boundaries`, `Pressure Pass`, `Closure Audit`)
- next focus dimension

### 2e) Persist state

Append the round result and updated scores:

```bash
omagy state write --input '{"mode":"deep-interview","state":{"active":true,"current_phase":"deep-interview","rounds":["<append round summary>"],"current_ambiguity":0.42,"current_focus":"scope","challenge_modes_used":[]}}' --json
```

### 2f) Round controls

- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened.
- Apply a **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]`) unless the closure audit says the interview is ready to crystallize.
- Round 4+: allow explicit early exit with risk warning.
- Warn at profile midpoint.
- Stop at profile `max_rounds` and preserve residual risk.

## Phase 3: Challenge Modes

Use each mode once when applicable:
- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions.
- **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 state to prevent repetition.

## Phase 4: Crystallize Artifacts

When threshold is met, the user exits with warning, or the hard cap is reached:

1. Write transcript summary to `.omagy/interviews/{slug}-{timestamp}.md`.
2. Write execution-ready spec to `.omagy/specs/deep-interview-{slug}.md`.

Use artifact CLI only:

```bash
omagy artifact write --input '{"path":".omagy/interviews/<slug>-<timestamp>.md","content":"<markdown transcript summary>"}' --json
omagy artifact write --input '{"path":".omagy/specs/deep-interview-<slug>.md","content":"<execution-ready markdown spec>"}' --json
```

Spec must include:
- Metadata: profile, rounds, final ambiguity, threshold, context type
- Context snapshot reference/path
- Prompt-safe initial-context summary when required, plus references to full source documents
- Clarity breakdown table
- Intent
- Desired outcome
- In-scope
- Out-of-scope / non-goals
- Decision boundaries: what Omagy may decide without confirmation
- Constraints
- Testable acceptance criteria
- Assumptions exposed and resolutions
- Pressure-pass findings
- Brownfield evidence vs inference notes
- Technical context findings
- Full or condensed transcript
- Residual-risk warning when the interview ended above threshold, by early exit, or by hard cap

### Autoresearch-goal specialization

When the clarified task is specifically a research mission, evaluator-backed
analysis, professor/critic deliverable, or the skill is invoked with
`--autoresearch`, keep the interview domain-specific without reviving deprecated
OMX `$autoresearch` runtime behavior.

- **Accepted seed inputs:** `topic`, professor-critic rubric, optional
  `critic-command`, `slug`, prior research draft, source constraints, and
  expected deliverable shape.
- **Required interview focus:** research topic clarity, source/evidence
  standards, professor-critic pass/fail rubric, blocked-source policy, slug or
  naming preference, and whether the draft is ready to create/start now or
  should refine further.
- **Canonical artifact path:** `.omagy/specs/deep-interview-autoresearch-{slug}.md`
- **Required artifact sections:**
  - `Research Topic`
  - `Professor-Critic Rubric`
  - `Evidence Standards`
  - `Launch Readiness`
  - `Seed Inputs`
  - `Confirmation Bridge`
- **Launch-readiness rule:** mark the draft as **not launch-ready** while the
  rubric or critic command contains placeholder markers such as `<...>`, `TODO`,
  `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`.
- **Structured handoff contract:** preserve finalized `task`,
  `validation_mode`, `completion_artifact_path`, `mission_validator_command` or
  `validator_prompt`, optional `output_artifact_path`, `topic`, `rubric`,
  `criticCommand`, `slug`, `launchReady`, and `blockedReasons` so
  `/omagy:autoresearch` can start the validator-gated loop and
  `/omagy:autoresearch-goal` can create a durable professor-critic goal when
  requested:

```bash
omagy autoresearch start --input '{"task":"<mission>","validation_mode":"mission-validator-script","completion_artifact_path":".omagy/specs/autoresearch-<slug>/result.json","mission_validator_command":"<validator command>"}' --json
omagy autoresearch-goal create --topic "<topic>" --rubric "<professor-critic rubric>" --slug <slug>
omagy autoresearch-goal start --slug <slug>
```

- **Confirmation bridge:** after artifact generation, offer at least `refine
  further`, `start autoresearch`, and `create/start autoresearch-goal`; do not
  run a detached sandbox launch or old direct `omx autoresearch` flow.
- **Handoff rule:** downstream execution must preserve the clarified mission
  intent, evidence standards, decision boundaries, and launch-readiness status.

## Phase 5: Execution Bridge

Present execution options after artifact generation. Treat the deep-interview
spec as the requirements source of truth and preserve intent, non-goals,
decision boundaries, acceptance criteria, and residual-risk warnings.

### 1. `/omagy:plan` or `/omagy:ralplan` (Recommended)
- **Input Artifact:** `.omagy/specs/deep-interview-{slug}.md`
- **Consumer Behavior:** Treat the spec as requirements source of truth. Do not repeat the interview by default; refine architecture, feasibility, PRD, and test-shape around the clarified intent.
- **Best When:** Requirements are clear enough to stop interviewing, but planning or consensus validation is still desirable.

### 2. `/omagy:ultrawork`
- **Input Artifact:** `.omagy/specs/deep-interview-{slug}.md`
- **Consumer Behavior:** Use the spec as clarified execution brief. Preserve acceptance criteria and non-goals.
- **Best When:** The spec is strong enough for direct execution and the task does not need consensus planning.

### 3. `/omagy:ralph`
- **Input Artifact:** `.omagy/specs/deep-interview-{slug}.md`
- **Consumer Behavior:** Use the spec's acceptance criteria and boundary constraints as the persistence target.
- **Best When:** The user explicitly wants bounded continuation and repeated verification pressure.

### 4. `/omagy:team`
- **Input Artifact:** `.omagy/specs/deep-interview-{slug}.md`
- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work.
- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify durable coordination.

### 5. `/omagy:ultragoal`
- **Input Artifact:** `.omagy/specs/deep-interview-{slug}.md`
- **Consumer Behavior:** Convert the clarified spec into durable Omagy goals under `.omagy/ultragoal/`; preserve acceptance criteria, non-goals, and residual-risk warnings.
- **Best When:** The clarified work is goal-oriented implementation or multi-step completion tracking.

### 6. `/omagy:autoresearch`
- **Input Artifact:** `.omagy/specs/deep-interview-autoresearch-{slug}.md`
- **Consumer Behavior:** Start a validator-gated research loop with `omagy autoresearch start`, keep running until the configured completion artifact passes, then finish with `omagy autoresearch complete`.
- **Best When:** The clarified work is a research loop that needs explicit script validation or prompt+architect artifact approval.

### 7. `/omagy:autoresearch-goal`
- **Input Artifact:** `.omagy/specs/deep-interview-{slug}.md` or `.omagy/specs/deep-interview-autoresearch-{slug}.md`
- **Consumer Behavior:** Create an artifact-backed research goal with a professor-critic completion gate. Use `omagy autoresearch-goal create/start`, then record pass/fail/blocker evidence with `verdict`.
- **Best When:** The clarified work is a research question, reference/literature gathering, evaluator-backed analysis, or professor-critic deliverable.

### 8. `/omagy:performance-goal`
- **Input Artifact:** `.omagy/specs/deep-interview-{slug}.md`
- **Consumer Behavior:** Create an evaluator-gated performance goal with explicit evaluator command and pass/fail contract. If those are missing, continue interviewing before handoff.
- **Best When:** The clarified work is speed, latency, throughput, memory, allocation, benchmark, or measurable optimization work.

### 8. Refine further
- Re-enter questioning to resolve the highest-leverage remaining uncertainty.

**Residual-Risk Rule:** If the interview ended via early exit, hard cap, 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.

</Steps>

<Tool_Usage>
- Use `omagy explore --prompt "<narrow lookup>" --json` for bounded read-only codebase fact gathering before user questions.
- Use the `explorer` subagent only when `omagy explore` returns `unsupported_prompt` or the investigation requires richer synthesis.
- Use `omagy memory read --json` when persistent project facts may answer a repo-context question.
- Use `omagy question` for every user-facing interview round when an attached tmux renderer is available.
- From attached-tmux Bash/tool paths, call it as `OMAGY_QUESTION_RETURN_PANE=$TMUX_PANE omagy question ...` unless an explicit `%pane` return target is known.
- If the current runtime is outside tmux and cannot render `omagy question`, use Antigravity native structured input when available; otherwise ask exactly one concise plain-text question and wait.
- After `omagy question` returns JSON, prefer `answers[0].answer` and `answers[]`; use legacy `answer` only as a fallback.
- Use `omagy state write/read --input '<json>' --json` for resumable mode state.
- If the interview cannot ask a required `omagy question` round, persist terminal blocked state with `active:false` and `current_phase:"blocked"`.
- Read/write context snapshots under `.omagy/context/`.
- Record whether oversized initial-context summary is not needed, pending, or satisfied before any scoring or handoff.
- Save transcript/spec artifacts under `.omagy/interviews/` and `.omagy/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: crystallize with explicit residual-risk warning.
- All dimensions >= 0.9 and readiness gates pass: allow early crystallization.
</Escalation_And_Stop_Conditions>

<Final_Checklist>
- [ ] Preflight context snapshot exists under `.omagy/context/{slug}-{timestamp}.md`.
- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff.
- [ ] 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 `.omagy/interviews/{slug}-{timestamp}.md`.
- [ ] Spec written to `.omagy/specs/deep-interview-{slug}.md`.
- [ ] Brownfield questions use evidence-backed confirmation when applicable.
- [ ] Handoff options provided: `/omagy:plan` or `/omagy:ralplan`, `/omagy:ultrawork`, `/omagy:ralph`, `/omagy:team`, plus context-sensitive `/omagy:ultragoal`, `/omagy:autoresearch`, `/omagy:autoresearch-goal`, `/omagy:performance-goal`, and refine further.
- [ ] No direct implementation performed in this mode.
</Final_Checklist>

<Advanced>
## Suggested Config

```toml
[omagy.deepInterview]
defaultProfile = "standard"
quickThreshold = 0.30
standardThreshold = 0.20
deepThreshold = 0.15
quickMaxRounds = 5
standardMaxRounds = 12
deepMaxRounds = 20
enableChallengeModes = true
```

## Resume

If interrupted, rerun `/omagy:deep-interview`. Resume from persisted mode state:

```bash
omagy state read --input '{"mode":"deep-interview"}' --json
```

## Recommended Pipeline

```text
deep-interview -> plan/ralplan -> ultrawork/ralph/team -> code-review
```

- Stage 1: `deep-interview` clarity gate
- Stage 2: `plan` / `ralplan` feasibility and architecture gate
- Stage 3: `ultrawork` / `ralph` / `team` execution and verification
- Stage 4: `code-review` read-only quality and architecture review
</Advanced>