deep-dive

<Use_When>

• User has a problem but doesn't know the root cause — needs investigation before requirements
• User says "deep dive", "deep-dive", "investigate deeply", "trace and interview"
• User wants to understand existing system behavior before defining changes
• Bug investigation: "Something broke and I need to figure out why, then plan the fix"
• Feature exploration: "I want to improve X but first need to understand how it currently works"
• The problem is ambiguous, causal, and evidence-heavy — jumping to code would waste cycles </Use_When>

<Do_Not_Use_When>

• User already knows the root cause and just needs requirements gathering — use /deep-interview directly
• User has a clear, specific request with file paths and function names — execute directly
• User wants to trace/investigate but NOT define requirements afterward — use /trace directly
• User already has a PRD or spec — use /ralph or /autopilot with that plan
• User says "just do it" or "skip the investigation" — respect their intent </Do_Not_Use_When>

<Why_This_Exists> Users who run /trace and /deep-interview separately lose context between steps. Trace discovers root causes, maps system areas, and identifies critical unknowns — but when the user manually starts /deep-interview afterward, none of that context carries over. The interview starts from scratch, re-exploring the codebase and asking questions the trace already answered.

Deep Dive connects these steps with a 3-point injection mechanism that transfers trace findings directly into the interview's initialization. This means the interview starts with an enriched understanding, skips redundant exploration, and focuses its first questions on what the trace couldn't resolve autonomously.

The name "deep dive" naturally implies this flow: first dig deep into the problem's causal structure, then use those findings to precisely define what to do about it. </Why_This_Exists>

<Execution_Policy>

• Phase 1-2: Initialize and confirm trace lane hypotheses (1 user interaction)
• Phase 3: Trace runs autonomously after lane confirmation — no mid-trace interruption
• Phase 4: Interview is interactive — one question at a time, following deep-interview protocol
• State persists across phases via state_write(mode="deep-interview") with source: "deep-dive" discriminator
• Artifact paths are persisted in state for resume resilience after context compaction
• Do not proceed to execution — always hand off via Execution Bridge (Phase 5) </Execution_Policy>

Phase 1: Initialize

1. Parse the user's idea from {{ARGUMENTS}}
2. Generate slug: kebab-case from first 5 words of ARGUMENTS, lowercased, special characters stripped. Example: "Why does the auth token expire early?" becomes why-does-the-auth-token
3. 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
4. Generate 3 trace lane hypotheses:
   • Default lanes (unless the problem strongly suggests a better partition):
     1. Code-path / implementation cause
     2. Config / environment / orchestration cause
     3. Measurement / artifact / assumption mismatch cause
   • For brownfield: run explore agent to identify relevant codebase areas, store as codebase_context for later injection
5. Initialize state via state_write(mode="deep-interview"):