---
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/配下に保存）

```markdown
## [ソースタイトル](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（実証済み）: [根拠]

依頼内容: 上記ソースを基にスキルの設計・作成をお願いしたい。
対象課: [想定配布先]
優先度: 低 / 中 / 高
```

---

## 対象ソース種別（優先度順）

1. **公式ドキュメント** — 高信頼・更新確認要
2. **技術ブログ（実務者）** — 実証済み判定しやすい
3. **GitHub README** — 実装例確認可能
4. **カンファレンス登壇資料** — 事例豊富だが鮮度注意
5. **ニュース記事** — 速報性あるが深度低い（C判定が難しい）

論文は基本対象外（実証済み判定が困難）。例外: 主要ML/AI論文でGitHub実装が存在する場合。

---

## 鮮度チェック

- **2年以内**: 通常評価
- **2〜4年**: 「鮮度注意」を明記してB以上なら採用可
- **4年超**: 技術変化の激しい分野は原則見送り。ベストプラクティスや設計原則なら例外可

---

## 注意事項

- ソースが有料壁・ログイン必須の場合は「アクセス不可」を明記し評価を保留
- GitHub README で star数が極端に少ない（<100）場合は C 判定に注意
- 評価後に必ず `sources/` への保存パスをユーザーに確認してから書き込む