| name | doc-prerequisite-knowledge |
| description | あるトピック(技術、概念、ライブラリ、フレームワーク、アルゴリズム、API、プロトコル等)を、必要な前提知識から積み上げて段階的に理解できるよう体系的に解説する。ユーザーが「〜について基本と前提知識から理解できるように教えてください」「〜を基礎から学びたい」「〜の前提知識から教えて」「〜を体系的に学びたい」「explain X from basics including prerequisites」のような学習・教育リクエストをした際に使用する。検証済みの公式ドキュメントへのリンクを含めて、信頼できる一次情報源と継続学習の足がかりを提供する。 |
Doc Prerequisite Knowledge
最小限かつ十分な前提知識チェーンを構築し、各概念に検証済みの公式ドキュメントを添えて段階的に解説する。
ワークフロー
進行中はこのチェックリストを応答にコピーして進捗を管理する:
進捗:
- [ ] Step 1: トピックの種類を特定
- [ ] Step 2: 前提知識をリストアップ (MECE / 2階層以内)
- [ ] Step 3: 公式ドキュメント URL を WebFetch で実在確認
- [ ] Step 4: 段階的構造で解説を出力
- [ ] Step 5: 品質チェックリストで自己検証
Step 1: トピックの種類を特定する
ユーザーが指定した対象を以下のいずれかに分類する。種類によって出力の重点が変わる:
| 種類 | 例 | 重点的に書く節 |
|---|
| ライブラリ / フレームワーク | React, Kubernetes, FastAPI | 主要構成要素、典型的な使い方 |
| 言語機能 / API | Python generator, JS Proxy, Rust async | 文法・挙動、最小コード例 |
| 概念 / アルゴリズム | B-tree, CAP定理, eventual consistency | 仕組み、トレードオフ |
| プロトコル / 仕様 | OAuth 2.0, HTTP/2, gRPC | 構成要素、メッセージフロー |
| ドメイン知識 | ACID, BGP, OOM killer | 解決する問題、実例 |
スコープが曖昧で複数解釈が可能な場合(例: 「Rustのasync」 = 言語機能か tokio か全般か)、最初に1つだけ確認質問してよい。それ以外は推測で進める。
想定読者レベル: 明示が無ければ「プログラミングは知っているが、そのトピックは初めて触れる」を default とする。ユーザーの直前の言葉づかいや既出の概念から上下に調整する。default を超えて高度に書かない —「難しすぎ」は出力が読まれない最大要因。
Step 2: 前提知識をリストアップする
トピックを理解するために本質的に必要な概念を、依存関係に沿って書き出す。
原則:
- MECE に、過不足なく並べる
- 深さは原則2階層まで(前提の前提まで遡らない。不可避なら1行で触れるだけにする)
- ユーザーが既知と思われる common sense レベルは省く
- 各前提について「なぜこれを先に理解する必要があるか」を1行で言語化できること(できなければ削る)
例: 「Rust の async/await を理解する」ための前提知識
Future trait — async 関数が返すものの正体- ownership / borrowing の基本 — async 固有の借用制約に直結する
- executor の役割 — 誰が
Future を進めるのか
- pinning の概要 — 自己参照構造を安全に扱うため
不要な例: 「Rustの基本構文」「変数とは何か」(common sense として既知の前提)
Step 3: 公式ドキュメントを検証して取得する
最重要原則: URL を絶対にハルシネートしない。実在しない URL を書くくらいなら、URL を書かない。
各前提知識および本題のトピックについて、一次情報源を探す:
WebSearch で {topic} official documentation / {topic} 公式ドキュメント 等を検索する- 候補 URL は 必ず
WebFetch で実在確認 する(タイトル・内容が想定と一致するか)
- 確認できなかった URL は出力に含めない。代わりに「公式ドキュメントを参照」と一般案内に留める
- 多数の URL を一度に検証する必要があれば
Agent(subagent_type=Explore または general-purpose)に委譲する
優先順位:
- 一次ソース: 公式サイト / 公式ドキュメント (例:
docs.python.org, kubernetes.io, developer.mozilla.org, IETF RFC)
- 準公式: メンテナーの公式ブログ、公式リポジトリの README / Spec
- 避ける: 個人ブログ、Qiita 等の二次情報。公式が無い/不十分な場合のみ「補助」と明記して使う。
Step 4: 段階的な構造で解説する
以下のテンプレートで出力する。トピックの性質に応じて節を増減してよい。
# {トピック}
## 一言で言うと
{1-2 文の要約。専門用語の連続を避ける。形式的定義は使わない}
## ざっくりイメージ
{身近なものへの比喩、または「もしこれが無ければ何を手作業でやるはめになるか」を 2-4 文で。専門用語ゼロを目指す。これが書ければ理解の土台ができる}
## なぜ必要か(動機)
{これが無い世界の不便さ、解決される課題}
## 前提知識
### 1. {前提概念A}
- **やさしい説明**: {専門用語を使わずに 1-2 文。「要は〜のこと」のトーン}
- **本題との関係**: {なぜ先に必要か。1 文}
- **もっと正確には**: {必要なら形式的定義を 1 文。不要なら省く}
- **公式ドキュメント**: [{title}]({verified URL})
### 2. {前提概念B}
...
## 本題: {トピック}
### 基本概念
{核となる仕組み・モデル}
### 主要な構成要素
{用語と役割を箇条書き}
### 典型的な使い方
{最小の実行可能なコード例 or フロー}
### 注意点・落とし穴
{初学者が躓きやすいポイント}
## 公式ドキュメント・参考資料
- [{title}]({verified URL}) — {何が書かれているか}
## 次のステップ
- {具体的な次に学ぶトピックや、深掘り用の公式リソース}
省略可能な節:
- 前提知識がほぼ無い場合は「前提知識」節を省く
- 概念系で「典型的な使い方」が自然でない場合は省く
- 「注意点・落とし穴」が思いつかない時は無理に書かない
わかりやすく書く指針 (default の想定読者「初めて触れる」に最適化):
- 1 文に新しい概念は 1 つまで。2 つ以上ある文は分ける
- 具体 → 抽象 の順で書く(抽象的な定義を先に置かない)
- 専門用語の初出は「平易な言い換え (専門用語)」の形にする。例: 「文字列を意味のかたまりに分ける処理 (字句解析)」
- 数式・形式的記法 / 4つ組のような数学的定義は、散文で同じ内容を述べた 後に 添える
- 比喩を 1 つは入れる (「〜のようなもの」)。ただし「厳密には〜と異なる」と1行注記する
- コード例は 最小・実行可能 なものに留める
- 「魔法のように動く」式の説明は避け、中で何が起きているかを少しでも見せる
- 表は 参照用 ではなく 理解用 に使う(無理に大きな表を入れない)
例: 「字句解析」の説明の良し悪し
❌ わかりにくい:
字句解析とは、入力文字列を字句単位 (lexeme) に分割し、それぞれにトークン種別を付与して終端記号列を生成する処理である。
✅ わかりやすい:
x = 1 + 2; のような生の文字列を、[ID, =, 1, +, 2, ;] のような「意味のかたまり」の列に分ける前処理が 字句解析 (lexer)。空白やコメントもこの段階で捨てる。
品質チェックリスト (Step 5)
出力前にこのチェックリストを応答にコピーして自己確認する:
- [ ] すべての URL は WebFetch で実在確認した (または書かず一般案内に留めた)
- [ ] 前提知識は2階層以内に収まっている
- [ ] 各前提に「やさしい説明」と「本題との関係」が書かれている
- [ ] 未定義の専門用語が無い (初出時に平易な言い換えがある)
- [ ] 1 文に新概念が 2 つ以上含まれている箇所が無い
- [ ] 「ざっくりイメージ」に身近な比喩か具体例があり、専門用語ゼロで読める
- [ ] 「一言で言うと」が、専門用語の連続なしで理解できる
- [ ] 「次のステップ」が具体的なリソース / トピックを指している
- [ ] 出力全体がユーザーの前提レベルに合っている (default は「初めて触れる読者」)
注意事項
- 知識が古くなりがちな領域 (ライブラリのバージョン、最新仕様等) は、検索で新しい情報を確認してから書く
- 推測で書く部分は明示する (例: 「内部実装は version 1.x 時点」)
- 出力言語はユーザーの言語に合わせる (日本語 / 英語両対応)
- 長くなる場合は最も重要な前提 3-5 個に絞る。網羅より「読み切れる量」を優先する
