explain-codelisted

# Explain code Build an accurate mental model of the code at the depth the question requires. Explain current mechanics from evidence in the repository, not from names, conventions, or plausible assumptions. ## Boundaries This skill owns neutral explanation: - what code does; - how control and data flow through it; - which types and components participate; - where responsibilities currently live; - which behavior is non-obvious. Route other intents explicitly: - Use `clarify` when observed behavior differs from expectations, the user asks whether behavior is wrong, or the question concerns historical design rationale. - Use `code-review` when the user asks for defects, risks, architectural criticism, security findings, or improvement recommendations. - Use `refactor-code` when the user wants code changed while preserving behavior. - Use `brainstorm` when the user wants new architecture, alternative ownership, or future design options. - Use `teach`, when explicitly invoked and available, for a progressive learning conversation. Use this skill to supply its current-code mechanics and evidence. - Use `technical-writing`, when available, when the deliverable is a substantial standalone document such as an architecture guide. Use this skill to establish the document's current-code mechanics and evidence. Do not turn an explanation into an unsolicited review or redesign. Mention a likely defect only when it is necessary to explain the observed flow, and label it as unverifi