• User has a vague idea and wants thorough requirements gathering before execution
• User says "deep interview", "interview me", "ask me everything", "don't assume", "make sure you understand"
• User says "ouroboros", "socratic", "I have a vague idea", "not sure exactly what I want"
• User wants to avoid "that's not what I meant" outcomes from autonomous execution
• Task is complex enough that jumping to code would waste cycles on scope discovery
• User wants mathematically-validated clarity before committing to execution </Use_When>

• User has a detailed, specific request with file paths, function names, or acceptance criteria -- execute directly
• User wants to explore options or brainstorm -- use

  omc-plan

  skill instead
• User wants a quick fix or single change -- delegate to executor or ralph
• User says "just do it" or "skip the questions" -- respect their intent
• User already has a PRD or plan file -- use ralph or autopilot with that plan </Do_Not_Use_When>

• Ask ONE question at a time -- never batch multiple questions
• Target the WEAKEST clarity dimension with each question
• Gather codebase facts via

  explore

  agent BEFORE asking the user about them
• Score ambiguity after every answer -- display the score transparently
• Do not proceed to execution until ambiguity ≤ threshold (default 0.2)
• Allow early exit with a clear warning if ambiguity is still high
• Persist interview state for resume across session interruptions
• Challenge agents activate at specific round thresholds to shift perspective </Execution_Policy>

1. Parse the user's idea from

   {{ARGUMENTS}}

2. Detect brownfield vs greenfield:
   • Run

     explore

     agent (haiku): check if cwd has existing source code, package files, or git history
   • If source files exist AND the user's idea references modifying/extending something: brownfield
   • Otherwise: greenfield
3. For brownfield: Run

   explore

   agent to map relevant codebase areas, store as

   codebase_context

4. Initialize state via

   state_write(mode="deep-interview")

   :

{
  "active": true,
  "current_phase": "deep-interview",
  "state": {
    "interview_id": "<uuid>",
    "type": "greenfield|brownfield",
    "initial_idea": "<user input>",
    "rounds": [],
    "current_ambiguity": 1.0,
    "threshold": 0.2,
    "codebase_context": null,
    "challenge_modes_used": []
  }
}

1. Announce the interview to the user:

Starting deep interview. I'll ask targeted questions to understand your idea thoroughly before building anything. After each answer, I'll show your clarity score. We'll proceed to execution once ambiguity drops below 20%.

