code-review

Awesome Copilot コードレビュー

このスキルは、このリポジトリのプルリクエストをレビューするときに使用します。まず .github/copilot-instructions.md の決定論的なチェックリストを適用し、その後、スキーマ検証だけでは判断できない編集上の判断や、リポジトリとの適合性を評価する判断にこのスキルを使用します。

フロントマターは YAML として検証し、引用符のスタイルではなく、必須のメタデータを確認してください。プレーン、シングルクォート、ダブルクォート、リテラル、折りたたみの各スカラーは、解析後の値がフィールドの型と内容に関する要件を満たしていれば、すべて使用できます。値がシングルクォートで囲まれていないという理由だけで、変更を求めないでください。

スキルについては、SKILL.md の構造とフィールドの制約には Agent Skills の仕様 を、リポジトリ固有のチェックには .github/copilot-instructions.md を使用してください。YAML として一般的に有効であるだけでは、仕様を満たしたことにはなりません。たとえば、metadata は文字列を文字列に対応付ける必要があり、allowed-tools はシーケンスではなく、スペース区切りの文字列でなければなりません。引用符のスタイルを指定せず、解析後の型と値を確認してください。

レビューの優先順位

次の順番でレビューしてください。

1. 正確性、セキュリティ、有害な動作。
2. リポジトリの貢献要件への準拠。
3. リポジトリとの適合性と、GitHub Copilot ユーザーにとっての有意義な価値。
4. 既存のリソースやモデル本来の能力との差別化。
5. 貢献がテストまたは検証されたことを示す証拠。
6. 明瞭さ、保守性、適切な範囲。

品質の指標として、ファイル数をそのまま使用しないでください。生成されたウェブサイトの大規模な変更、README の機械的な更新、その他のビルド出力も正当な場合があるため、元となるソースの変更内容に基づいて評価してください。

リポジトリとの適合性

投稿が、GitHub Copilot の特定のワークフロー、テクノロジー、ドメイン上の制約、またはユーザーの問題に対応していることを確認してください。次のような貢献には指摘してください。

• 有意義な付加価値をもたらさず、現在のモデルがすでに十分に対応できる一般的な助言を提供しているもの（ナレッジの付加価値を参照）
• 明確な差別化を示さず、既存のリソースを言い換えているもの
• あらゆるプロジェクトですべてに対応できる、といった広範な主張をしているもの
• 具体的な指示、制約、例、または期待される結果を示していないもの
• 主に投稿者の製品を紹介または宣伝するためのラッパーであるもの

有料または商用のサービスだからといって、自動的に不適切と判断する必要はありません。投稿が単独でもユーザーに価値を提供し、有料サービスに関するリポジトリのガイダンスに従っているかを評価してください。

ナレッジの向上

リソースに価値があるのは、モデルの行動を変える場合に限られます。適切に整形され、要件に準拠したコンテンツでも、何の価値も加えないことがあります。PR が追加または大幅に変更するすべてのエージェント、指示、スキル、プロンプト、フック、ワークフローについて、次の基準を適用してください。

1. リソースを読み込まずに、現在の最先端モデルが同じタスクを与えられたら、何をするか考えてください。
2. このリソースによって、モデルが何を変えるのかを特定してください。価値があるのはその差分であり、コンテンツそのものではありません。

真に価値を高めるもの：

• モデルが知っている可能性や正しく扱える可能性が低い事実。たとえば、最近登場した API やニッチな API、バージョン固有の破壊的変更、気づきにくい落とし穴
• 社内向け、独自のもの、または組織固有のツールや規約
• 妥当なデフォルトを意図的に上書きする制約
• 決定論的な結果を生み出す、同梱のスクリプト、テンプレート、データ
• 特定のツールや MCP サーバーを連携させる複数ステップのワークフロー
• 直感的にわかりにくい期待出力の具体例

価値の向上と見なさないもの：

• クリーンコード、SOLID、DRY、意味のある名前、テストの作成、エラー処理など、一般的なベストプラクティス
• 主流の言語やフレームワークに関する、広く知られた公開ドキュメントの言い換え
• 新たな制約を加えない、「あなたは X の専門家です」といったペルソナの設定
• モデルが標準で備えている動作を列挙したチェックリスト
• ユーザーの一行の依頼で置き換えられる長文

長さ、洗練度、構成は、価値の根拠にはなりません。価値を高めている具体的な行を引用または示してください。該当するものがなければ、明確にそう伝えてください。結果を次のように分類してください。

• 高 — コンテンツの大部分が、優れたモデルにとって自明ではありません
• 部分的 — 役立つ中核部分がある一方、一般的な内容でかさ増しされています
• なし — このリソースがなくても、優れたモデルの動作は実質的に変わりません

価値の向上がなしの場合、承認を推奨しないでください。部分的の場合は、該当する一般的なセクションを削除し、具体性のあるセクションを拡充するよう投稿者に求めてください。

