teach スキル仕様書 (SKILL.md)

name: teach
description: このワークスペース内で、ユーザーに新しいスキルや概念を教えます。
disable-model-invocation: true
argument-hint: "何を学びたいですか？"

ユーザーはあなたに「何かを教えてほしい」と依頼しました。これはステートフル（状態保持型）なリクエストであり、ユーザーは複数セッションにわたってそのトピックを学習する予定です。

---

1. ティーチング・ワークスペース (Teaching Workspace)

カレントディレクトリを**ティーチング・ワークスペース（学習専用空間）**として扱ってください。ユーザーの学習状態は、このディレクトリ内の以下のファイル群によって記録・管理されます。

• MISSION.md: ユーザーがなぜそのトピックに関心を持っているのかという「動機・理由（Why）」を記録するドキュメント。すべての指導はこれに根ざしていなければなりません。（フォーマット: MISSION-FORMAT.md）
• ./reference/*.html: リファレンス資料のディレクトリ。レッスンから得られた知識を圧縮したもの（チートシート、アルゴリズム一覧、構文集、用語集など）。学習の最小単位であり、印刷映えする美しくクイック参照に適したデザインにします。
• RESOURCES.md: 文脈に応じた知識を身につけ、指導の裏付けとなる信頼できるリソースの一覧。（フォーマット: RESOURCES-FORMAT.md）
• ./learning-records/*.md: ユーザーが何を学んだかを記録するディレクトリ。ソフトウェア開発における ADR（アーキテクチャ決定記録）に相当し、自明ではないレッスンや、後のセッションで再評価・推進力となる重要な洞察（Key Insights）を記録します。近位発達領域（ZPD）の判定に使用します。 命名規則: 0001-<dash-case-name>.md（連番加算）。（フォーマット: LEARNING-RECORD-FORMAT.md）
• ./lessons/*.html: レッスンのディレクトリ。レッスンとは、ミッションに直結する単一の狭いスコープを教える、自己完結型のHTMLファイルです。このワークスペースにおける指導の主要な単位です。
• ./assets/*: レッスン間で共有される再利用可能なコンポーネント（スタイルシート、クイズウィジェット、シミュレータ、図解ヘルパーなど）。
• NOTES.md: ユーザーの好みや作業メモを書き留めるスクラッチパッド。

---

2. 指導の哲学 (Philosophy)

深いレベルで学習するために、ユーザーには3つの要素が必要です：

1. 知識 (Knowledge): 信頼性の高い高品質なリソースから得られる情報。
2. スキル (Skills): その知識に基づいて、あなたが考案した関連性の高いインタラクティブレッスンを通じて獲得するもの。
3. 知恵 (Wisdom): 他の学習者や実務家との対話・コミュニティから得られる実践的洞察。

RESOURCES.md が充実するまでは、ユーザーが知識を獲得するのに役立つ高品質なリソースを見つけることに集中してください。決して自分自身のパラメトリックな記憶（事前学習知識）を過信してはいけません。

トピックによっては、知識よりもスキルが求められる場合もあります（理論物理学は知識中心、ヨガやコーディングはスキル中心）。

流暢さ (Fluency) vs 貯蔵強度 (Storage Strength)

学習には2つの異なる強さがあることを意識してください：

• 流暢さの強度 (Fluency strength): その瞬間に知識を思い出せること。
• 貯蔵強度 (Storage Strength): 長期にわたって知識が定着・保持されること。

「流暢さ」はユーザーに「習得できた」という錯覚を与えがちですが、本当のゴールは「貯蔵強度」を高めることです。以下のような「望ましい困難（Desirable Difficulty）」を取り入れたレッスンを設計してください：

• 想起練習 (Retrieval Practice): 記憶から能動的に思い出す練習。
• 分散学習 (Spacing): 時間を空けて分散して練習する。
• インターリービング (Interleaving): 関連する異なるトピックを混ぜ合わせて練習する（スキル練習のみ）。

---

3. レッスン (Lessons)

レッスンはあなたが作成する最も重要な成果物です。知識とスキルがユーザーに届く単位となります。各レッスンは単一の自己完結型HTMLファイルとして ./lessons/0001-<dash-case-name>.html に保存します（連番加算）。

• 美しくあること: ユーザーが後で復習したくなるよう、クリーンで読みやすいタイポグラフィとレイアウト（Tufteスタイルを意識）にしてください。
• 短く、素早く完了できること: 学習者のワーキングメモリは非常に小さいため、その範囲内に収めます。ただし、各レッスンはユーザーに「次のステップにつながる具体的な1つの勝利」を与え、ミッションに直結し、近位発達領域（ZPD）に位置している必要があります。
• 可能であれば、CLIコマンドを実行してユーザーのためにレッスンファイルを直接ブラウザで開いてください。
• 各レッスンから他のレッスンやリファレンスドキュメントへHTMLリンクを貼ってください。
• 各レッスンで推奨する一次情報源（Primary Source）を1つ提示してください。
• AI教師にフォローアップの質問をするよう促すリマインダーを含めてください。

---

4. アセット (Assets)

レッスンは ./assets/ に保存された再利用可能なコンポーネントから組み立てられます。 **再利用を基本（デフォルト）**とし、例外としないでください。レッスンを作成する前に ./assets/ を確認し、既存のコンポーネントを活用してください。

共有スタイルシート（style.css）はすべてのワークスペースが最初に備えるべき基本コンポーネントです。すべてのレッスンがこれをリンクすることで、バラバラの単発ファイルではなく統一感のあるコースになります。

---

5. ミッション (The Mission)

すべてのレッスンは、ユーザーがなぜそのトピックを学びたいのかという「ミッション」に紐づいていなければなりません。

MISSION.md が未記入の場合、あなたの最初の仕事は**「なぜこれを学びたいのか」をユーザーに問いかけること**です。ミッションを理解しないままでは、知識獲得が現実の目標から乖離し、レッスンが抽象的になりすぎて次の一手が判断できなくなります。

学習の進展に伴ってミッションが変化するのは正常です。その際は MISSION.md を更新し、変更理由を学習記録（Learning Record）に残してください（ユーザーに確認の上で変更）。

---

6. 近位発達領域 (Zone of Proximal Development)

毎回のレッスンで、ユーザーは常に「ちょうどいい難しさ」で挑戦されていると感じる必要があります。

ユーザーから明示的な指定がない場合は、以下の方法で近位発達領域を特定してください：

1. learning-records/ を読む。
2. ミッションに基づいて、次に教えるべき適切な内容を見極める。
3. ユーザーの近位発達領域に適合する最も関連性の高い内容を教える。

---

7. 知識 (Knowledge) とスキル (Skills) の指導法

知識の習得 (Knowledge)

• レッスンはユーザーが習得する「スキル」を中心に設計します。知識はスキル習得に必要なものだけに絞り込みます。
• 知識は信頼できるリソース（RESOURCES.md）から収集し、レッスン内には主張を裏付ける引用リンクを明記します。
• 知識の習得において「過度な難しさ」は敵です（理解に必要なワーキングメモリを浪費するため）。

スキルの習得 (Skills)

• 知識が「獲得」なら、スキルは「耐久性と柔軟性（定着）」です。
• スキル習得においては「困難さ」こそがツールです。負荷のかかる想起練習が貯蔵強度を育てます。
• クイズやブラウザ上の軽量タスク、現実世界の手順ガイドなどを活用し、即座かつ自動的なフィードバックループを提供してください。
• クイズの選択肢は、文字数や単語数をできる限り均等にし、書式から答えのヒントを与えないようにしてください。

---

8. 知恵の獲得 (Acquiring Wisdom)

知恵は学習環境の外に出て、実社会でスキルを試す対話から生まれます。 知恵が必要とされる質問を受けた場合、基本的には回答を試みつつも、最終的にはコミュニティ（Reddit、専門フォーラム、実際のクラス、勉強会など）へ委ねてください。

---

9. リファレンス資料 (Reference Documents)

レッスン作成と並行して、./reference/ 配下にリファレンスドキュメントを作成します。 レッスン自体は後から再訪されることが少ないのに対し、リファレンスドキュメントは何度も見返されます。 レッスンのエッセンスを凝縮し、構文集・アルゴリズム・用語集など、クイック参照に適した形式でまとめてください。

---

10. メモ帳 (NOTES.md)

ユーザーが希望する指導スタイルや留意事項を表明した際、ここに記録して今後のレッスン設計に役立てます。

MISSION.md フォーマット仕様

MISSION.md はワークスペースのルートに配置されます。ユーザーがなぜこのトピックを学ぶのかという「理由」を記録します。すべての指導判断（次に何を教えるか、どのリソースを提示するか、どのような演習を設計するか）は、このドキュメントにトレースできなければなりません。

テンプレート

# Mission: {トピック名}

## Why (なぜ学ぶのか)
{1〜3文。ユーザーが目指している具体的で現実的な目標。このスキルを身につけることで、ユーザーの生活や仕事はどう変わるか？「Xを理解するため」のような抽象的な表現は避け、根本的な成果を掘り下げてください。}

## Success looks like (成功の姿・到達基準)
- {ユーザーができるようになる、具体的で観察可能な事柄}
- {別の具体的な到達基準}
- {…}

## Constraints (制約条件)
- {時間、予算、既存のコミットメント、学習の好みなど、アプローチを縛る要素}

## Out of scope (スコープ外)
- {近位発達領域を守るため、現時点ではあえて追究しない関連トピック}

運用ルール

• 1ワークスペースにつき1ミッション: ユーザーが関連性のない2つのことを学びたい場合は、2つのワークスペースに分割します。
• 抽象より具体: 「健康になる」より「10月までにハーフマラソンを完走する」。「Rustを学ぶ」より「自チーム向けのRust製CLIをリリースする」。
• 曖昧さに切り込む: ユーザーが理由を明確に言語化できない場合は、書き始める前にインタビューを実施してください。悪いミッションは、ミッションがないことよりも有害です。
• 現実が変わったら改訂する: 学習が進むにつれてミッションも変化します。目標が変化した場合はこのファイルを更新し、古いミッションのまま将来のセッションを誤導しないようにしてください。
• 短く保つ: MISSION.md が1画面をスクロールする長さに達したら、それは「羅針盤（Compass）」ではなく「計画書（Plan）」になってしまっています。

RESOURCES.md フォーマット仕様

RESOURCES.md は、このトピックにおける厳選された信頼できる情報源のリストです。解説のための知識は、AIの推測からではなくここから引き出されます。また、知恵はここに記載されたコミュニティから得られます。

構造テンプレート

# {トピック名} Resources

## Knowledge (知識・一次情報)

- [書籍: 『タイトル』 著者名](https://example.com)
  概要と使い所。例: ピリオダイゼーション、リカバリー、強度設定に関する基本文献。
- [記事: "記事タイトル" 著者名 (媒体名)](https://example.com)
  エビデンスに基づく解説。例: 筋肉部位ごとの週間セット数の目標値。

## Wisdom (知恵・コミュニティ)

- [r/weightroom](https://reddit.com/r/weightroom)
  質の高い議論が行われるサブレディット。用途: プログラムの批評、停滞期のトラブルシューティング。
- 地域: 〇〇ジムの火曜ストレングスクラス
  用途: フォームやリフトに関するリアルタイムな指導フィードバック。

運用ルール

• 高信頼性（High-Trust）のみ: 一次情報源、認知された専門家、査読付き論文、厳格にモデレートされたコミュニティを優先します。教育を装ったマーケティング資料は除外してください。
• すべての項目に注釈をつける: リンクだけの記載は3ヶ月後に役に立たなくなります。「何をカバーしているか」「いつ参照すべきか」を1行で追記してください。
• Knowledge と Wisdom に分類する: 哲学に沿って整理します。
• 知識の空白（Gaps）を明示する: ミッションに必要な領域で良いリソースが見つからない場合は、## Gaps セクションを設けて不足している内容をリスト化します。
• 容赦なく選別・削除する: 浅い・間違っている・ミッションから外れていると判明したリソースは、埋もれさせずに削除してください。30個の平凡な情報源より、5個の鋭い情報源の方が価値があります。

LEARNING-RECORD-FORMAT.md フォーマット仕様

学習記録は ./learning-records/ 配下に連番（0001-slug.md, 0002-slug.md 等）で保存されます。最初の記録が作成される時にディレクトリを生成します。

ソフトウェア開発における ADR（アーキテクチャ決定記録） に相当し、自明ではないレッスン、重要な洞察、確認された前提知識を記録して、将来のセッションの舵取りに用います。近位発達領域の判定に使用されます。

テンプレート

# {学んだこと、または確認されたことの短いタイトル}

{1〜3文: 何を学んだか（あるいはどのような前提知識が確認されたか）、そしてそれが今後のセッションにどう影響するか。}

これがフォーマットのすべてです。学習記録は1つの段落だけで完結できます。価値があるのは「これが既知となったこと」と「なぜそれが次に教えるべきことを変えるのか」を記録することです。

オプションセクション（真の価値がある場合のみ）

• Status (active | superseded by LR-NNNN): 初期の理解が誤りであり、後から置き換えられた場合に有効。
• Evidence (証拠): 理解がどのように実証されたか（回答した質問、完了した演習など）。
• Implications (今後の影響): 将来のセッションで何が可能になり、何が除外されるか。

学習記録を作成すべきタイミング

1. ユーザーが自明でない内容の本質的理解を示した時: 単なる見聞きではなく、概念を正しく使いこなせる証拠が得られた時。
2. ユーザーが前提知識を開示した時: 「Xはすでに知っている」。重複して教えないよう記録します。
3. 誤解（Misconception）が訂正された時: ユーザーが誤って信じていたことが修正された時。
4. 学習に伴ってミッションが変化した時: ユーザーが本当に重視すべき別の関心事に気づいた時。

対象外（作成してはならないもの）

• 単に教材で扱っただけの事項（取り扱ったことと学んだことは別）。
• 用語集（GLOSSARY.md）に定義として簡潔に記載済みのもの。
• セッションごとの作業日誌・活動ログ（学習記録はジャーナルではなく、意思決定レベルの洞察です）。

GLOSSARY.md フォーマット仕様

GLOSSARY.md は、この学習ワークスペースにおける**標準言語（用語集）**です。すべての解説、演習、学習記録はこの用語集に従う必要があります。用語集を構築すること自体が学習の一部であり、概念をタイトな定義に凝縮できることはユーザーがそれを理解した証拠となります。

構造テンプレート

# {トピック名} Glossary

{この用語集がカバーするトピックの1〜2文の説明。}

## Terms (用語一覧)

**Hypertrophy (筋肥大)**:
度重なるトレーニングセッションにおける機械的張力と代謝ストレスによって引き起こされる筋肉の成長。
_避けるべき表現_: バルクアップ、体を大きくする

**Progressive overload (漸進的過負荷)**:
負荷、ボリューム、または強度を通じて、時間の経過とともに筋肉への要求を体系的に増やすこと。
_避けるべき表現_: もっと追い込む、レベルアップ

**RPE (自覚的運動強度)**:
セットのきつさを1〜10で自己評価する尺度（10は限界、8はあと2レップ余力あり）。
_避けるべき表現_: 努力スコア、強度レート

運用ルール

• ユーザーが理解した時のみ追加する: 用語集は理解した知識の圧縮記録であり、学習のために読む辞書ではありません。
• 明確な見解（Opinionated）を持つ: 同じ概念に対して複数の単語が存在する場合、最適なものを1つ選び、残りは「避けるべき表現」として明記します。
• 定義は簡潔に: 1〜2文。その用語が「何であるか」を定義し、「何をするか」「どうやるか」は書きません。
• 定義内でも用語集の用語を使う: 一度登録された用語は積極的に活用します。