ln-61-skill-reviewer

スキルレビュー

目標： リポジトリや外部の状態を変更せずに、スキルの品質と設定済みの配布先をレビューします。静的な契約の保証と、実行時に観察された動作を区別します。

実行契約： 順序付きのチェックボックスが完了の定義です。各項目を内部で PENDING、具体的な証拠がある PROVEN、条件が存在しない証拠がある CLEARED、または不足がある UNPROVEN として追跡します。読み取り、委任、ツールの失敗は証明になりません。各セクションの後に項目を照合してください。回答を返す前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数えます。すべての不足に対し、スキルの判定ルールと承認ルールを適用してください。 ユーザーの意図、範囲、既存の承認を維持してください。承認済みの作業は続行し、重大な未解決の選択肢や必要な外部承認がある場合に限り、確認を求めてください。重大なリスクに応じて調査の深さを調整し、チェックを暗黙に省略しないでください。依存関係と安全性に関する順序を守り、それ以外の場合は各要件に適した検証方法を選んでください。

ツールのルーティング

必要な作業	優先する機能	代替手段
リポジトリの範囲と証拠	ネイティブのファイル検索、対象を絞った読み取り、Git diff	同等の読み取り専用シェルコマンド
フロントマターとスキルの構造	リポジトリ定義またはホストネイティブのスキルバリデーター	YAML、パス、命名規則、リポジトリ契約の手動チェック
プラグイン統合	リポジトリ定義のプラグインバリデーターとマニフェスト解析	マニフェストと該当するカタログの手動比較
ホストによる検出	設定済みのすべての配布先に対応するホストネイティブのバリデーター	カタログ、マニフェスト、ソースパスの手動検査
現在のホストルール	ホストの公式ドキュメント	入手できない場合、主張を UNVERIFIED とする
動作上の独立性	新しいサブエージェントまたはクリーンなコンテキスト	信頼度が低いことを明示した、分離した自己レビュー

外部調査は、現在のホストの動作や変更される可能性のある標準を確認する場合にのみ使用してください。リポジトリの実ファイル、インストール済みバージョン、ローカルの検証結果を覆すために、ウェブ上の情報を使わないでください。

ツールがないこと自体は、スキルの欠陥ではありません。文書化された代替手段を適用し、機能が欠けているために信頼できる判定ができない場合に限り、BLOCKED としてください。

チェックリスト

範囲と証拠を確認する

• 対象パス、Git の差分、ステージ済みファイルと未追跡ファイルを特定し、レビューのモードを確立します。静的コンテンツ／配布物のレビューか、要求された場合、必要と判断された場合、および許可されている場合の動作検証かを確認します。テストを行わないよう明示されている場合はそれに従います。静的レビュー専用モードでは、シナリオを実行したり評価を委任したりしないでください。
• リポジトリ固有の規約を判断する前に、リポジトリの指示、スキルの契約、および設定されているすべてのホストカタログを確認します。リポジトリが配布していないカタログは必須にしないでください。
• 主となるスキルと、同じ変更の影響を受けるマニフェスト、カタログ、ドキュメントを分けて確認します。
• リポジトリで定義された標準的なスキル構成を確認します。リポジトリのポリシーで明示的に要求されているアダプターや生成コピーは認めつつ、許可されていない、古い、または内容が異なるホスト固有のコピーは不備として扱います。
• フロントマターとフォルダー名が、リポジトリの契約および各対象ホストの要件を満たしていることを確認します。name と description のみがローカル規約として定められている場合は、その2項目だけを求め、普遍的な要件として押し付けないでください。
• 各説明に、提供する機能、適用対象となる明確な条件、および重要な非適用範囲が記載されていることを確認します。
• 説明がホストの文字数制限内に収まり、ワークフローで裏付けられない広範な主張を避けていることを確認します。
• 各スキルが単独で動作し、必須の別スキル、MCP サーバー、トラッカー、コーディネーター、ワーカー、共有ランタイムを必要としないことを確認します。
• リポジトリで定められた完了規約を適用します。順序付きチェックリストが完了の定義である場合、重複した完了セクションを指摘します。
• ドメイン固有のアルゴリズム、ツールの振り分け、安全ゲート、証拠、判定、出力、残存リスクを維持します。確認項目が削除されている場合は、義務を引き継ぐ項目を特定するか、その確認が目標の達成に寄与しない理由を説明します。項目数だけでは、義務の喪失も維持も証明できません。
• 意思決定に役立たない一般論は指摘します。過去の失敗が記録されていなくても、直感的でないドメイン知識と具体的な安全策は維持します。
• 内容の階層と単一の情報源の管理を確認します。各ルールを最も適切な標準セクションに置き、本文、補足ファイル、マニフェスト、リポジトリの指示間で重複または矛盾するガイダンスを指摘します。
• 冗長な記述、生成された要約文、コピーされた実装ロジックやビジネスロジック、安定した契約、権威ある情報源、または明示的な更新トリガーに置き換えられる、変動しやすいバージョン、パス、件数、既定値、ホストの動作を指摘します。
• 必須の機能すべてについて、利用可能なツール経路、信頼できる代替手段、または明示的な BLOCKED の結果があることを確認します。
• 各スキルの変更範囲が、宣言された結果に合致していることを確認します。読み取り専用のワークフローに、暗黙の書き込み権限が加わってはなりません。
• 最適化や実験を行うスキルで状態を変更する場合、証拠に基づいて維持、破棄、またはロールバックを決定するよう求めます。
• テスト作成など変更範囲が限定された書き込みを行うスキルについて、宣言された契約で明示的に許可されていない限り、製品コードを修正したり、承認されていない外部状態に触れたりできないことを確認します。
• 通常の完了、ツール不足、コンテキスト不足、Git の未コミット状態、コマンド失敗、矛盾する証拠における処理を追跡します。前提条件が依存するアクションより先に示されていること、安全な進行を可能にする停止条件があること、失敗状態の判定に矛盾がないことを確認します。
• 出力契約で、事実、推論、不足している証拠、判定、残存リスクが区別されていることを確認します。
• 周辺の適用条件を各スキルの目標と照らし合わせます。指示が結果、証拠の必要性、または範囲／安全上の制約を支えていることを求めます。無関係な作業、不足している義務、曖昧な分岐を指摘します。ただし、スキル同士を依存させないでください。

