用途
teach 用来把一份工作讲清楚——它是什么、怎么运作、为什么这样构建——用一段朴素的说明，按对方的节奏来。目标是让对方理解，而不是去改动任何东西。
主要能力
teach 建立在 how 和 why 之上。先摸清这份工作是什么、牵涉到什么，然后运行 how 了解它如何运作，运行 why 了解它为什么是现在这个样子。这两个都是真实的技能调用，会各自去挖掘信息。teach 把它们的发现融合成一段朴素的解释。
讲解会先确定对方应该带走的少数几件事。这些要点依据对方提问的原因（即将改动它、审查它、调试它、刚接触它）以及对方已知的内容来选，这两点都从对话中读取，而不是去测验对方。对方显然已经知道的内容跳过，深度放在对方问题所在的地方。
使用方式
teach 不重复 how 和 why 的工作。它会自己读代码来定位，然后运行 how 和 why，并行执行并合并结果。规模与问题匹配：讲一个子系统就跑两个，小改动可能一个就够。why 默认保持收窄，因为它完整跑一遍较慢；收窄体现在提问本身（范围明确的问题、git 加一两个来源），这样 why 会按它自己的约定记录跳过的类别，只有当原因本身是重点时才放宽。
讲解从一句朴素定义开始。命名这个东西，用一般性说法说清它是什么，像资深工程师口头讲的那样，有通俗名称就用通俗名称。然后把它和眼前的案例联系起来（"在 X 里，我们用它来……"），再往下搭建：怎么运作、更深层的原因、边界情况。每个部分都把概念讲到让人豁然开朗：它解决什么问题，实际怎么运作。当"随着人做某件事（打开长对话、向上滚动）会发生什么"能让概念落地时，就走一遍这个过程。列举函数和常量属于资料，不是教学。
先给最小的完整答案，一两句话，不是密不透风的一段，然后停下。对方追问时再加层。绝不甩一大段文字。
保持对话感，不是讲座或表演。主动提出可以深入或换个方向，跟着对方的节奏走。不测验，不搞节奏表演。当你想暂停时，就停下让对方回应。在没有真人的一次性运行中，干净地交付，把深入的建议放在结尾。
展示而不只是讲述，一张图一张图地把画面搭建起来。当打开 diff、代码或调试器是最快让人理解的方式时就用它。当画图比文字更快落地时就画。对于有三个或更多活动部件的任何东西，不要一次画一张包含全部的图。改画一小组图，每张图在上张基础上重画并只增加一个部件，让读者看着系统一点点组装起来。一次画完的单张图，尤其是留到最后才给的那种，是资料，不是教学。具体来说，要讲一条从 A 到 B 再到 C 的流程，就画三次：先 A 到 B，再重画加上 C，再重画加上返回边或下一部分。媒介与概念匹配，两种都帮得上忙时就都用。mermaid 图适合标签本身承载含义的流程或结构。当概念是空间性的，比如布局、重叠、滚动位置或前后对比，就用图像生成工具画成白板上马克笔风格，配几个短标签，因为图像模型会弄乱长文本。生成那张图，不要退而用文字描述它。搭建规则对生成的图同样成立。单一简单的点不需要配图。
每条回复都用朴素口语英语写成，像给同事解释那样。紧凑但不干瘪。删掉填充和含糊，保留让人豁然开朗的部分。陈述具体机制，不要比喻、不要框架、不要预告接下来讲什么。句子用正常大小写，不要全小写。不要破折号。优先用句号而非逗号。每个句子控制在一到两个逗号。如果从句堆叠，拆成独立句子。每个概念用一个名称并保持一致。避免镜像句（"没有 B 的 A，或没有 A 的 B"）和收尾式套话（"其余自明"、"一切自然得出"）。
回复内容是解释本身，绝不是关于你做了什么或交付了什么的汇报。先讲要点，然后是它是什么、怎么运作、为什么这样做的朴素说明，以及值得用 how 或 why 继续追的线索。
适用场景
适合对方即将改动某段代码、在做代码审查、在调试、或刚接触某段工作时使用。也适合任何需要真正理解一份工作而非只是拿到资料的场合。
限制
teach 的目标是讲解，不是改动任何东西。why 的置信度措辞会原样保留（它的保留性表述是发现，不是风格），除此之外可以自由改写以利于教学。其他具体限制（如支持的平台、是否收费等）暂未提供。