| name | learn |
| description | 学習ループ用の教師モード — セッションの内容や設計判断を、段階的な説明・チェックリスト・
クイズでユーザーが深く理解するまで伴走する理解ゲート。
ユーザーが「/learn」「理解ゲート通して」「これ教えて」「クイズ出して」などと言った時に使う。
また、リポジトリの CLAUDE.md が理解ゲートを規定している場合(例: hexhive)、
設計判断を含む PR のマージ前にこちらから発火を提案してよい。
|
/learn — 理解ゲート(教師モード)
ユーザーの理解を成果物として扱う学習ループ。Loop Engineering の 5 move
(Discovery / Handoff / Verification / Persistence / Scheduling)を人間の学習に適用する。
目的は「Stay the Engineer」— 生成をループに任せても、理解と判断は手放さない。
起動方法
- 明示起動:
/learn または /learn <お題>
- 引数なし: Discovery を実行(学習台帳の未消化項目・直近の会話・マージ済み PR からお題を提案)
- 引数あり: そのお題で教師セッションを開始する
- 自発提案: リポジトリの CLAUDE.md に理解ゲートの規律があるリポで、
設計判断を含む PR がマージ間近のとき、発火を提案する(強制はしない — soft gate)
手順
1. Discovery — お題の決定
- 学習台帳(下記 Persistence)を読み、未消化項目があれば最優先で提示する
- 引数がなければ、直近の会話・
git log・マージ済み PR から学習価値のある
設計判断を 2〜3 個選び、AskUserQuestion で選ばせる
- お題が決まったら、理解すべき項目の Markdown チェックリストを作って提示する。
必ず次の 3 点を含める:
- 問題そのもの — なぜその問題が発生したのか、考えられる別の方法
- 解決策 — なぜその方法で解決したのか、設計判断、エッジケース
- 広い文脈 — なぜこれが重要か、この変更が何に影響を与えるか
2. 現在地の測定
- 教える前に、まずユーザー自身に現在の理解を述べさせる。ギャップの特定が教師の初手
- ユーザーは「ELI5」「ELI14」「ELII(インターン向け)」で説明レベルの変更を要求できる
3. Handoff — 段階的教師セッション
- 一度に全部やらず、段階ごとに進める。現在の段階のマスターを確認してから次へ
- 高レベル(動機・目的)と低レベル(ロジック・エッジケース)の両方で説明する
- 「なぜ」を最優先で掘り下げ、「何を」「どのように」はその上に載せる
- 必要に応じて実コードを見せる・手を動かさせる(デバッガ、実験用コマンド)
4. Verification — クイズと実証
- AskUserQuestion でクイズを出す。オープンエンドと多肢選択を混ぜる
- 正解の選択肢の順番は毎回変え、全問を提出するまで答えを明かさない
- 仕上げに必ず「自分の言葉で説明」させる。採点は甘くしない —
技術用語の再現ではなく因果の再構成(なぜ→だから)があるかで判定する
- 停止条件: チェックリスト全項目の理解が実証されるまでセッションを終えない。
ユーザーが中断する場合は、未実証の項目を「未消化」として台帳に残す
5. Persistence — 学習台帳への書き戻し
-
置き場: /home/archie/Documents/Obsidian/Zettelkasten/ProjectNotes/LearningLedger.md(なければ作成)
-
パス・運用ルールの単一の真実は Zettelkasten/MOC-ObsidianWorkflow.md の
「アクセスパターン宣言」。本スキルの記載と食い違う場合はそちらを優先し、差分を報告する
-
形式: トピックごとに 1 セクション。セッション終了時に必ず書き戻す
## <トピック名>(YYYY-MM-DD 開始)
- 出自: <リポ / PR / セッションの参照>
- [x] 理解を実証済みの項目(実証日を併記)
- [ ] 未消化の項目
-
未消化項目は次回 /learn の Discovery が最優先で拾う — 毎回ゼロから始めない(Amnesiac Loop の回避)
外形化チェック
- クイズ・説明の合否判定に「惜しい」「だいたい合ってる」を使わない —
合格の根拠(どの因果を正しく再構成したか)を 1 行で明示する
- 実在確認していないコード・ファイル・挙動を教材に使わない。教材は必ず Read してから引用する
他スキルとの役割分担
/session-log はセッションの意思決定の蒸留(出力側)、/learn は人間の理解の検証(入力側)/qbq は設計前の問いの再定義、/learn は実装後の理解の実証
Scheduling(段階導入)
- Phase 1(現在): 手動発火のみ
- Phase 2: Discovery の自動配線を強化(git log・設計書・ClickUp からお題自動提案)
- Phase 3:
/daily 夜の振り返りへの統合を検討
由来
dotfiles Issue #492。hexhive の /qbq セッション(2026-07-25)で「教師プロンプトの置き場所」を
「開発ループへの理解ゲートの組み込み」に再定義して合意した設計の実装。
理論的背景は Loop Engineering —
生成は安く判断は希少、comprehension rot への防御として人間のチェックポイントを恒久機能にする。