リポジトリの検証

• 変更したスキルディレクトリについて、リポジトリで必須とされているすべてのスキルバリデーターを特定して実行します。リポジトリの証拠がない場合、バリデーターの名前や場所を推測しないでください。
• 必須のバリデーターを利用できない場合は、リポジトリおよびホストの契約に照らして、YAML の解析、命名、説明の制約、必須ファイルの配置を手動で検証します。
• 影響を受ける配布単位について、リポジトリで必須とされているすべてのプラグインまたはパッケージのバリデーターを実行します。
• 対応するカタログまたはマニフェストが存在する場合は、各ホスト固有の厳格なバリデーターを実行します。実際の検証範囲を記録し、ホストがそれらのスキルを実際に検証していると確認できない限り、マーケットプレイスの検証をスキルのフロントマター検証として扱わないでください。
• 設定されたカタログをすべて解析します。リポジトリのポリシーでホスト間の整合性が求められている場合に限り、プラグイン名と順序を比較します。
• 宣言されているすべてのカタログソース、マニフェストパス、スキルパスが存在することを確認します。
• リポジトリで整合性が求められている箇所では、プラグインの説明など重複するメタデータが一致していることを確認します。
• マーケットプレイスのリポジトリでは、安定した識別子が意図せず変更されていないことを確認します。表示上のブランディングは識別子の代わりにはなりません。
• 古い名前、削除済みのパス、ドラフトのマーカー、MCP との結び付き、オーケストレーション関連の用語、生成されたコピーを検索します。
• 行数の目標は、リポジトリのポリシーで定められている場合に限り適用し、動作品質の証拠ではなく保守上の制約として扱います。

対象範囲に含まれる場合の動作レビュー

