GzmSTAR/master-learning-skill

Master Learning（マスターラーニング）

Master Learningは、Codexが熟練者として振る舞う前に、真剣な見習いのように振る舞わせます。タスクを計画したりコードを変更したりする前に、ドメイン、エコシステム、ソース資料、実装パターンを学習するために使用します。

コアルール

タスクが、Codexが現在のソースに基づいて確立していないドメイン知識に依存している場合、実装に直接飛びつかないでください。最初に学習ブリーフ（Learning Brief）を作成します。次に、そのブリーフを計画、設計、テスト、実装の基礎として使用します。

トリガー判断

以下のいずれかに該当する場合、このスキルを使用します：

• ユーザーが馴染みのないドメイン、フレームワーク、研究分野、プロトコル、規格、ハードウェア/ソフトウェアエコシステムでの構築を依頼した場合。
• タスクに「調査」「まず学習」「ベストプラクティス」「最新」「論文」「GitHub」「例」「ベンチマーク」「規格」またはそれらに相当する意図が任意の言語で含まれている場合。
• 誤った前提が実装作業の無駄、安全でない設計、低い学術的/工学的品質、互換性のないAPIを引き起こす可能性がある場合。
• タスクがライブラリの選択、論文の再現、高スターリポジトリの適応、公式ドキュメントの参照、編集前のローカルプロジェクト規約の理解を含む場合。

些細な編集、ローカルエビデンスが明確な直接的なバグ修正、フォーマットのみの作業、またはユーザーが調査をしないよう明示的に指示したタスクでは、このスキルを使用しないでください。

ワークフロー

1. 学習目標を設定する。 プロジェクトの目的、対象読者、ターゲット環境、成功基準、そして解決すべき未知の事項を再定義します。
2. 調査の深さを選択する。 タスクが高リスク、新規性、規制関連、論文駆動型、またはソース間で矛盾がある場合を除き、scoutから始めます。その場合はdeepを使用します。メンテナンスタスクでドメインは既知だが依存関係が変更されている可能性がある場合は、refreshを使用します。
3. 優先順位に従ってソースを収集する。 まず公式ドキュメントとローカルリポジトリの真実を優先し、次に規格/仕様、論文、高品質のGitHubリポジトリ、例/テスト/Issue、信頼できるエンジニアリング記事を収集します。
4. トリビアではなくパターンを学習する。 ドメインの概念、データ/制御フロー、API契約、一般的なアーキテクチャ、エッジケース、障害モード、テストアプローチ、アンチパターンを抽出します。
5. ソースカバレッジを監査する。 ギャップを明確にマークします。公式ソース、コード例、現在のソースが存在しない場合は、結論を暫定的とラベル付けします。
6. 学習ブリーフを作成する。 実用的であることを保ちます：何を構築するか、何を避けるか、何を検証するか、そしてどのような前提が残っているか。
7. 根拠を得てから進める。 学習ブリーフを使用して実装計画またはコード変更を行います。ブリーフが未解決の重大なリスクを明らかにした場合は、実装前にさらに質問または調査します。

SkillOptスタイルの検証ゲート

このスキルは、SkillOptにヒントを得たループ（タスクの展開、失敗の振り返り、範囲を限定した編集の適用、検証が改善された場合のみ候補を維持）によって最適化されています。タスク実行時も同じ規律を使用します：

• 学習ブリーフを装飾的なレポートではなく、現在のプロジェクトの訓練可能な手順として扱います。
• エビデンスが変更された場合、範囲を限定した更新を行います：次の決定を改善するために必要なルールのみを追加、削除、または置き換えます。
• 拒否された前提をブリーフに保持し、後で再導入されないようにします。
• 実装前に検証ゲートを実行します：ソースカバレッジ、ローカルコードの適合性、リスクレビュー、受入基準。
• 検証ゲートに失敗した場合、不確実性の中でコーディングするのではなく、ブリーフを改善します。

訓練規律

長期プロジェクトやスキルの反復改善中に、以下のSkillOptスタイルの制御を使用します：

• テキスト学習率： 毎回の失敗後に完全な書き換えではなく、1つか2つの正確なルール編集を優先します。
• 拒否された前提バッファ： 破棄された前提を記録します。例：古いAPI、放棄されたリポジトリ、互換性のないライセンス、弱い論文、ユーザーのランタイムと一致しない例。
• ホールドアウト検証： 新しいルールを信頼する前に、更新されたブリーフを異なるシナリオでテストします。
• 低速更新： 同じ失敗が複数のタスクにわたって現れた場合、それを一回限りのメモからSKILL.mdまたは参照ファイルに昇格させます。
• 回帰チェック： スキルが依然として些細なタスクをスキップし、直接修正に過剰に調査しないことを確認します。