AI が作成した投稿

🤖🤖🤖 で終わる PR タイトルは、CONTRIBUTING.md に記載された、AI が作成したことを意図的に開示するものです。このマーカー自体を問題として報告しないでください。

AI が作成したことを開示している投稿については、PR が引き続き次の点を満たしているか確認してください。

• 具体的なニーズがあり、リポジトリに適合している
• 人による結果の検証またはテストが行われている
• 生成された一般的な文章ではなく、有用な制約が含まれている
• 既存のリソースとの違いが説明されている

生成に使われたツールについての憶測ではなく、提出された成果物をレビューしてください。

マーケティングと自己宣伝

マーケティング色の強い表現は、次のような具体的な証拠がある場合に限り指摘してください。

• 使用手順と関係のないブランドや製品の宣伝が繰り返されている
• 裏付けのない最上級表現や販売上の主張
• リンクや行動喚起がリソースの大半を占めている
• GitHub Copilot の利用支援ではなく、ユーザー獲得を主目的とするリソース
• 「無料のリソースから有料コネクターへ」と誘導する構成。MCP／コネクターの設定コマンド、UTM リンクや紹介リンク、または作成者のサービスへ誘導するクレジット制アップセルが含まれます。ベンダー名を削除して導線を残した改変版も対象です。コンテンツの権利者を確認するため、LICENSE の著作権者、metadata.author、上流リポジトリの README を確認してください。

具体的な証拠を示し、投稿の焦点をユーザーの課題に戻す方法を提案してください。作成者が参照先プロジェクトと関係しているという理由だけで、宣伝目的だと推測しないでください。

重複と差別化

新しいリソースが既存のものに似ている場合は、既存のエージェント、指示、スキル、フック、ワークフロー、プロンプト、プラグインを検索してください。名前だけでなく、目的と動作を比較してください。

重複を報告するのは、重なりが大きい場合に限ります。対象とするフレームワーク、ユーザー層、制約、ワークフローの段階が異なる場合は、関連するリソースが共存できることがあります。

設定済みの MCP コンテキストが関係する場合は、GitHub MCP サーバーを使って、関連するイシュー、過去の投稿、リポジトリの履歴を確認してください。判断の根拠となる具体的なリソースまたはプルリクエストを示してください。

エビデンスと検証

PRに、コントリビューションをどのようにテストまたは検証したかが記載されていることを確認してください。適切なエビデンスはリソースによって異なります。

• エージェント、プロンプト、指示、スキルには、現実的な使用シナリオを含めるか、出力の評価方法を説明する必要があります
• スクリプトや同梱アセットには、対象を絞ったテスト、または再現可能な検証手順が必要です
• ワークフローやフックでは、安全なトリガー、最小権限のアクセス許可、制約された出力、想定されるイベントの動作を示す必要があります
• ドキュメントの更新では、説明している機能や動作の正式な情報源を示す必要があります

現実的な手動評価のほうが適切な場合、文章のみのリソースに実行可能なテストを求めないでください。リソース独自のルールを試すためにフィクスチャを作成したAIのみの合成評価や、Copilot以外のハーネスのみでのテストは、それだけでは弱いエビデンスです。

信頼できる経路と自動化された経路

GitHubおよびMicrosoftの外部プラグインの更新は、通常、信頼できるソースからの投稿です。それでも、具体的な正確性、セキュリティ、マニフェストの問題は報告してください。ただし、変更が自動化されたもの、または外部から提供されたものだからといって、編集上の懸念を作り出さないでください。

自動化されたドキュメントPRについては、内容の誤りと、自動化による古い更新の繰り返しを区別してください。毎日重複する更新は、ドキュメント自体の品質が低いことを示すのではなく、ワークフローが既存のPRを更新すべきことを示している場合があります。

レビュー結果

PRによって生じた、具体的で対応可能な問題についてのみコメントしてください。各指摘では、次の点を満たす必要があります。

• 可能な場合は、該当するファイルと行を特定する
• ユーザーやメンテナーへの具体的な影響を説明する
• 指摘の根拠となるリポジトリのルール、既存リソース、またはエビデンスを引用する
• 最小限で有効な修正を提案する

「AIが生成したように感じる」「品質が低い」「マーケティングっぽい」といった曖昧なコメントは避けてください。観察できる問題を説明してください。

自動チェックに合格したという理由だけで承認を推奨しないでください。編集上の価値やリポジトリとの適合性についての最終判断は、人間のメンテナーが行います。

レビューポリシーの変更

Copilot Code Reviewは、PRのヘッドブランチからスキルと指示を読み込みます。そのため、.github/skills/code-review/、.github/copilot-instructions.md、AGENTS.md、その他のレビューポリシーファイルへの変更は、セキュリティ上重要なガバナンス変更として扱ってください。レビュー基準を弱めたり、回避したり、削除しようとする変更は明確に指摘し、メンテナーによるレビューを必須としてください。