• このフェーズは、動作の実行が対象範囲に含まれ、許可されている場合に限り適用します。それ以外の場合は、実行のみを対象とする項目を対象範囲の理由とともに CLEARED とし、動作はテストしていないことを明記します。静的な調査だけでは、起動や実行品質を証明できません。
• スキル名だけでなく、記載されたトリガーから代表的な肯定プロンプトを導き出します。
• 隣接する機能や、曖昧になりやすいユーザーの表現から、類似する否定プロンプトを導き出します。
• 肯定プロンプトではスキルが起動し、類似する否定プロンプトでは起動しないことを検証します。
• 通常のシナリオ、証拠が不足しているシナリオ、安全上の境界に関するシナリオを、それぞれ少なくとも1つずつ検証します。
• スキルがコードやその他の成果物を生成する場合は、エージェントが実際に生成した結果を評価し、独立したタスク契約との差分を確認します。文章のレビュー、回答の簡潔さ、静的な調査を、実行時の動作の代わりにしないでください。
• タスクの完全性、正確性、安全性、対象範囲の順守、クリーンアップをそれぞれ個別に評価します。コード量やトークン数の削減は、求められる結果を達成した後に限り、補助的な証拠として扱います。
• 複雑または高リスクな変更では、利用可能な場合、新しい独立したコンテキストを使用し、スキルと未加工のタスク成果物だけを提供します。
• 期待される検出事項、意図された修正、過去の結論を独立した評価者に明かさないでください。
• 漏えいしたコンテキストがなければ成功しないフォワードテストは、スキルの欠陥として扱います。
• 独立したコンテキストが、グローバルにインストールされたスキル、フック、プラグイン、ユーザー指示、環境設定、キャッシュ、成果物によって汚染されていないか確認します。対象スキルが起動したことを証明し、動作の帰属を確実に判断できない評価アームは無効とします。
• 具体的な反復性のある失敗によって必要性が証明されない限り、評価ハーネスを作成したり保持したりしないでください。

エビデンスのルール

• 各指摘は、正確なファイルと、役立つ範囲で最小の行またはセクションを示して引用します。
• バリデーターの失敗と、手動で確認された懸念、推測に基づく改善案を区別します。
• ブロッキング重大度を付与するには、決定論的なバリデーターのエビデンス、許可された再現、または完全な静的矛盾／失敗パスを必須とします。レビューの実施モードで除外されているシナリオは実行しないでください。
• 実行したコマンド、終了ステータス、重要な出力を、シークレットを漏らさずに記録します。
• 必須のホストテストまたはクリーンコンテキストテストを実行できない場合は、カバレッジの不足を報告します。許可された診断用アーティファクトは一時的なものとして正規のプラグインディレクトリの外に保管し、その旨を開示してください。レビュー中にステージング、公開、外部状態の作成を行わないでください。

判定

• PASS — 宣言されたモードに必要なすべてのチェックに合格し、重大な懸念はありません。静的チェックのみの PASS は、実行時の動作を保証するものではありません。
• PASS WITH CONCERNS — レビュー対象範囲に確認済みのブロッキング不具合はありませんが、範囲を限定した非ブロッキングの不確実性が残っています。テストされていない公開準備や動作準備が整っていると推測しないでください。
• FAIL — 誤ったトリガー、安全でない動作、インストールの破損、または無効な契約を引き起こす可能性のある、確認済みの不具合があります。
• BLOCKED — 必須のエビデンスまたはツールを利用できず、信頼できる代替手段もありません。

セルフチェック

• 返答前に整合性を確認してください。 項目ごとのエビデンス、要件の網羅性、矛盾、対象範囲、判定、該当するクリーンアップを確認します。レポートまたは許可されたアーティファクトを修正してください。有効なエビデンスを再利用し、リポジトリを自動的に再スキャンしたり、成功したコマンドを再実行したりしないでください。関連する変更、失敗、未解決のエビデンスがある場合に限り、チェックを繰り返してください。残る不足を開示してください。

出力の契約

ユーザーの言語で、次の順序に従って報告します。5つのフィールドをすべて保持し、各事実は一度だけ記載してください。結果が少ない場合は、各フィールドを1行にまとめてもかまいません。空の表は省略し、リンク先のアーティファクトをコピーしないでください。

1. 結果： スキル固有の判定と、エビデンスで裏付けられた結果。
2. 対象範囲： レビュー／変更した対象範囲、除外事項、ベースライン、重要な前提。
3. エビデンス： 以下のスキル固有の項目。事実、推論、未検証の主張を区別します。アーティファクトへのリンクを付け、役立つ場合は表を使用します。
4. 検証： チェックと結果、利用できないエビデンス、該当するクリーンアップ／外部状態。
5. 完了： Checklist: X/Y complete、Incomplete: None、または各 UNPROVEN 項目の理由、結果への影響、具体的な次のアクション。残存リスクと必要な判断事項。

スキル固有のエビデンス： 対象スキルと配布先。構造／ホスト間の同等性、トリガーの境界、静的チェックと動作チェックのカバレッジ、バリデーターの結果。指摘には重大度、正確な場所、影響、エビデンス、最小限の修正を含めます。確認済みの不具合、手動で確認された懸念、推測に基づく改善案を区別します。利用できないクリーンコンテキストまたは実行時のエビデンスと、開示済みの一時的なアーティファクトを報告します。