--- description: "セッションから再利用可能なパターンを抽出し、保存前に品質を自己評価し、適切な保存場所(グローバル vs プロジェクト)を決定します。" --- # /learn-eval - 抽出、評価、そして保存 `/learn`を拡張し、スキルファイルを書く前に品質ゲート、保存場所の決定、ナレッジ配置の認識を追加します。 ## 抽出対象 以下を探す: 1. **エラー解決パターン** — 根本原因 + 修正 + 再利用性 2. **デバッグテクニック** — 非自明なステップ、ツールの組み合わせ 3. **ワークアラウンド** — ライブラリの癖、APIの制限、バージョン固有の修正 4. **プロジェクト固有のパターン** — 規約、アーキテクチャの決定、統合パターン ## プロセス 1. セッションから抽出可能なパターンをレビュー 2. 最も価値の高い/再利用可能なインサイトを特定 3. **保存場所の決定:** - 質問: 「このパターンは別のプロジェクトでも役立つか?」 - **グローバル** (`~/.claude/skills/learned/`): 2つ以上のプロジェクトで使える汎用パターン(bash互換性、LLM APIの動作、デバッグテクニックなど) - **プロジェクト** (現在のプロジェクトの`.claude/skills/learned/`): プロジェクト固有のナレッジ(特定の設定ファイルの癖、プロジェクト固有のアーキテクチャ決定など) - 迷ったらグローバルを選択(グローバル → プロジェクトへの移動はその逆より容易) 4. 以下の形式でスキルファイルのドラフトを作成: ```markdown --- name: pattern-name description: "130文字以内" user-invocable: false origin: auto-extracted --- # [説明的なパターン名] **抽出日:** [日付] **コンテキスト:** [これが適用される場面の簡潔な説明] ## 問題 [このパターンが解決する問題 - 具体的に] ## 解決策 [パターン/テクニック/ワークアラウンド - コード例付き] ## 使用するタイミング [トリガー条件] ``` 5. **品質ゲート — チェックリスト + 総合判定** ### 5a. 必須チェックリスト(実際にファイルを読んで検証) ドラフトを評価する前に、以下の**すべて**を実行: - [ ] `~/.claude/skills/`および関連プロジェクトの`.claude/skills/`ファイルをキーワードでgrepし、内容の重複を確認 - [ ] MEMORY.md(プロジェクトとグローバル両方)の重複を確認 - [ ] 既存スキルへの追記で十分かを検討 - [ ] これが再利用可能なパターンであり、一回限りの修正でないことを確認 ### 5b. 総合判定 チェックリスト結果とドラフト品質を統合し、以下の**いずれか1つ**を選択: | 判定 | 意味 | 次のアクション | |------|------|--------------| | **Save** | ユニーク、具体的、適切にスコープされている | ステップ 6に進む | | **Improve then Save** | 価値はあるが改善が必要 | 改善点をリスト → 修正 → 再評価(1回) | | **Absorb into [X]** | 既存スキルに追記すべき | 対象スキルと追加内容を表示 → ステップ 6 | | **Drop** | 些末、冗長、または抽象的すぎる | 理由を説明して終了 | **ガイドライン指標**(判定を通知するが、スコアリングはしない): - **具体性と実行可能性**: すぐに使えるコード例やコマンドが含まれている - **スコープの適合性**: 名前、トリガー条件、内容が整合し、単一のパターンに焦点を当てている - **ユニーク性**: 既存スキルでカバーされていない価値を提供(チェックリスト結果から判断) - **再利用性**: 将来のセッションで現実的なトリガーシナリオが存在 6. **判定別の確認フロー** - **Improve then Save**: 必要な改善 + 修正ドラフト + 更新されたチェックリスト/判定を1回の再評価後に提示。修正後の判定が**Save**ならユーザー確認後に保存、それ以外は新しい判定に従う - **Save**: 保存パス + チェックリスト結果 + 1行の判定理由 + 完全なドラフトを提示 → ユーザー確認後に保存 - **Absorb into [X]**: 対象パス + 追加内容(diff形式)+ チェックリスト結果 + 判定理由を提示 → ユーザー確認後に追記 - **Drop**: チェックリスト結果 + 理由のみを表示(確認不要) 7. 決定された場所に保存/追記 ## ステップ 5の出力形式 ``` ### チェックリスト - [x] skills/ grep: 重複なし(または: 重複検出 → 詳細) - [x] MEMORY.md: 重複なし(または: 重複検出 → 詳細) - [x] 既存スキル追記: 新規ファイルが適切(または: [X]に追記すべき) - [x] 再利用性: 確認済み(または: 一回限り → Drop) ### 判定: Save / Improve then Save / Absorb into [X] / Drop **理由:** (判定を説明する1-2文) ``` ## 設計の根拠 このバージョンは、以前の5ディメンション数値スコアリングルーブリック(Specificity、Actionability、Scope Fit、Non-redundancy、Coverageを1-5でスコアリング)をチェックリストベースの総合判定システムに置き換えています。最新のフロンティアモデル(Opus 4.6+)は強力なコンテキスト判断能力を持っており、豊かな定性的シグナルを数値スコアに強制すると、ニュアンスが失われ、誤解を招く合計を生み出す可能性があります。総合的なアプローチにより、モデルがすべての要因を自然に重み付けし、明示的なチェックリストが重要なチェックのスキップを防ぎながら、より正確な保存/破棄の決定を生み出します。 ## 注意事項 - 些末な修正を抽出しない(タイプミス、単純な構文エラー) - 一回限りの問題を抽出しない(特定のAPI障害など) - 将来のセッションで時間を節約するパターンに焦点を当てる - スキルは焦点を絞る — 1スキル1パターン - 判定がAbsorbの場合、新しいファイルを作成せず既存スキルに追記