Your idea: "{initial_idea}" Project type: {greenfield|brownfield} Current ambiguity: 100% (we haven't started yet)

• The user's original idea
• All prior Q&A rounds (conversation history)
• Current clarity scores per dimension (which is weakest?)
• Challenge agent mode (if activated -- see Phase 3)
• Brownfield codebase context (if applicable)

• Identify the dimension with the LOWEST clarity score
• Generate a question that specifically improves that dimension
• Questions should expose ASSUMPTIONS, not gather feature lists

• Round 3+: Allow early exit if user says "enough", "let's go", "build it"
• Round 10: Show soft warning: "We're at 10 rounds. Current ambiguity: {score}%. Continue or proceed with current clarity?"
• Round 20: Hard cap: "Maximum interview rounds reached. Proceeding with current clarity level ({score}%)."

You are now in CONTRARIAN mode. Your next question should challenge the user's core assumption. Ask "What if the opposite were true?" or "What if this constraint doesn't actually exist?" The goal is to test whether the user's framing is correct or just habitual.

You are now in SIMPLIFIER mode. Your next question should probe whether complexity can be removed. Ask "What's the simplest version that would still be valuable?" or "Which of these constraints are actually necessary vs. assumed?" The goal is to find the minimal viable specification.

You are now in ONTOLOGIST mode. The ambiguity is still high after 8 rounds, suggesting we may be addressing symptoms rather than the core problem. Ask "What IS this, really?" or "If you could only describe this in one sentence to a colleague, what would you say?" The goal is to find the essence.

1. Generate the specification using opus model with the full interview transcript
2. Write to file:

   .omc/specs/deep-interview-{slug}.md

undefined

• Interview ID: {uuid}
• Rounds: {count}
• Final Ambiguity Score: {score}%
• Type: greenfield | brownfield
• Generated: {timestamp}
• Threshold: {threshold}
• Status: {PASSED | BELOW_THRESHOLD_EARLY_EXIT}

• {constraint 1}
• {constraint 2}
• ...

• {explicitly excluded scope 1}
• {explicitly excluded scope 2}

• {testable criterion 1}
• {testable criterion 2}
• {testable criterion 3}
• ...

AskUserQuestion

1. Ralplan → Autopilot (Recommended)
   • Description: "3-stage pipeline: consensus-refine this spec with Planner/Architect/Critic, then execute with full autopilot. Maximum quality."
   • Action: Invoke

     Skill("oh-my-claudecode:omc-plan")

     with

     --consensus --direct

     flags and the spec file path as context. The

     --direct

     flag skips the omc-plan skill's interview phase (the deep interview already gathered requirements), while

     --consensus

     triggers the Planner/Architect/Critic loop. When consensus completes and produces a plan in

     .omc/plans/

     , invoke

     Skill("oh-my-claudecode:autopilot")

     with the consensus plan as Phase 0+1 output — autopilot skips both Expansion and Planning, starting directly at Phase 2 (Execution).
   • Pipeline:

     deep-interview spec → omc-plan --consensus --direct → autopilot execution

2. Execute with autopilot (skip ralplan)
   • Description: "Full autonomous pipeline — planning, parallel implementation, QA, validation. Faster but without consensus refinement."
   • Action: Invoke

     Skill("oh-my-claudecode:autopilot")

     with the spec file path as context. The spec replaces autopilot's Phase 0 — autopilot starts at Phase 1 (Planning).
3. Execute with ralph
   • Description: "Persistence loop with architect verification — keeps working until all acceptance criteria pass"
   • Action: Invoke

     Skill("oh-my-claudecode:ralph")

     with the spec file path as the task definition.
4. Execute with team
   • Description: "N coordinated parallel agents — fastest execution for large specs"
   • Action: Invoke

     Skill("oh-my-claudecode:team")

     with the spec file path as the shared plan.
5. Refine further
   • Description: "Continue interviewing to improve clarity (current: {score}%)"
   • Action: Return to Phase 2 interview loop.

Skill()

Stage 1: Deep Interview          Stage 2: Ralplan                Stage 3: Autopilot
┌─────────────────────┐    ┌───────────────────────────┐    ┌──────────────────────┐
│ Socratic Q&A        │    │ Planner creates plan      │    │ Phase 2: Execution   │
│ Ambiguity scoring   │───>│ Architect reviews         │───>│ Phase 3: QA cycling  │
│ Challenge agents    │    │ Critic validates          │    │ Phase 4: Validation  │
│ Spec crystallization│    │ Loop until consensus      │    │ Phase 5: Cleanup     │
│ Gate: ≤20% ambiguity│    │ ADR + RALPLAN-DR summary  │    │                      │
└─────────────────────┘    └───────────────────────────┘    └──────────────────────┘
Output: spec.md            Output: consensus-plan.md        Output: working code

1. Deep Interview gates on clarity — does the user know what they want?
2. Ralplan gates on feasibility — is the approach architecturally sound?
3. Autopilot gates on correctness — does the code work and pass review?

• Skip Stage 1 → autopilot may build the wrong thing (vague requirements)
• Skip Stage 2 → autopilot may plan poorly (no Architect/Critic challenge)
• Skip Stage 3 → no execution (just a refined plan)

• Use

  AskUserQuestion

  for each interview question — provides clickable UI with contextual options
• Use

  Task(subagent_type="oh-my-claudecode:explore", model="haiku")

  for brownfield codebase exploration (run BEFORE asking user about codebase)
• Use opus model (temperature 0.1) for ambiguity scoring — consistency is critical
• Use

  state_write

  /

  state_read

  for interview state persistence
• Use

  Write

  tool to save the final spec to

  .omc/specs/

• Use

  Skill()

  to bridge to execution modes — never implement directly
• Challenge agent modes are prompt injections, not separate agent spawns </Tool_Usage>

Why good: Explored first, then asked an informed question. Never asks the user what the code already reveals.
</Good>

<Good>
Contrarian mode activation:

Why good: Challenges a specific assumption (scale requirement) that could dramatically simplify the solution.
</Good>

<Good>
Early exit with warning:

• Success Criteria: 0.5 (How do we verify the search ranking algorithm works correctly?)
• Constraints: 0.6 (No performance targets defined yet)

Why good: Respects user's desire to stop but transparently shows the risk.
</Good>

<Bad>
Batching multiple questions:

Why bad: Four questions at once — causes shallow answers and makes scoring inaccurate.
</Bad>

<Bad>
Asking about codebase facts:

Why bad: Should have spawned explore agent to find this. Never ask the user what the code already tells you.
</Bad>

<Bad>
Proceeding despite high ambiguity:

Why bad: 45% ambiguity means nearly half the requirements are unclear. The mathematical gate exists to prevent exactly this.
</Bad>
</Examples>

<Escalation_And_Stop_Conditions>
- **Hard cap at 20 rounds**: Proceed with whatever clarity exists, noting the risk
- **Soft warning at 10 rounds**: Offer to continue or proceed
- **Early exit (round 3+)**: Allow with warning if ambiguity > threshold
- **User says "stop", "cancel", "abort"**: Stop immediately, save state for resume
- **Ambiguity stalls** (same score +-0.05 for 3 rounds): Activate Ontologist mode to reframe
- **All dimensions at 0.9+**: Skip to spec generation even if not at round minimum
- **Codebase exploration fails**: Proceed as greenfield, note the limitation
</Escalation_And_Stop_Conditions>

<Final_Checklist>
- [ ] Interview completed (ambiguity ≤ threshold OR user chose early exit)
- [ ] Ambiguity score displayed after every round
- [ ] Challenge agents activated at correct thresholds (round 4, 6, 8)
- [ ] Spec file written to `.omc/specs/deep-interview-{slug}.md`
- [ ] Spec includes: goal, constraints, acceptance criteria, clarity breakdown, transcript
- [ ] Execution bridge presented via AskUserQuestion
- [ ] Selected execution mode invoked via Skill() (never direct implementation)
- [ ] If 3-stage pipeline selected: omc-plan --consensus --direct invoked, then autopilot with consensus plan
- [ ] State cleaned up after execution handoff
</Final_Checklist>

<Advanced>

/deep-interview "vague idea"
  → Socratic Q&A until ambiguity ≤ 20%
  → Spec written to .omc/specs/deep-interview-{slug}.md
  → User selects "Ralplan → Autopilot"
  → /omc-plan --consensus --direct (spec as input, skip interview)
    → Planner creates implementation plan from spec
    → Architect reviews for architectural soundness
    → Critic validates quality and testability
    → Loop until consensus (max 5 iterations)
    → Consensus plan written to .omc/plans/
  → /autopilot (plan as input, skip Phase 0+1)
    → Phase 2: Parallel execution via Ralph + Ultrawork
    → Phase 3: QA cycling until tests pass
    → Phase 4: Multi-perspective validation
    → Phase 5: Cleanup

--consensus --direct

--direct

• RALPLAN-DR summary (Principles, Decision Drivers, Options)
• ADR (Decision, Drivers, Alternatives, Why chosen, Consequences)
• Testable acceptance criteria (inherited from deep-interview spec)
• Implementation steps with file references