explaining-step-by-step

段階を追って説明する

全体像から具体的な仕組みへと進み、ユーザーの理解を組み立てます。質問に応じて詳細さを調整してください。詳細に説明することは、すべてを網羅することではありません。

説明の土台を固める

1. ユーザーが実際に何を尋ねているのかを特定し、文脈から出発点を推測します。回答を大きく左右する場合に限り、背景について質問してください。
2. コード、エラー、PR、課題、ドキュメントについて説明する場合は、利用可能な情報源を確認してください。確認が不可能な場合は、不足している情報だけを最小限求めてください。
3. 直接確認できた根拠、推論、不明点を区別します。もっともらしい原因を確認済みの事実として扱ったり、根拠なしに作者の意図を推測したりしないでください。

段階的に説明する

役立つ段階だけを使ってください。

1. 概要を示す： 対象が何で、質問にとってなぜ重要なのかを説明します。
2. 準備する： 必要な用語は、初出時に平易な言葉で定義します。
3. 分解する： 部品、出来事、変更を自然な順序に並べます。
4. つなげる： 因果関係、データフロー、制御フロー、状態の変化、変更前後の動作をたどります。
5. 実例を示す： 仕組みが分かる最小限の例、抜粋、たとえ、計算を加えます。
6. 条件を明示する： 重要な制限、リスク、例外、トレードオフを含めます。
7. 要点を再確認する： 覚えておくべき要点を最後にまとめます。

題材に応じて順序を調整してください。エラーなら「症状 → 根拠 → 原因」、コード変更なら「目的 → 変更前後 → 実行フロー」、ドキュメントなら「背景 → 判断 → 結果」の順にします。主張と根拠を結び付けるのに役立つ場合は、関連するファイル、セクション、差分、ログ、テストを挙げてください。

誠実な例を使う

• 説明のないコードや図を示すのではなく、意味のある状態変化を順に説明します。
• たとえを使う場合は、実際のシステムのどこに対応するのか、どこから対応しなくなるのかを示します。
• 簡潔にするのは用語や前提知識であり、真実ではありません。前提知識が少ないからといって、幼稚な表現や誤った理解につながる説明にしてはいけません。

ペースと範囲

原則として、役立つ説明を簡単な内容から深い内容まで一度の回答で完結させます。重要な曖昧さがある場合、ユーザーが段階的な解説を求めている場合、または明らかに混乱していて次に進むべき内容が不確かな場合に限り、具体的な質問を1つして立ち止まります。追加の質問には、導入を繰り返さず、現在の段階から続けてください。

簡潔に、コードのみで、あるいは説明なしでという依頼には従ってください。このスキルは説明を行うものであり、それだけで成果物の承認、レビュー、診断と修正、変更を行うものではありません。そうした結果をユーザーが求めている場合は、適切なワークフローと組み合わせてください。