Evaluate external sources on 3 axes: A (generality), B (no duplication), and C (proven),sources/ and generate an evaluation memo. If A+B+C are all YES, also automatically generate a skillization request text to the template division (CCO).
How to use
「このソースを評価して: https://...」
「sources/に追加できるか判断して」
「このブログ記事をスクリーニングして」
Evaluation flow
Step 1: Understanding the source content
Read the source from a URL or file path. Check items:
- Title, author, organization, publication date
- Main topics and target technologies
- Presence of concrete cases, data, and numerical values
Step 2: A+B+C 3-axis evaluation
A: Generality (applicable to 3 or more divisions)
- YES: Is it a principle or method independent of specific tools and usable across multiple divisions?
- NO: Dedicated to a specific service or only a niche use for a single division
B: No duplication (does it not duplicate existing skills)
Cross-check with existing skills (ls .claude/skills/ or refer to the template division's management file):
- YES: No skill with equivalent functionality exists
- NO:
[skill名]duplicates the concept or method
C: Proven (is there a track record of practical application)
- YES: Concrete cases, numerical values, and implementation examples are explicitly shown
- NO: Theory only, "should-be" arguments only, or no cases
Evaluation priority: C (most important) > A > B
Step 3: Overall judgment
| A | B | C | Judgment |
|---|---|---|---|
| YES | YES | YES | Skillization request → Generate a request text to the template division |
| YES | YES | NO | Local adoption proposal → Keep it as a reference within the reserch division |
| YES | NO | YES | Re-evaluate after duplication check → Proposal to enhance an existing skill |
| NO | — | — | Skip → Insufficient generality |
| — | — | NO | Skip → No proof |
Step 4: Generate an evaluation memo
sources/<topic-slug>-eval-YYYYMMDD.md Output as.
Output format
Evaluation memo (saved under 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行でポイント・注意点]
Skillization request text (additionally generated only when A+B+C are all YES)
【reserch課→template課 スキル化依頼】
ソース: [タイトル](URL)
概要: [1行]
A+B+C評価: 全YES
- A（汎用性）: [対象課] に適用可能
- B（重複なし）: 既存skillとの重複なし
- C（実証済み）: [根拠]
依頼内容: 上記ソースを基にスキルの設計・作成をお願いしたい。
対象課: [想定配布先]
優先度: 低 / 中 / 高
Target source types (in priority order)
- Official documentation — High reliability, update check required
- Technical blogs (practitioners) — Easy to judge as proven
- GitHub README — Implementation examples can be checked
- Conference presentation materials — Rich in cases but beware of freshness
- News articles — Timely but low depth (C judgment is difficult)
Papers are basically out of scope (proven judgment is difficult). Exception: major ML/AI papers for which a GitHub implementation exists.
Freshness check
- Within 2 years: Normal evaluation
- 2-4 years: If "Freshness caution" is explicitly stated and the rating is B or above, adoption is acceptable
- Over 4 years: In fields with rapid technological change, as a rule, skip it. Exceptions may be made for best practices or design principles
Notes
- If the source is behind a paywall or requires login, explicitly state "inaccessible" and withhold evaluation
- If the star count is extremely low (<100) in a GitHub README, be careful about assigning a C rating
- After evaluation, always
sources/confirm with the user the save path to , then write