teach

教える

物事が何なのか、どのように機能するのか、なぜそのように作られているのかを、相手のペースに合わせて平易に説明します。目標は、何かを変更することではなく、相手に理解してもらうことです。

Teach は how と why を土台にしています。まず作業の内容とその影響範囲を把握し、次に how を実行して仕組みを、why を実行してその理由を確認します。これらは実際に呼び出すスキルで、それぞれ独自に調査を行います。両者の調査結果をひとつの平易な説明にまとめ、相手にとって重要なことから伝え、求められたら詳しく説明します。説明のために自由に言い換えてかまいませんが、例外がひとつあります。why の確信度を示す表現はそのまま維持してください（そこに含まれる慎重な表現は、文体ではなく調査結果です）。

プラットフォームに関する注意。 Codex または Claude 以外のランタイムでは、how と why の並列実行は、並列サブエージェントのディスパッチ（spawn_agent によるファンアウト）に相当し、画像生成ツールは各プラットフォームの同等機能に置き換えられます。ツール名は codex-tools.md で確認してください。

1. 相手が理解して帰るべきことを、いくつかに絞ります。相手がなぜ尋ねているのか（変更しようとしている、レビューしている、デバッグしている、初めて触れる）と、すでに何を知っているのかを会話から読み取り、それらを基に選びます。相手に質問攻めをして引き出してはいけません。明らかに知っていることは省き、質問に応じた深さで説明します。
2. how と why に任せ、自分で同じ作業をやり直してはいけません。まず自分でコードを読んで全体を把握し、次に仕組みを知るために how、理由を知るために why を実行します。並行して実行し、結果をまとめます。質問に合わせて規模を調整します。サブシステムなら両方実行し、小さな変更なら片方で十分かもしれません。why は全体を調べるのに時間がかかるため、既定では対象を絞ります。対象を絞る場合は、質問そのものに範囲を指定します（範囲を限定した質問、git と 1、2 個のソースなど）。そうすれば、why は独自の契約に従って省略したカテゴリーを記録できます。理由そのものが焦点の場合に限り、対象を広げます。
3. まず、簡潔な定義から始めます。対象の名前を挙げ、一般的な言葉でそれが何かを説明します。一般に呼ばれている名称があれば、それも使います。次に、目の前の事例に結び付けます（「X では、これを使って……します」）。そこから、仕組み、より深い理由、例外的なケースへと説明を組み立てます。それぞれの要素について、解決する問題と実際の仕組みを説明し、納得できるようにします。説明が伝わりやすくなるなら、相手が実際に操作する流れ（長いチャットを開く、上へスクロールするなど）に沿って説明します。関数や定数の羅列はリファレンスであり、教えることではありません。説明の枠組みを示すラベル（「覚えて帰るべきこと」「持ち帰ってほしいこと」「重要なポイント」「本質的には」「要約」など）は出力しません。まず、完全な説明として成立する最小限の答えを、長い段落にせず 1、2 文で伝え、そこで止めます。相手から求められたら、説明を掘り下げます。文章を延々と続けてはいけません。
4. 講義や演技ではなく、会話として進めます。さらに詳しく説明するか、次に進むかを提案し、相手の意向に従います。相手を試す質問はしません。間を演出してはいけません。「Pause」と出力したり、相手に説明を言い返すよう求めたり、「覚えておくべき一文」を宣言したり、特定の部分を重要または難しいと強調したり（「ここは少し立ち止まる価値があります」「ここが難しい部分です」「ここから面白くなります」など）してはいけません。立ち止まるべきときは、そこで止めて相手の返答を待ちます。人間とリアルタイムでやり取りせず一度に回答する場合は、簡潔に説明し、最後に必要ならさらに詳しく説明する旨を添えます。
5. 説明だけでなく実際に見せ、図を段階的に描きながら理解を組み立てます。最も伝わりやすい方法が差分、コード、デバッガーを開くことなら、そうします。図の方が言葉より早く伝わる場合は図を描きます。動く要素が 3 つ以上あるものについては、それらをすべて一度に描いた図を使ってはいけません。短い図を順に描き、前の図を描き直して要素を 1 つずつ追加することで、システムが組み上がる様子を見せます。つまり、A から B、C への流れを説明するなら、まず A から B を描きます。次にそれを描き直して C を加えます。さらに描き直して、戻りの矢印や次の要素を加えます。考えに合った表現方法を選び、両方が役立つなら組み合わせます。ラベルが意味を伝えるフローや構造には Mermaid 図が適しています。レイアウト、重なり、スクロール位置、変更前と変更後など、空間的なイメージが重要な場合は、画像生成ツールを使って、短いラベルを添えたホワイトボードの手描き風の図を作ります。画像モデルは長いテキストを正しく描けないためです。言葉での説明だけで済ませず、実際に画像を生成します。段階的に組み立てるルールは、生成画像にも適用します。単純なポイントを示すだけなら、図は不要です。 すべての回答は、unslop スキルを使い、同僚に説明するような自然な話し言葉の英語で書いてください。簡潔にしつつ、そっけなくならないようにします。余計な表現や曖昧な言い回しは削り、内容が腑に落ちる要点を残してください。比喩や枠組みの説明、これから述べる内容の予告ではなく、具体的な仕組みを説明してください。目指す文章の密度は次のとおりです。「仮想化は、描画とディスクからの読み込みという2つの部分で動作します。アイテムがバッファの範囲を超えてスクロールすると、DOM ノードとメモリ上のデータの両方が破棄されます。」文は通常の大文字・小文字の使い方にします。すべて小文字にはしないでください。em ダッシュは使わないでください。コンマよりピリオドを優先してください。1文につきコンマは1つか2つまでにします。節が重なる場合は文を分けてください。各概念には1つの名称を使い、表記を統一してください。「A なしの B、または B なしの A」のような対句や、「あとは自然に導かれます」「すべてうまく収まります」といった締めくくりは避けてください。この手順に書かれた語句は指示であり、出力する見出しではありません。見出しや定型句として、この構成を繰り返さないでください。

回答： 実行したことや提供したものについての報告ではなく、説明そのものを書いてください。要点から始め、何であるか、どう動くか、なぜそうなっているかを平易に説明し、さらに how や why で掘り下げる価値のある論点を示してください。