Codebase Explanation
Explain mechanics from the code that exists now.
Workflow
- Clarify the behavior or path the user wants explained and bound the relevant component.
- Locate entrypoints, public interfaces, owners of state, configuration, and the main callers and consumers.
- Trace control flow and data flow separately. Name validation, transformations, persistence, concurrency, retries, and error paths where present.
- Cite concrete files and symbols. Distinguish runtime code from tests, fixtures, generated output, documentation, and proposed designs.
- Verify important claims through tests, call sites, configuration, or safe execution when appropriate and authorized.
- Explain the smallest coherent model first, then add edge cases and uncertainty.
Boundaries
- Current code can establish mechanics, not historical intent. Label rationale as inference unless direct evidence supports it.
- Do not change code merely because the explanation reveals a defect or awkward design.
- Do not imply that an unexecuted path, configuration, or deployment is active.
Output
Lead with a plain-language summary, then provide Entrypoints, Flow, State and ownership, Interfaces, Failure paths, Evidence, and Unknowns.
1---2name: codebase-explanation3description: Explain how an existing codebase works using current repository evidence: entrypoints, ownership, control and data flow, state, interfaces, failures, and concrete files. Use when the user asks how code behaves; use design-rationale-investigation instead for historical intent or why a design was chosen.4license: MIT5---67# Codebase Explanation89Explain mechanics from the code that exists now.1011## Workflow12131. Clarify the behavior or path the user wants explained and bound the relevant component.142. Locate entrypoints, public interfaces, owners of state, configuration, and the main callers and consumers.153. Trace control flow and data flow separately. Name validation, transformations, persistence, concurrency, retries, and error paths where present.164. Cite concrete files and symbols. Distinguish runtime code from tests, fixtures, generated output, documentation, and proposed designs.175. Verify important claims through tests, call sites, configuration, or safe execution when appropriate and authorized.186. Explain the smallest coherent model first, then add edge cases and uncertainty.1920## Boundaries2122- Current code can establish mechanics, not historical intent. Label rationale as inference unless direct evidence supports it.23- Do not change code merely because the explanation reveals a defect or awkward design.24- Do not imply that an unexecuted path, configuration, or deployment is active.2526## Output2728Lead with a plain-language summary, then provide `Entrypoints`, `Flow`, `State and ownership`, `Interfaces`, `Failure paths`, `Evidence`, and `Unknowns`.
JovaniPink