deep-interview

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

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.

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

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:

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:

omagy memory read --json
omagy artifact list --json

3. Initialize state:

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:

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:

{
  "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:

{
  "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:

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

{
  "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:

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

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:

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:

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.

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

## Suggested Config

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

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

Recommended Pipeline

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