# Skill Evaluator

> Claude Codeスキル（SKILL.md）を静的審査6軸＋動的計測（L0/L2/L3/L5）でALWAYS評価し、scorecard.md・fixes.md・skill-eval.jsonを対象スキルの.eval/配下に出力する。引用なき採点は必ず禁止し、対象スキル本体は絶対に書き換えない（評価と提案のみ）。「スキル評価して」「このスキル大丈夫？」「skill-evaluator」「スキル診断」「fleet監査」「全スキル一括評価」「スキルレビューして」「このスキルの品質チェック」で必ず発動する。NOT for: スキルの新規作成・構造修正（→teru-skill-creator/skill-harness/skill-creator）、ハーネス全体（CLAUDE.md/hooks/permissions含む）の診断（→review-harness）。

- Skill: `naoterumaker/skill-evaluator` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add naoterumaker/skill-evaluator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/naoterumaker/skill-evaluator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: naoterumaker (https://skillmd.com/u/naoterumaker)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/naoterumaker/skill-evaluator

---


# skill-evaluator

Claude Codeスキル1本、または`~/.claude/skills/`配下の全スキルを評価する。**評価と改善提案のみを行い、対象スキルを書き換えない。**

## Purpose

スキルは書いた本人には妥当に見える。このスキルは「そもそもSkillであるべきか」「境界は1つの成果契約か」「モデルが知らない差分だけが書かれているか」「脆弱箇所だけ厳密か」「記述が層別されているか」「成功条件は観測可能か」を、本文からの引用を根拠に**4値判定（PASS/CONCERN/BLOCKER/UNKNOWN）＋証拠水準（E0〜E6）**で判定し、機械検査（L0）・発火設計（L2）・実行結果（L3）・使用実績（L5）で裏取りする。1〜5点の点数は同一スキルの改訂前後比較専用の副記であり、絶対値やスキル間順位づけには使わない（Invariant 5）。

v2.0は`~/ManabiLibrary/documents/Agent_Skill_Evaluation_Manual_V2.md`を一次資料とする「両建て方式」（4値判定＋証拠水準を主出力、点数は副記）。設計根拠と各基準の出典は [references/research-basis.md](references/research-basis.md)、判定基準・Tier階層・Release判定語彙・成熟度モデル(M0〜M6)・安全ゲートの詳細は [references/rubric.md](references/rubric.md) を参照。

## Use when

- 「このスキル評価して」「スキル診断して」「品質チェックして」と特定のスキルを指して依頼されたとき
- 新規スキル作成・大幅改修の直後、リリース前の品質ゲートとして
- 「fleet監査」「全スキルまとめて見て」など`~/.claude/skills/`全体の棚卸しを求められたとき

## Do not use when

- スキルをこれから作る・構造を直す（→ `teru-skill-creator` / `skill-harness` / `skill-creator`）
- CLAUDE.md・hooks・permissions・memory等ハーネス全体の診断（→ `review-harness`）
- 評価ではなく単にスキルの使い方を知りたいだけ（→ 対象スキルのSKILL.mdを直接読む）

## Contract

**Inputs**:
- 単体評価: 評価対象スキルのディレクトリパス（例 `~/.claude/skills/ai-video-edit-workflow`）
- fleet監査: スキル群のルートディレクトリ（既定 `~/.claude/skills/`）
- 任意: 対象を「配布用（distribution）」として審査するか「ローカル運用」として審査するかの指定（既定ローカル）

**Outputs**（対象スキルディレクトリ配下の `.eval/` に保存。fleet監査は `~/.claude/skills/.audit/fleet-report.md`）:
- `scorecard.md` — マニュアル8.1準拠の結果カード形式: **評価契約（Layer 0）→ハードブロッカー→6軸4値判定（本文引用＋証拠水準E0〜E6付き）→点数副記（改訂前後比較専用）→Tier→Release判定（APPROVE/APPROVE WITH CONDITIONS/REVISE/REJECT/RETIRE）→成熟度M0〜M6**の順で書く
- `fixes.md` — 優先度付き改善案（`[blocker]/[high]/[med]/[low]`、そのまま実行できる具体性、description書き換え案は実文面）
- `skill-eval.json` — 機械可読サマリー。基本キーは`skill/grade/score/blockers/axes/l0_pass/eval_count/last_fired/evaluated_at`（v1.0互換）。v1.1で`vector.{routing,uplift,reliability,efficiency}`を追加。v2.0で以下をさらに追加する。**未測定の項目は`null`のまま残す。捏造禁止・「測ってないのに数字を埋める」静かな欠落も禁止。**
  ```json
  {
    "skill": "...", "grade": "...", "score": 0.0, "blockers": [], "axes": {"...": {}},
    "l0_pass": true, "eval_count": 0, "last_fired": null, "evaluated_at": "...",
    "vector": { "routing": null, "uplift": null, "reliability": null, "efficiency": null },
    "verdicts": { "existence": "PASS", "boundary": "CONCERN", "knowledge_delta": "PASS",
                  "control": "PASS", "dependency": "CONCERN", "grounding": "CONCERN" },
    "evidence_level": "E1",
    "decision": "APPROVE_WITH_CONDITIONS",
    "tier": "A",
    "maturity": "M2",
    "contract": { "model": null, "harness": "claude-code", "baseline": "none",
                  "trials": 0, "verified_at": "..." }
  }
  ```
  測定した場合のフィールド形（v1.1既出）: `routing: {"precision":0.94,"recall":0.87,"f1":0.90,"trials":3}` / `uplift: {"pass_without":0.58,"pass_with":0.76,"delta_pp":18,"repair_rate":0.24,"regression_rate":0.06}` / `reliability: {"pass_at_k":0.92,"pass_all_k":0.54,"k":5}` / `efficiency: {"token_delta_pct":11,"time_delta_pct":-4}`。`verdicts`の値は`PASS/CONCERN/BLOCKER/UNKNOWN`のいずれか。`decision`は`APPROVE/APPROVE_WITH_CONDITIONS/REVISE/REJECT/RETIRE`のいずれか。`tier`は`A/B/C`（`references/rubric.md`のTier階層）。`maturity`は`M0`〜`M6`。

**Success criteria**:
- 6軸すべてに、スキル本文からの直接引用を伴う根拠がある（引用なき採点は不合格＝このスキル自体のInvariant違反）
- ハードブロッカーの有無を明示的に判定し、該当する場合は等級上限Dを適用している
- L0はスクリプト実行結果に基づく（目視のみでpass/failを書かない）
- fixesの各項目が「そのまま実行可能」（該当箇所のファイル名・行・書き換え後の文面を含む）

## Invariants

これらは評価対象や状況によらず常に守る（`references/rubric.md`にある採点基準そのものより上位のルール）。

1. **対象スキルを書き換えない。** 評価と提案のみ行う。Edit/Writeは`.eval/`配下と`fleet-report.md`にのみ許可される。
2. **引用なき採点をしない。** 6軸それぞれの点数には、対象SKILL.md（または同梱ファイル）からの直接引用を最低1つ付ける。引用できない場合は「根拠不明」として1点扱いにする。
3. **ブロッカーを隠さない。** ハードブロッカー該当時は必ずscorecardの先頭に明示し、等級を強制的にD以下にする。他の軸が高得点でも上書きしない。
4. **L0はスクリプトの出力そのものを転記する。** `scripts/l0_lint.py`を実行せずに「おそらく通る」と書かない。
5. **静的軸点数を絶対値として扱わない・異なるスキル間の順位づけに使わない。** 単独LLM judge・校正（calibration）なし・baseline比較なしの静的採点は「校正済み測定」ではなく「設計レビュー上の方向的指標」に過ぎない。点数の正しい用途は (a) 同一スキルの改訂前後比較 (b) ブロッカー・欠落箇所の特定、の2つのみ。scorecardには必ずこの注記を含める（`references/rubric.md`の等級決定セクション参照）。
6. **重大な安全違反・重大な退行は他の高評価で相殺しない（独立ハードゲート）。** `references/rubric.md`「安全ゲート」節の該当項目、または用途別ハードゲートの`RegressionRate`超過は、他の5軸が`PASS`でも単独でRelease判定を`REVISE`以下に固定する。
7. **結論には必ず証拠水準E0〜E6を付ける。** `references/rubric.md`の証拠強度表を参照し、「構造上は健全（E1）」のように書く。**E1（静的検査・6軸レビュー）の結論を「実証済み」「効果がある」と書かない。** `references/rubric.md`「書いてはいけない結論」の7項目を出力前に確認する。

## Decision policy

- 存在妥当性が閾値未満（Skillであるべきでない）と判定した場合、他の5軸を採点しても等級はDを超えない。scorecardの冒頭で「配置判断: Script/Hook/MCP/Subagent/CLAUDE.mdのどれが適切か」を明記する。
- ハードブロッカーが1つでもあれば等級上限D（他が満点でも）。`references/rubric.md`のブロッカー一覧に該当するかをまず機械的にチェックしてから6軸採点に入る。
- L3（eval実行）が同梱されていない場合、それ自体を接地妥当性の減点理由にする（evalなし=接地妥当性は3点以下が上限）。
- L5計測ログ（`.usage.jsonl`）が存在しない場合、「不明・計装推奨」と書く。0件や不明を勝手に「使われていない」と断定しない（計装の不在と不使用は別事実）。

## Procedure

### A. 単体評価

0. **Layer 0（評価契約の固定）**: skill版（git-sha相当かディレクトリの最終更新）・model・harness・利用可能tools・baseline種別（no-skill/previous-version/alternative-structure、既定はno-skill）・試行数・検証日を確定し、scorecard冒頭と`skill-eval.json`の`contract`キーに記録する。以降の手順はすべてこの契約の下で行う。実行評価（手順6）まで求められていない場合、`contract.trials`は0、`contract.baseline`は`"none"`のままでよい。
1. 対象ディレクトリの `SKILL.md` と同梱ファイル（`scripts/`, `references/`, `assets/`, `evals/`）を全て読む。
2. `scripts/l0_lint.py <skill_dir> --mode local`（配布用スキルなら `--mode distribution`）を実行し、結果を保存する。安全ゲート（`references/rubric.md`「安全ゲート」）まで確認する場合は`--security`を付けて再実行し、警告一覧をscorecardに転記する（警告はPASS/FAILを変えない。目的の意味的一致は人間/LLMレビューで別途判断する）。
3. `references/rubric.md` のハードブロッカー一覧と照合する。該当があれば理由をSKILL.md本文の引用付きで記録し、該当軸を`BLOCKER`に固定する。
4. 6軸（存在妥当性・境界妥当性・知識差分妥当性・統制妥当性・依存妥当性・接地妥当性）を`references/rubric.md`の基準で**PASS/CONCERN/BLOCKER/UNKNOWNの4値**で判定し、各判定に本文引用と証拠水準（E0〜E6）、CONCERN/UNKNOWNなら「次に必要な実験」を付ける。改訂前後比較用に1〜5点の副記を併記してよい。
5. L2: descriptionの様式を指示的/受動的/混在で判定し、name+description文字数を記録する。trigger精度の実測まで求められた場合は、should-trigger 20件＋near-missのshould-not-trigger 20件を各3試行以上実行し、Precision/Recall/F1/FPRを算出して`vector.routing`に格納する（agentskills.io公式ガイドがこの20+20×3試行・train/validation約60/40設計を示している）。実測が求められていない、または実行できない場合は様式分類のみにとどめ`vector.routing`は`null`のままにする。
6. L3: `evals/`配下のeval定義有無と、あれば内容の妥当性（query + expected_behavior の組が具体的か）を確認する。実行まで求められている場合は以下の方式で測定する:
   - 同タスク・同モデル・同ハーネスでスキル有無のwith/without比較を**最低5試行**行う
   - 対応結果を四象限（`references/rubric.md`参照）に分類し、ΔPassRateだけでなく**RepairRate**（withoutで失敗しwithで成功）と**RegressionRate**（withoutで成功しwithで失敗）を独立に集計する。平均だけを見ると退行が隠れる
   - **指示遵守（instruction following）と目的達成（goal completion）を分離して採点する**。手順どおりでも成果が改善しない、または成果は良くても必須手順に反する、をそれぞれ検出する
   - 能力（k回中1回でも成功）を測るなら**pass@k**、信頼性（k回全部成功）を測るなら**pass^k**を区別して報告する
   - 結果を`vector.uplift`（pass_without/pass_with/delta_pp/repair_rate/regression_rate）と`vector.reliability`（pass_at_k/pass_all_k/k）に格納する。用途別の優先ゲート（読み取り系/生成系/破壊的操作系/fleet系/自動生成系）とTier別必須項目は`references/rubric.md`の「用途別ハードゲート」「Tier A/B/C」を参照する
   - 実行まで求められていない場合は`vector.uplift`・`vector.reliability`を`null`のままにし、その旨をscorecardに明記する（測ってもいないのに数字を埋めない）
7. L5: `.usage.jsonl`等の計装ログを探す。なければ「不明・計装推奨」。あれば直近30日の発火数を集計する。
8. **Tierを判定する**（`references/rubric.md`「Tier A/B/C」）。Tier B以上は安全ゲート（手順2の`--security`結果＋人間/LLMレビュー）を確認し、重大な安全違反・`RegressionRate`超過があれば他の評価に関わらずRelease判定を`REVISE`以下に固定する（Invariant 6）。
9. **Release判定**（`APPROVE`/`APPROVE WITH CONDITIONS`/`REVISE`/`REJECT`/`RETIRE`）と**成熟度（M0〜M6）**を`references/rubric.md`の基準で決定する。等級S〜D（副記）は軸平均から算出してよいが、Release判定を代替しない。`scorecard.md` / `fixes.md` / `skill-eval.json` を対象スキルの `.eval/` に書く。

### B. fleet監査

1. `scripts/l0_lint.py --fleet <skills_root> --mode local --json` を実行する。
2. skill_count / fail_count / budget合計と超過状況 / description様式内訳を取得する。
3. 各スキルについて `.eval/skill-eval.json` があれば読み込み等級分布を集計する（なければ「未評価」としてカウント）。
4. 使用実績ログがあれば未発火リストを作る。なければ「不明・計装推奨」と明記する。
5. name/description文字列の類似度が高い組を重複候補として列挙する（簡易: 正規化した語のJaccard類似度が高いペア）。
6. `~/.claude/skills/.audit/fleet-report.md` に等級分布・バジェット状況・様式内訳・eval保有率・重複候補・（あれば）未発火リストをまとめる。カタログ評価（多クラス混同行列・coverage gap・portfolio分類、`references/rubric.md`「カタログ評価」）は要求された場合のみ追加で実施する。

## Validation

- 単体評価後: `.eval/scorecard.md` に評価契約（Layer 0）・6軸すべての4値判定（引用＋証拠水準付き）・静的点数の位置づけ注記（Invariant 5）・Tier・Release判定があるか、`.eval/skill-eval.json` が`skill/grade/score/blockers/axes/l0_pass/eval_count/last_fired/evaluated_at`＋`vector.{routing,uplift,reliability,efficiency}`＋`verdicts/evidence_level/decision/tier/maturity/contract`の全キーを持つか（未測定分は`null`で存在すること）を自己チェックする。
- fleet監査後: `fleet-report.md`のバジェット合計がl0_lint.pyの`--json`出力の`total_budget_chars`と一致するか照合する。

## Gotchas

- 対象スキルのSKILL.mdがフロントマターの閉じ`---`を欠いていることがある。`l0_lint.py`はこの場合パースエラーを返す（クラッシュしない）。エラーをそのまま採点理由に転記する。
- `description`はYAMLの折り返し記法（`>`や引用符）で書かれることがある。文字数はスクリプトの出力値を正とし、目視で数えない。
- 配布用（distributionを名乗る）スキルにローカル拡張フィールド（`model`, `context`, `agent`等）が残っていることがある。これは配布妥当性の減点対象だが、ローカル運用スキルには適用しない（`--mode`の選択を誤らない）。
- evalファイルの`query`が発火文言のテストであり、`expected_behavior`が動作結果のテストであることを混同しない。両方揃って初めてL3として機能する。
- `l0_lint.py --security`は正規表現によるテキストパターン検査であり、パターンそのものを説明・定義しているドキュメントやスクリプト自身のソースを誤検知することがある（自己適用時に確認済み）。警告は「読むべき箇所のヒント」であり、機械的な有罪判定として転記しない。
- 結論を書く前に`references/rubric.md`「書いてはいけない結論」の7項目と照合する。E1（静的）の結果を根拠に「効果がある」「優秀」と書いていないか必ず確認する。

## Examples

**OK**: 「`video-thumbnail-gen`を評価して」→ 単体評価Aフローを実行。SKILL.md該当行「※本番用テンプレートは購入者特典サイトで配布」を引用し、未同梱リソース前提の手順としてハードブロッカー該当・境界妥当性を`BLOCKER`（E1）に固定、加えてevalディレクトリ不在を接地妥当性`CONCERN`（E1、eval 0件のため上限CONCERN）の根拠として引用付きで記録。等級上限D、Release判定は`REJECT`（未同梱リソース前提のまま承認できない）。

**NG**: 「たぶん問題ないと思います」で終える採点。本文引用なし・スクリプト未実行のため、このスキル自身のInvariant 2/4違反。

**境界例**: 対象スキルにscripts/はあるがreferences/がなくSKILL.mdが480行の場合、L0は行数上ではPASSだが「進行的開示を使わず全て本文に詰め込んでいる」ことを知識差分妥当性/統制妥当性の軸でコメントする（L0のPASSは軸採点を免除しない）。