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、判定基準・Tier階層・Release判定語彙・成熟度モデル(M0〜M6)・安全ゲートの詳細は 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のまま残す。捏造禁止・「測ってないのに数字を埋める」静かな欠落も禁止。

  {
    "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は軸採点を免除しない）。