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/ への保存パスをユーザーに確認してから書き込む