In depth analysis

--- name: deep-dive description: "2-stage pipeline: trace (causal investigation) -> deep-interview (requirements crystallization) with 3-point injection" argument-hint: "<problem or exploration target>" triggers: - "deep dive" - "deep-dive" - "trace and interview" - "investigate deeply" pipeline: [deep-dive, plan, autopilot] next-skill: plan next-skill-args: --consensus --direct handoff: .omc/specs/deep-dive-{slug}.md --- <Purpose> Deep Dive orchestrates a 2-stage pipeline that first investigates WHY something happened (trace) then precisely defines WHAT to do about it (deep-interview). The trace stage runs 3 parallel causal investigation lanes, and its findings feed into the interview stage via a 3-point injection mechanism : enriching the starting point, providing system context, and seeding initial questions. The result is a crystal-clear spec grounded in evidence, not assumptions. </Purpose> <UseWhen> - 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 </UseWhen> <DoNotUse_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 </DoNotUseWhen> <WhyThis_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. </WhyThisExists> <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> <Steps> ## 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 : covers verification-method defects, not just system defects. Examples: the verification query reuses a single dimensional key across distinct entities, tenants, streams, or groups; the comparison filter shape does not match the schema grain; or the catalog or column name was assumed portable across runtimes without enumeration. This includes multi-entity premise/key-assumption mismatches. - Premise audit for cross-entity discrepancies: if the problem says "X is empty but Y is not", "N streams differ", or "values mismatch across entities", lane 3 should test the verification premise first. Enumerate entity dimensions (cohort IDs, tenant IDs, partition keys, dimensional keys per stream) via metadata table or sche