review

レビュー

結果を変えたり、変更を危険にしたりする不具合を見つけてください。個人の好みを指摘事項にしないでください。

変更を実装していない新しいサブエージェントを使ってください。委任せずに直接レビューするよう指示してください。あなたがそのレビュアーである場合は、直接レビューしてください。読み取り専用で作業してください。ファイルを編集したり、コメントを投稿したりしないでください。

対象範囲

ユーザーが指定した実装対象をレビューしてください。対象はファイル、差分、ブランチ、コミット、プルリクエスト、または GitHub 上のその他のコード変更です。未実装の技術提案には /architecture-review を使用してください。

ユーザーが対象を指定していない場合は、リポジトリのローカル変更全体をレビューしてください。デフォルトブランチを基準とした現在のブランチ上のコミット、ステージ済みの変更、未ステージの変更、未追跡ファイルを含めてください。

リポジトリと、その周辺の関連コードを文脈として使用してください。ローカル変更がない場合は、その旨を伝えてください。リポジトリ全体の監査に置き換えないでください。

基準

次の条件を満たす場合にのみ承認してください。

• 変更がその目的に合致し、要求どおりに動作する。
• ソースや、セキュリティ、データ損失、互換性、運用に関するリポジトリのルールを破る可能性のある既知の不具合や未対処のリスクがない。

完璧さを求めたり、個人の好みを理由に差し止めたりしないでください。技術的な根拠またはリポジトリの慣例を示してください。

判定は、独立したエージェントによる証拠です。GitHub の承認ではなく、人間によるレビューの代わりにもなりません。

レビューの順序

1. 前提を設定する。 レビュー担当者に、タスク、受け入れ基準、タスクまたは仕様にある不変条件 ID、リポジトリのルール、差分全体またはプルリクエスト、テストの証拠を伝えてください。変更の影響を受けるユーザーまたは開発者を明示してください。
2. 全体像を把握する。 変更の概要と、関連する仕様またはチケットを読んでください。変更がシステムに適していること、意図した動作と一致していること、レビュー可能な一つの成果を提供していることを確認してください。不一致があれば、詳細をレビューする前に報告してください。
3. 主要な動作をレビューする。 成果を実現するファイルとフローから始めてください。動作、障害、セキュリティ境界、インターフェース、互換性、マイグレーション、並行性、運用を確認してください。
4. 人が記述した変更箇所をすべて、文脈の中でレビューする。 正確性、回帰、複雑さ、名称、コメント、スタイル、ドキュメントを判断できるだけの周辺コードを読んでください。生成ファイルや大規模なデータについては、生成元を確認し、出力を抜き取りでチェックしてください。指摘事項は変更の範囲内に留めてください。
5. 検証内容をレビューする。 テストについて、次の点を確認してください。
   • 変更された動作と、影響を受ける障害経路をカバーしている。
   • 引用されているすべての AC-n、REQ-n、INV-n、またはタスク基準を検証している。
   • ユーザーや呼び出し元が観測できる動作、または文書化された内部契約を検証している。
   • 実装に不具合があれば失敗する。
   • 実装ロジックをコピーしておらず、セットアップにシナリオを隠していない。
6. 指摘事項や判定を変える可能性のある主張を確認または否定できる、焦点を絞ったチェックを実行してください。
7. 専門分野のレビュー範囲を確認する。 セキュリティ、プライバシー、並行性、アクセシビリティ、国際化、またはドメイン固有の作業を特定してください。判断に必要な証拠やスキルがレビュアーにない場合は、リスクを「未検証」としてください。その不足によってルールに違反する問題が見逃される可能性があり、適格なレビュアーによる確認がない場合は、Blocked としてください。
8. 指摘事項を報告する。 下記の形式を使用して、対応可能な指摘事項を優先度順に返してください。

コードレビューの指摘事項

実際のバグ、顧客に影響する問題、または変更によって導入・露呈したことが確認できる簡素化のみを報告してください。セキュリティ、ロジック、動作、信頼性、互換性、リグレッション、および影響を受ける障害経路を確認してください。

各指摘を裏付けるため、周辺コードを十分に調べてください。簡素化とは、状態、間接処理、重複、または運用作業を減らしながら、同じ結果と根拠を提供するものです。Could fix としてのみ報告してください。

各指摘には次の形式を使用してください。

Priority: Must fix / Should fix / Could fix
Confidence: 0 to 5
What I found: Describe the technical problem.
Why it matters: Explain the impact on customers, callers, or the service.
Trigger and effect: State the exact condition and what the customer or service experiences.
Where: File and line.
Suggested fix: Give a short, practical direction.

優先度の意味：

• Must fix： マージすると危険です。この変更によって、セキュリティ上の障害、データ損失、必須機能の破損、または重大なサービスのリグレッションが発生する可能性があります。
• Should fix： 修正すべき実際の不具合または信頼性上のリスクです。マージ前に修正する必要があります。
• Could fix： 影響範囲が限定され、確認済みの問題または簡素化です。マージを妨げる必要はありません。スタイルの好みには使用しないでください。

確信度の意味：

• 5： 再現、テスト、またはコードの直接的な証拠によって確認されています。
• 4： 信頼できる別の説明がなく、強い根拠があります。
• 3： 可能性は高いものの、実行時の証拠が不足しています。
• 0～2： 報告しないでください。さらに調査するか、その領域は未検証としてください。

平易な言葉を使ってください。何が、どのような状況で壊れ、誰に影響するかを述べてください。スタイルの好み、理論上の懸念、変更範囲外の問題は省いてください。

判定

新たなサブエージェントを利用できない場合、ユーザーが文書化されたセルフレビューを明示的に受け入れない限り、独立レビューができない旨を報告して終了してください。

指摘事項がない場合は、その旨を伝えてください。最後に Approve、Request changes、または Blocked のいずれかを記載し、その後に未検証の事項を述べてください。Must fix または Should fix の指摘がある場合は、Request changes としてください。Could fix の指摘は Approve を妨げません。

範囲

• 指摘は変更範囲内に限定しつつ、変更された各行とシステムへの影響を判断できるよう、周辺コードも十分に調べてください。
• 好みを指摘事項にしないでください。技術的な証拠とリポジトリの慣例を根拠にしてください。
• チェックに合格したという理由だけで承認しないでください。