| name | skill-review |
| description | Agent skill (SKILL.md)の品質を評価基準に沿って採点し、観点ごとの判定と修正案をレポートするSkill。 評価のみ行い、ファイルの編集はしない。 ユーザーが「このskillを評価して」「skillをレビューして」「SKILL.mdの品質を見て」のように依頼したら必ずこのSkillを使うこと。 skillの新規作成や編集そのものを依頼された場合は使わない。 |
| allowed-tools | ["Read","Glob","Grep","Bash(find *)","Bash(rg *)","Bash(ls *)","Bash(wc *)"] |
skill-review
目的
Agent skill (SKILL.mdとその付属ファイル)を評価基準に沿って点検し、
観点ごとの判定・根拠・修正案をレポートするSkillです。
評価だけを行い、ファイルの編集はしません。
Arguments
<path>: 評価対象のskillディレクトリまたはSKILL.mdのパス(複数指定可)- 指定が無い場合は、リポジトリ内のskillを探索して全件評価する
例:
/skill-review skills/doc-sync/ → 単一skillを評価/skill-review → リポジトリ内の全skillを評価
評価観点
各観点の詳細な判定基準と良い例・悪い例は references/criteria.mdを参照すること。
評価時は必ずcriteria.mdを読んでから判定する。
観点1〜12の評価前に、Agent Skills仕様への適合性を別枠のゲートとして検証する。
詳細はcriteria.mdの「仕様チェック」を参照すること。
| # | 観点 | 要約 |
|---|
| 1 | 目標と境界 | 目的・やること・やらないことが明確か |
| 2 | description品質 | 発動条件が判断でき、使わないケースも書かれているか |
| 3 | コマンド例の量 | 例が最小限で、形式・順序・境界ケースの明確化に限定されているか |
| 4 | 完了条件 | 何をもって成功とするかが定義されているか |
| 5 | 早期リターン | 前提が満たされない場合に即終了する手順があるか |
| 6 | 自己完結性 | 通常skillは他skillへ言及・委譲していないか。オーケストレーションskillは連結先と順序が明確か |
| 7 | 簡潔さ | 本文が冗長でないか(SKILL.md本文は目安500行以下) |
| 8 | 分割 | 長いテンプレート・例・詳細ドキュメントがreferences/等に分離されているか |
| 9 | 可読性 | 人間がメンテナンスしやすい構成・見出し・表現か |
| 10 | dry-run | 編集を伴うskillの場合のみ: 編集せず差分提示するモードがあるか |
| 11 | 鮮度 | 参照しているコマンド・パス・ファイルが現在も実在するか |
| 12 | クライアント互換性 | 固有設定が対象クライアントの仕様と最小権限に従い、未対応環境で無視可能か |
allowed-toolsなどのクライアント固有frontmatterは、未対応クライアントで無視されること自体は減点しない。
対応クライアントの現行仕様に沿った構文で、skillの実行に必要な最小限の権限だけを指定しているかを判定する。
判定は観点ごとに次の4値とする。
- 合格: 基準を満たしている
- 要改善: 基準を満たしていない(根拠と修正案を必ず添える)
- 該当なし: その観点が対象skillに適用されない(例: 読み取り専用skillに対する観点10)
- 判定保留: 観点は適用されるが、判定に必要な証拠を取得できない(不足している証拠を明記する)
作業手順
1. 対象の列挙
引数のパス、または全件評価モードならリポジトリ内のSKILL.mdを列挙する。
探索手段は問わないが、node_modules/, .git/, バックアップ用ディレクトリは除外する。
指定パスが存在しない、またはSKILL.mdが1件も見つからない場合は、その旨をユーザーに報告して終了する。
descriptionの競合検査用に、評価対象と同じリポジトリまたはskill配置ルートにある他skillのnameとdescriptionも列挙する。
比較範囲を特定できない場合は、競合部分を判定保留にする。
2. 仕様チェック
references/criteria.mdの「仕様チェック」に従い、frontmatterとSKILL.mdの基本構造を検証する。
利用可能なら対象仕様のvalidatorを実行し、利用できなければ同じ要件を手作業で確認する。
- 全要件を満たす: 仕様適合
- 1件でも違反がある: 仕様不適合
仕様不適合でも、判定可能な観点1〜12の評価は続ける。
3. 評価
skillごとに以下を行う。
- SKILL.md本文と付属ファイル(references/等)を読む
- references/criteria.mdの基準に沿って観点1〜12を判定する
- 「要改善」には該当行の引用を根拠として付け、具体的な修正案を書く
- 観点11(鮮度)は、本文中のファイルパス・コマンド名の実在を確認して判定する
- 観点2(description品質)は、列挙した他skillのdescriptionと発動条件を比較する
推測で判定しない。根拠を示せない場合は「要改善」ではなく判定保留として報告する。
4. レポート
skillごとに以下の形式で出力する。
## skills/example-skill/
### 仕様チェック
判定: 仕様適合
| 観点 | 判定 | 根拠 |
| --- | --- | --- |
| 1. 目標と境界 | 合格 | 「目的」「やらないこと」の両セクションあり |
| 2. description品質 | 要改善 | トリガーフレーズが無い |
| 11. 鮮度 | 判定保留 | コマンドの実在を確認できる環境が無い |
| ... | ... | ... |
### 要改善の詳細
- 観点2: descriptionに発動条件が無い
現状: "PRを作成するSkill。"
修正案: "ユーザーが「PR作って」「pull request作成」と依頼したら使うこと" を追記
仕様不適合の場合は、違反した要件、根拠、修正案を「仕様チェック」に列挙する。
複数skillを評価した場合は、最後に全体サマリー(skill数、仕様不適合数、判定保留数、要改善の多い観点トップ3)を付ける。
原則
- 編集しない: このSkillは評価とレポートまで。修正の適用はユーザーの別途依頼を待つ。
- 好みを混ぜない: 文体や語彙の好みは指摘しない。基準に照らして判定できる事項のみ扱う。
- 基準外の重大問題は報告する: 12観点に該当しなくても、明らかな誤り(壊れたリンク、矛盾した手順)を見つけたら「その他」として報告する。
