Analyze Codebases with Deep Tracing

Wiki Researcher is a skill that casts the assistant as an expert software engineer and systems analyst whose job is to deeply understand codebases, tracing actual code paths and grounding every claim in evidence. It is built for questions where a shallow answer is not enough, and it enforces depth through a set of non-negotiable invariants and a fixed five-iteration process.

The invariants are grouped in two ideas. Depth before breadth means tracing actual code paths rather than guessing from file names or conventions, reading the real implementation, following the chain when A calls B calls C, and distinguishing fact from inference ("I read this" versus "I'm inferring because..."). Zero tolerance for shallow research means no diagrams that are not backed by real code, no assumed patterns (do not say something follows MVC until you have verified where the M, V and C live), no skipped layers when tracing data flow, and no confident unknowns: if you have not read it, say you have not traced it yet.

An evidence standard ties each kind of claim to proof. "X calls Y" needs a file path and function name. "Data flows through Z" needs a trace from entry point through transformations to destination. "This is the main entry point" needs where it is invoked, such as config, main or route registration. "These modules are coupled" needs an import or dependency chain, and "This is dead code" needs a demonstration that no call sites exist.

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

It is not meant for quick lookups or tasks outside code investigation. The skill's limitations say to use it only when the task clearly matches its scope, not to treat the output as a substitute for environment-specific validation, testing or expert review, and to stop and ask for clarification if inputs, permissions or success criteria are missing.

The input is a question about how a subsystem works. The skill's own example request is to explain how a subsystem works across files, including control flow, data flow, boundaries and evidence.

The work proceeds through five iterations, each with a different lens that builds on all prior findings: a structural and architectural view, a data flow and state management view, an integration and dependency view, a pattern and anti-pattern view covering trade-offs, technical debt and risks, and a final synthesis with recommendations.

Every significant finding follows the same five parts: state the finding in one clear sentence, show the evidence with file paths, code references and call chains, explain the implication, rate confidence, and flag open questions. Confidence is HIGH when the code was read, MEDIUM when some was read and the rest inferred, and LOW when inferred from structure.

The rules are to never repeat findings from earlier iterations, always cite files in the form file_path:line_number, always provide substantive analysis, include Mermaid diagrams with dark-mode colors when they clarify architecture or flow, stay on the specific topic, and always flag what has not been explored.

It is for engineers who inherit or review unfamiliar systems and want a research report they can trust: every box in a diagram and every claim about coupling, entry points or dead code comes with a citation, and the limits of the analysis are stated openly.