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. If the request is very vague and the likely search space is large, ask 1-3 short narrowing questions before exploring. Default to scope-first questions such as "Which feature or path do you care about?", "Do you want runtime flow, architecture, or file tour?", and "Should I stay focused on frontend, backend, or data?".
3. If the question is narrow and local to one function, class, hook, or file, do a direct explain pass after a focused code search.
4. If the question spans multiple modules, services, or an end-to-end flow, split it into 2-4 exploration angles, gather findings in parallel when the harness allows it, then synthesize.
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