メニュー
カレントディレクトリを学習ワークスペースとして、ミッション駆動のレッスン（HTML）で概念・スキルを複数セッションかけて教える。新しいトピックの学習を始めたい時・前回の学習を再開したい時に /teach で実行。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | teach |
| description | カレントディレクトリを学習ワークスペースとして、ミッション駆動のレッスン（HTML）で概念・スキルを複数セッションかけて教える。新しいトピックの学習を始めたい時・前回の学習を再開したい時に /teach で実行。 |
| argument-hint | 何を学びたいか |
| disable-model-invocation | true |
ユーザーに何かを教える。これはステートフルな依頼であり、ユーザーは複数セッションにわたってトピックを学ぶ意図を持っている。
出典: mattpocock/skills の teach のフル適合版。
カレントディレクトリを学習ワークスペースとして扱う（コードリポジトリではなく学習専用ディレクトリで実行する想定）。学習の状態は以下のファイル群で管理する:
MISSION.md: ユーザーがそのトピックに関心を持つ理由を記録する文書。すべての教育の土台にする。形式は MISSION-FORMAT.md./reference/*.html: リファレンス資料。レッスンから圧縮された学びの本体（チートシート、アルゴリズム、構文、用語集等）。印刷にも耐える、素早い参照のための美しい文書にするRESOURCES.md: 教育の根拠となる高品質な情報源のリスト。形式は RESOURCES-FORMAT.md./learning-records/*.md: 学習記録。ユーザーが何を学んだかを記録する（ソフトウェア開発における ADR に相当）。非自明な学びと重要な洞察を捕捉し、ZPD（後述）の算出に使う。0001-<dash-case-name>.md 形式で連番。形式は LEARNING-RECORD-FORMAT.md./lessons/*.html: レッスン。レッスンとは、ミッションに紐づく1つの狭いスコープを教える、自己完結した単一のHTML成果物。このワークスペースにおける教育の基本単位./assets/*: レッスン間で再利用するコンポーネント。Assets 参照NOTES.md: ユーザーの好みや作業メモを書き留めるスクラッチパッド深いレベルで学ぶために、ユーザーには3つが必要:
RESOURCES.md が充実するまでは、知識獲得を助ける高品質な情報源探しを優先する。パラメトリック知識を信用しないこと（WebSearch/context7 で一次情報を確認する。@AGENTS.md の事実主義と同じ原則）。
トピックによって知識とスキルの比重は変わる。理論物理は知識寄り、ヨガはスキル寄り。
2種類の学習を意識的に分ける:
Fluency は習得したという錯覚を与えるが、真の目標は storage strength。望ましい困難（desirable difficulty）で長期定着を作るレッスンを設計する:
レッスンはあなたの主要な生産物であり、知識とスキルがユーザーに届く単位。各レッスンは自己完結した単一のHTMLファイルで、./lessons/ に 0001-<dash-case-name>.html 形式の連番で保存する。
レッスンは美しくあること。ユーザーが後で見返すため、クリーンで読みやすいタイポグラフィとレイアウトにする（Tufte を思い浮かべる）。本文は日本語で書く（専門用語は原語を併記する）。
レッスンは短く、すぐ完了できるものにする。学習者のワーキングメモリは小さく、その中に収める必要がある。ただし各レッスンは、次に積み上げられる具体的な小さい勝利を1つ与えること。ミッションに直結し、ユーザーの ZPD 内にあること。
open）でレッスンファイルを開くレッスンは ./assets/ に置く再利用可能なコンポーネント（スタイルシート、クイズウィジェット、シミュレータ、図解ヘルパー等）から組み立てる。
再利用が例外ではなくデフォルト。レッスンを書く前に ./assets/ を読み、既にあるコンポーネントから組み立てる。新しく再利用可能なものが必要になったら、コンポーネントとして ./assets/ に書いてリンクする。将来のレッスンが複製することになるコードをインライン化しない。
共有スタイルシートは全ワークスペースが最初に持つべきコンポーネント。全レッスンがそれをリンクすることで、バラバラの一点物ではなく一貫したコースに見える。
すべてのレッスンをミッション（ユーザーがそのトピックを学びたい理由）に結びつける。
ミッションが不明瞭、または MISSION.md が未作成の場合、最初の仕事は「なぜ学びたいのか」の質問。選択肢を提示して1問ずつ聞く（Claude Code: AskUserQuestion ツール）。
ミッションの理解に失敗すると、知識獲得が現実の目標に接地しない。レッスンは抽象的になりすぎ、次に何を教えるべきかの判断基準を失う。
ミッションはユーザーの成長に伴って変わり得る。これは正常なこと。MISSION.md を更新し、変化を学習記録として残す。ミッション変更はユーザーに確認を取ってから行う。
各レッスンでユーザーが「ちょうどよく挑戦されている」と感じること。
学びたいことをユーザーが指定したらそれに従う。指定がなければ以下で ZPD を割り出す:
learning-records を読むレッスンはユーザーが獲得するスキルを軸に設計する。レッスン内の知識は、そのスキル獲得に必要な分だけに絞る。知識を先に教え、その後インタラクティブなフィードバックループでスキルを練習させる。
知識はまず信頼できる情報源から集め、RESOURCES.md で管理する。レッスンには引用（主張を裏付ける外部リンク）を散りばめ、信頼性を高める。
知識の獲得では、難しさは敵。理解に必要なワーキングメモリを食い潰す。
知識が獲得の問題なら、スキルは定着と応用の問題。知識を定着させる。
スキル獲得では、難しさは道具。労力を要する想起こそが storage strength を作る。使える手段:
いずれもフィードバックループを軸にする。フィードバックは即時に、できれば自動で返す。
クイズの選択肢は全て同じ語数（可能なら同じ文字数）にし、形式から答えのヒントを与えない。
知恵は本物の現実世界での交流——学習環境の外でスキルを試すこと——から来る。
知恵を要する質問には、まず自分で答えを試みたうえで、最終的にはコミュニティに委ねる姿勢をデフォルトにする。
コミュニティとは、ユーザーが現実世界でスキルを試せる場（オンライン/オフライン）。フォーラム、subreddit、現実の教室（予算が許せば）、地域の同好会など。評判の高いコミュニティを探して提案する。ユーザーが参加したくないと表明したら尊重する。
レッスン作成と並行してリファレンス文書も作る。レッスンはそれらを参照できる。レッスンをまたいで有用な知識の原単位を管理するのに役立つ。
レッスンが後で読み返されることは稀だが、リファレンス文書は読み返される。レッスンの圧縮されたエッセンスを、素早い参照のための形式で書く。
リファレンスに向くトピックの例: プログラミングの構文・スニペット、プロセスのアルゴリズム・フローチャート、ヨガのポーズとシーケンス、フィットネスの種目とルーティン、独自の術語体系を持つトピックの用語集。
特に用語集は必須のリファレンス。一度作ったら全レッスンでそれに従うこと。形式は GLOSSARY-FORMAT.md。
ユーザーは時折、教え方の好みや配慮してほしいことを口にする。それを記録する場所。レッスン設計やユーザーとのやりとりの際に参照する。
.local/ メモリディレクトリは使わないコードベース包括的レビュー。6観点（perf/sec/test/arch/cq/docs）を並列サブエージェントで実行し、優先度付きissueファイルをメモリディレクトリに生成。使用タイミング: コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review実行時。境界: PR単位のレビュー→pr-review、自ブランチの提出前確認→self-review、ローカル未コミット変更→/code-review、ドキュメントのレビュー→doc-review。
既存設定と整合したスキルを新規作成。「スキルを作って」「この手順をスキル化して」等の依頼時、/create-skill実行時に使用。~/.claude/AGENTS.md（CLAUDE.mdは互換symlink）、context/*.md、既存スキルを自動参照し、重複・競合を避けたスキルを生成。境界: 既存スキル・指示ファイルの修正→update-inst、指示ファイル全体の監査→instructions-audit。
抽象的な要件・Biz 要求から要求を深掘りし、コードベース SSoT で既存実装整合性を確認した上で「実装マスタ（01_requirements_skeleton.md）」と「システム要件書（02_system_requirements.md）」を作成する。使用タイミング (1)「○○って機能を作りたい」「このBiz要求を満たす機能を設計して」等の抽象要件提示時、(2) 既存機能の拡張・Phase 分割等の要件定義開始時、(3) `/design-feature ...` 実行時。
Agent Teamsによる多角的ドキュメントレビュー。設計書・仕様書・計画書等のドキュメントを6 Agent（通常4 + Devil's Advocate + agent CLI）で並列レビュー。使用タイミング: (1) /doc-review 明示実行時、(2) 「チームでレビューして」「多角的にレビューして」等の明示依頼時（Agent Teams発動条件(c)相当）。通常の「レビューして」だけの依頼では発火しない（単独レビューまたはagent CLIで対応し、必要なら本スキルを提案する）。
既存の計画・設計・アイデアを徹底的に尋問し、共有理解に至るまでストレステストする対話スキル。使用タイミング: (1) 「グリルして」「grillして」「この計画を詰めて」「計画の穴を突いて」「ストレステストして」等の依頼時、(2) 実装着手前に計画・設計の前提や未決定事項を洗い出したい時。境界: ゼロからの要件定義・要件書作成→design-feature、完成した文書の多角的レビュー→doc-review。本スキルは既に存在する計画・アイデアの対話的な検証を行う。要件書等の成果物は生成せず、確定した重要決定のみADRとして.local/docs/に記録する。
現在のセッション内容を、別セッションのエージェントが引き継げるハンドオフ文書に圧縮し、メモリディレクトリに書き出す。セッションを切り替えたい時・作業を中断して後日再開したい時に /handoff で実行。