シナリオ処理ルール

• 最新フレームワーク/APIタスクの場合： コードを推奨する前に、公式ドキュメント、リリースノート、移行ノート、ローカルの依存関係バージョンを確認します。
• 論文再現タスクの場合： 論文の方法、前提、評価設定、コード/データの可用性、ユーザーの環境との不一致を読み取ります。
• GitHub適応タスクの場合： ライセンス、最近の活動、例、テスト、Issue、依存関係の健全性、再利用が許可されているか、学習のみが適切かを検査します。
• ローカルプロジェクトタスクの場合： 外部ソースの前に、マニフェスト、設定、テスト、ドキュメント、既存の規約を検査します。
• 低リスクの直接修正の場合： 明示的に深い調査をスキップし、なぜスキルが必要ないかを述べます。
• ネットワーク劣化タスクの場合： 欠落した外部検証をラベル付けし、ローカルエビデンスのみで続行するか、必要な場合は許可/入力を求めます。

出力契約

すべての学習ブリーフには以下を含める必要があります：

• Task：学習目標、ターゲット環境、成功基準、調査の深さ、信頼度。
• Sources：URL/パス、種類、日付/最新性（利用可能な場合）、信頼性、主な用途。
• Domain Model：主要な概念、オブジェクト、用語、関係性。
• Local Code Lessons：プロジェクト構造、規約、制約、関連ファイル（ローカルコードが存在する場合）。
• GitHub/Code Lessons：レビューしたリポジトリ、有用なパターン、ライセンス/再利用ノート、Issue。
• Paper/Standard Lessons：方法、要件、制限、前提。
• Implementation Patterns：アーキテクチャ、API/契約、データ/制御フロー、テスト、運用上の制約。
• Risks and Anti-Patterns：エッジケース、弱い前提、避けるべきこと。
• Recommendation：推奨アプローチ、受入基準、次のステップ。
• Open Questions：未解決の決定または欠落したエビデンス。

構造化されたMarkdownアーティファクトが有用な場合は、references/learning-brief-template.mdを使用します。

バンドルリソース

以下のファイルは関連がある場合にのみ読み取ります：

• references/research-depths.md：scout、deep、refreshを選択します。
• references/source-quality-rubric.md：ソースをスコアリングし比較します。
• references/github-mining.md：スターだけで騙されずにGitHubリポジトリを検査します。
• references/paper-learning.md：論文をエンジニアリング制約に変換します。
• references/skillopt-training.md：このスキルに使用されるSkillOptにヒントを得た最適化プロトコル。
• references/learning-brief-template.md：一貫したブリーフを作成します。
• references/anti-patterns.md：一般的な障害モードを回避します。
• training/benchmark-scenarios.json：このスキルの回帰テストに使用されるホールドアウトシナリオセット。

スクリプトはオプションのヘルパーです：

• scripts/create_learning_brief.py：学習ブリーフのスキャフォールドを作成します。
• scripts/github_scan.py：GitHubリポジトリを検索し候補をエクスポートします。
• scripts/paper_scan.py：CrossRef、arXiv、PubMedの公開APIを検索します。
• scripts/source_audit.py：ソースカバレッジをチェックし、弱い根拠について警告します。
• scripts/merge_learning_brief.py：スキャン出力をブリーフのドラフトにマージします。
• scripts/skillopt_train.py：ローカルのSkillOptスタイルのシナリオ訓練と検証ベンチマークを実行します。

完全性ルール

• ソースの発見結果、引用、リポジトリの内容、APIの振る舞いを決して捏造しないでください。
• ネットワークアクセスが失敗した場合は、調査が劣化したことと、何がチェックされなかったかを説明します。
• サマリーよりも一次情報源を優先します。
• 「最新」の主張については、記憶に頼る前に現在のドキュメントまたはリリースを確認します。
• 1つのブログ記事、1つのStack Overflowの回答、または1つのREADMEを、高リスクの意思決定には不十分として扱います。
• ソース間で矛盾がある場合は、矛盾を保持し、最も安全な検証可能な経路を推奨します。