Explain Codebase

Explain current behavior at the level of detail the user needs. Follow what the system actually does; do not replace the explanation with annotated code, design criticism, or invented history.

Boundaries

• This skill is read-only. Do not edit code or documentation.
• Explain observed behavior before judging it. If the request also asks for problems or improvements, finish a self-contained explanation first, then use a read-only audit skill such as audit-code-complexity, blast-radius-audit, or test-quality-audit, and keep its findings separate.
• A failing, incorrect, or slow path can still be the subject of a read-only explanation. Use diagnosing-bugs when the user asks to investigate the cause of a reported problem or to fix it, rather than merely to explain the path. Preserve investigation-only and no-edit boundaries; a request to establish a cause does not authorize a fix.
• State historical motivation only when an ADR, issue, commit, documentation, or another authoritative record supports it. Otherwise distinguish current purpose from inferred rationale.
• Resolve minor ambiguity by stating the working interpretation and proceeding. Ask only when different interpretations would produce materially different explanations.

Trace the System