メニュー
Agent skill (SKILL.md)の品質を評価基準に沿って採点し、観点ごとの判定と修正案をレポートするSkill。 評価のみ行い、ファイルの編集はしない。 ユーザーが「このskillを評価して」「skillをレビューして」「SKILL.mdの品質を見て」のように依頼したら必ずこのSkillを使うこと。 skillの新規作成や編集そのものを依頼された場合は使わない。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
GitHubのPull Request(PR)のコードレビューを行うSkill。worktreeを作成してソースコード全体を読みながらFinder SubAgentで指摘候補を発見し、Verifier SubAgentで検証する。レビューをレポートとインラインコメントで投稿する。self reviewにも対応する。 ユーザーが「このPRをレビューして」のように依頼したら使うこと。
GitHub issueを起点に「調査 → worktree作成 → 実装 → PR作成」を一気通貫で実行するSkill。実装はSubAgentに委譲し、commitとPR作成はgit-commit・github-pr-create skillに連結して実行する。「#N をsubagentで解決して」「実装をsubagentに任せてissueからPRまで」のような依頼に使う。
Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。 ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。
計画や設計について、意思決定のあらゆる分岐点が解消されるまで、徹底的に質問を繰り返してください。ユーザーが計画の改善・詳細化・最適化を望んでいる場合や、設計について厳しく問い詰めてほしいと言われたとき、あるいは「計画(Plan)を詰めて」、「計画(Plan)を改善して」と要望があった際にこの手順を使用してください。
weztermのpane・tab・windowを `wezterm cli` で操作するskill。paneの分割・フォーカス移動・リサイズ・zoom・close、 tab/windowの作成・切替・リネーム、paneの表示内容の読み取り、paneへのコマンド送信と実行結果の確認を行う。 ユーザーが「weztermのpaneを分割して」「weztermの別paneでコマンドを実行して」のように、weztermと明示して依頼したときだけ使うこと。 ユーザーはtmuxも併用しているため、「paneを分割して」のようにweztermと明示されていないpane/tab操作の依頼では使わない (どちらを指すかユーザーに確認する)。 tmuxの操作、およびwezterm自体の設定 (wezterm.luaやkeybinding) の変更にも使わない。
Codexに作業を委譲して結果を得るSkill。ユーザーが「Codexにやらせて」「Codexに作業を任せて」と明示的に依頼したときのみ使用する。エージェント自身の判断で自発的に使わないこと。自分自身がCodexの場合は使わない。
SOC 職業分類に基づく
| 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 *)"] |
Agent skill (SKILL.mdとその付属ファイル)を評価基準に沿って点検し、 観点ごとの判定・根拠・修正案をレポートするSkillです。 評価だけを行い、ファイルの編集はしません。
<path>: 評価対象のskillディレクトリまたはSKILL.mdのパス(複数指定可)例:
/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.mdを列挙する。
探索手段は問わないが、node_modules/, .git/, バックアップ用ディレクトリは除外する。
指定パスが存在しない、またはSKILL.mdが1件も見つからない場合は、その旨をユーザーに報告して終了する。
descriptionの競合検査用に、評価対象と同じリポジトリまたはskill配置ルートにある他skillのnameとdescriptionも列挙する。
比較範囲を特定できない場合は、競合部分を判定保留にする。
references/criteria.mdの「仕様チェック」に従い、frontmatterとSKILL.mdの基本構造を検証する。 利用可能なら対象仕様のvalidatorを実行し、利用できなければ同じ要件を手作業で確認する。
仕様不適合でも、判定可能な観点1〜12の評価は続ける。
skillごとに以下を行う。
推測で判定しない。根拠を示せない場合は「要改善」ではなく判定保留として報告する。
skillごとに以下の形式で出力する。
## skills/example-skill/
### 仕様チェック
判定: 仕様適合
| 観点 | 判定 | 根拠 |
| --- | --- | --- |
| 1. 目標と境界 | 合格 | 「目的」「やらないこと」の両セクションあり |
| 2. description品質 | 要改善 | トリガーフレーズが無い |
| 11. 鮮度 | 判定保留 | コマンドの実在を確認できる環境が無い |
| ... | ... | ... |
### 要改善の詳細
- 観点2: descriptionに発動条件が無い
現状: "PRを作成するSkill。"
修正案: "ユーザーが「PR作って」「pull request作成」と依頼したら使うこと" を追記
仕様不適合の場合は、違反した要件、根拠、修正案を「仕様チェック」に列挙する。 複数skillを評価した場合は、最後に全体サマリー(skill数、仕様不適合数、判定保留数、要改善の多い観点トップ3)を付ける。