Analyze Codebases with Deep Tracing

Deeply investigates codebases by tracing actual code paths and grounding every claim in evidence, under non-negotiable invariants: trace real code rather than guessing from names or conventions, read the actual implementation instead of summarizing a guess, follow a call chain all the way down (if A calls B calls C, trace all of it), and explicitly distinguish "I read this" from "I'm inferring because." It runs five iterations, each taking a different lens and building on prior findings: a structural/architectural view mapping components and entry points, a data-flow/state-management view, an integration/dependency view covering external connections and API contracts, a pattern/anti-pattern view surfacing design trade-offs and technical debt, and a synthesis/recommendations pass combining everything into actionable insight.

For every significant finding, it states the claim in one sentence, shows the evidence (file paths, code references, call chains), explains why it matters, rates confidence as HIGH (read the code), MEDIUM (read some, inferred the rest), or LOW (inferred from structure alone), and flags open questions for what to trace next. Its evidence standard maps each claim type to a specific proof requirement - "X calls Y" needs a file path and function name, "data flows through Z" needs a traced entry-point-to-destination path, "this is dead code" needs proof that no call sites exist.

Use it when a user asks "how does X work" expecting real depth, wants to understand a complex system spanning many files, or asks for architectural or pattern analysis.

Input: a codebase or subsystem needing deep investigation. Output: a five-lens research report with per-finding evidence, confidence ratings, and open questions, including Mermaid diagrams in dark-mode colors when they clarify architecture or flow, and an explicit list of what hasn't been explored yet.

Engineers and agents who need a code-traced, confidence-rated investigation of an unfamiliar or complex codebase rather than a plausible architectural summary. Its zero-tolerance rules extend to diagrams specifically: every box and arrow must correspond to real code that was actually read, not an assumed pattern like "this follows MVC" asserted without verifying where the model, view, and controller actually live.

Its rules also forbid repeating findings across iterations and require every claim to carry a file_path:line_number citation, so a later iteration can build on prior ones without re-deriving or contradicting them. It also requires substantive analysis at every step - never a placeholder like "continuing..." - and staying focused on the specific topic under investigation rather than drifting into adjacent systems.