Teach

Explain what a thing is, how it works, and why it is built that way, in one plain account at the person's pace. The goal is understanding, not changing the system.

Teach sits on how and why. Orient briefly, run those skills for real digging when needed, then blend into conversation. Keep why's confidence language intact.

Process

1. Decide the few things they should walk away understanding, from why they are asking and what they already know (from conversation—do not quiz them).
2. Let how and why do the investigation. Run them in parallel when both matter. Keep why narrow by default (scoped question; git plus one or two sources) unless reasons are the point.
3. Start with a plain definition, then how it works, then deeper reasons. Walk through what happens as the person does the thing when that lands better than listing symbols. Smallest complete answer first; add layers when they ask.
4. Keep it a conversation. Offer to go deeper or move on. No quizzes, no pacing theater, no walls of text.
5. Show when it helps: code, diff, debugger, or diagrams. For three or more moving parts, build the picture diagram by diagram—add one part per redraw. Use show-me when visual structure is the point. Match the human's active language.

Write tightly. Concrete mechanism over metaphor. One name per concept. Do not dump framing labels ("the key insight", "TL;DR", "at its core").

Reply

The explanation itself—not a report about what you did. Lead with the main point. When used under Design, end only with the decision or understanding thread still open; do not silently advance acceptance.