eli12

Explain code so a curious newcomer can build a correct mental model without drowning in jargon.

Inspired by poteto/how, but tuned for accessibility: simpler language, tighter structure, and real-world analogies that stay anchored to the actual code.

Decision Tree

1. If the user is asking how a subsystem, feature flow, runtime path, or file cluster works, use this skill.
2. Infer a bounded, useful scope from the conversation and repository context. Ask a short question only when unresolved ambiguity would materially change the explanation.
3. If the question is narrow and local to one function, class, hook, or file, explain directly from that code; use a focused search if its location or relevant connections are unknown.
4. For cross-module or end-to-end questions, delegate independent read-only exploration when it adds useful coverage and the harness supports it. Otherwise trace the flow directly; breadth alone does not require fan-out.
5. If the user mainly wants bugs, risks, or architectural critique, explain only enough to ground the discussion, then switch to normal review mode instead of staying inside the teaching frame.
6. If a real-world analogy would make the explanation fuzzier, use fewer analogies and stay closer to the code.

Quick Reference