| name | source-eval |
| description | 外部ソース（技術ブログ・公式ドキュメント・GitHub README等）をA+B+C判定で評価し、 sources/配下に評価メモを生成する。スキル化依頼の自動提案まで含む。 使用タイミング: (1) sources/に登録するソースの一次スクリーニング時 (2) 外部ベストプラクティスの スキル化可否を判断したい時 (3) 複数ソースをまとめて評価したい時。 トリガー例: 「このソースを評価して」「sources/に追加できるか確認して」「スキル化できるか判断して」 「このURL/記事の品質をチェックして」
|
source-eval — 外部ソース品質評価メモ生成
外部ソースを A（汎用性）・B（重複なし）・C（実証済み）の3軸で評価し、sources/ に評価メモを生成する。
A+B+C全YES の場合、template課（CCO）へのスキル化依頼文も自動生成する。
使い方
「このソースを評価して: https://...」
「sources/に追加できるか判断して」
「このブログ記事をスクリーニングして」
評価フロー
Step 1: ソース内容の把握
URLまたはファイルパスからソースを読み込む。確認項目:
- タイトル・著者・組織・公開日
- 主なトピックと対象技術
- 具体的な事例・データ・数値の有無
Step 2: A+B+C 3軸評価
A: 汎用性（3課以上に適用可能か）
- YES: 特定ツール非依存・複数課で使える原則・手法か
- NO: 特定サービス専用・単一課のニッチユースのみ
B: 重複なし（既存skillと重複しないか）
既存skillと照合する（ls .claude/skills/ または template課の管理ファイルを参照）:
- YES: 同等機能のskillが存在しない
- NO:
[skill名] と概念・手法が重複する
C: 実証済み（実務適用実績があるか）
- YES: 具体的な事例・数値・実装例が明示されている
- NO: 理論のみ・「べき論」のみ・事例なし
評価優先順位: C（最重要）> A > B
Step 3: 総合判定
| A | B | C | 判定 |
|---|
| YES | YES | YES | スキル化依頼 → template課に依頼文を生成 |
| YES | YES | NO | ローカル導入提案 → reserch課内で参照に留める |
| YES | NO | YES | 重複確認後再評価 → 既存skillの強化提案 |
| NO | — | — | 見送り → 汎用性不足 |
| — | — | NO | 見送り → 実証なし |
Step 4: 評価メモを生成
sources/<topic-slug>-eval-YYYYMMDD.md として出力。
出力フォーマット
評価メモ（sources/配下に保存）
## [ソースタイトル](URL)
- 収集日: YYYY-MM-DD
- 著者/組織: [著者名] / [組織名]
- 公開日: YYYY-MM or 不明
- 種別: 公式ドキュメント / 技術ブログ / GitHub README / カンファレンス資料 / その他
### A（汎用性）: Yes / No
対象課: [課名リスト] または 該当なし
理由: [1行]
### B（重複なし）: Yes / No
類似skill: [skill名] または なし
理由: [1行]
### C（実証済み）: Yes / No
根拠: [事例・数値・実装例を1行で]
### 総合判定: スキル化依頼 / ローカル導入提案 / 重複確認後再評価 / 見送り
### メモ
[1-2行でポイント・注意点]
スキル化依頼文（A+B+C全YESの場合のみ追加生成）
【reserch課→template課 スキル化依頼】
ソース: [タイトル](URL)
概要: [1行]
A+B+C評価: 全YES
- A（汎用性）: [対象課] に適用可能
- B（重複なし）: 既存skillとの重複なし
- C（実証済み）: [根拠]
依頼内容: 上記ソースを基にスキルの設計・作成をお願いしたい。
対象課: [想定配布先]
優先度: 低 / 中 / 高
対象ソース種別（優先度順）
- 公式ドキュメント — 高信頼・更新確認要
- 技術ブログ（実務者） — 実証済み判定しやすい
- GitHub README — 実装例確認可能
- カンファレンス登壇資料 — 事例豊富だが鮮度注意
- ニュース記事 — 速報性あるが深度低い（C判定が難しい）
論文は基本対象外（実証済み判定が困難）。例外: 主要ML/AI論文でGitHub実装が存在する場合。
鮮度チェック
- 2年以内: 通常評価
- 2〜4年: 「鮮度注意」を明記してB以上なら採用可
- 4年超: 技術変化の激しい分野は原則見送り。ベストプラクティスや設計原則なら例外可
注意事項
- ソースが有料壁・ログイン必須の場合は「アクセス不可」を明記し評価を保留
- GitHub README で star数が極端に少ない（<100）場合は C 判定に注意
- 評価後に必ず
sources/ への保存パスをユーザーに確認してから書き込む
