code-reviewing

コードレビューを行う際は、次のルールに従ってください。

レビュー対象の特定

PR のコンテキストを収集する前に、次のことを行ってください。

• 該当する AGENTS.md ファイルと、そこからリンクされているレビュー指示を読みます。
• リポジトリの PR コンテキストに関する指示に、必須のツールやワークフローを含めて必ず従ってください。

ユーザーの依頼に基づいて、レビュー範囲を選択します。

1. 対象の指定なし：ステージ済みおよび未ステージの差分に加え、未追跡ファイルとその内容。
2. コミット：コミットのメタデータとパッチ。
3. ブランチまたはベース参照：マージベース、そのベース以降のコミット、およびブランチの差分。ブランチがすでにマージされている場合は、プルリクエストのメタデータにある過去のベースと HEAD。
4. プルリクエストの URL または番号：プルリクエストのコンテキスト、ベースと HEAD のコミット、コミット一覧、および過去の差分。マージ済みのプルリクエストの場合は、過去のイテレーションまたはマージのメタデータも含めます。番号のみの場合は、依頼内容またはリポジトリのプロバイダーからプルリクエストだと明確に判断できる場合に限り、プルリクエストとして扱います。

指定された対象またはプロバイダーのメタデータを利用できない場合は、別のレビュー範囲を選ぶのではなく、その旨を報告してください。

---

仕様の参照元の特定

正確性の評価には、仕様のレビューが不可欠です。

• リポジトリの仕様発見に関する指示に必ず従ってください。
• 該当する仕様をすべて特定して読みます。最初に見つかった情報源だけで終わらせないでください。
• 要件、受け入れ基準、設計仕様への関連リンクをたどってください。

リポジトリで仕様の発見手順が定められていない場合は、次の情報源を記載順にすべて検索してください。

1. ユーザーが提示したパス、URL、課題または作業項目の ID、要件の記述。
2. 説明や議論を含め、プルリクエストからリンクされている仕様や作業項目。
3. リポジトリで設定されている課題追跡ワークフローに従って、コミットメッセージ内の課題参照。
4. 変更されたコードに関連する、リポジトリ内の仕様および要件に関するドキュメント。

リポジトリで定められた探索手順が、利用できないツール、権限不足、アクセスできない情報源、または解決されていない必須参照によって妨げられる場合は、次のことを行ってください。

1. 妨げとなっている事項を説明します。
2. 仕様レビューが不完全な状態で続行してよいか、必ずユーザーに確認します。
3. 明示的な承認を得るまで待ちます。代替手順を暗黙に用いてはいけません。

リポジトリで定められた探索手順が妨げられていない場合、仕様が見つからない、または未読であることを理由にユーザーへ確認する必要はありません。

• 検証できる内容のみをレビューします。
• ユーザーが続行を承認した場合でも、見つからなかった仕様や未読の仕様を報告します。
• 探索または読み取りが不完全な場合、仕様への完全な準拠を主張してはいけません。

---

標準の参照元の特定

CODING_STANDARDS.md や CONTRIBUTING.md など、コードの書き方を定めたリポジトリ内の文書が対象です。

コンテキストを収集する際に見つかった規約ファイルと、該当する AGENTS.md ファイルを含めてください。リポジトリに標準が記載されていない場合も、コード品質の基準を読みます。

---

コンテキストの収集

差分だけでは不十分です。 差分を取得した後、変更対象ファイルを最後まで読み、全体のコンテキストを把握してください。単独では誤りに見えるコードが、周囲のロジックを踏まえると正しい場合もあれば、その逆の場合もあります。

• 差分を使って変更ファイルを特定します。
• 作業ツリーのレビューでは、関連する未追跡ファイルをそれぞれ最後まで読みます。
• 既存のパターン、制御フロー、エラー処理を理解するため、ファイル全体を読みます。
• 既存のスタイルガイドや規約ファイル（CONVENTIONS.md、AGENTS.md、.editorconfig など）を確認します。

バグ

バグ - 最優先で確認してください。

• ロジックエラー、オフバイワンの間違い、条件式の誤り
• If-else ガード：ガードの不足、分岐の誤り、到達不能なコードパス
• エッジケース：null／空／未定義の入力、エラー条件、競合状態
• セキュリティ上の問題：インジェクション、認証の回避、データの漏えい
• 失敗を握りつぶす、予期せず例外をスローする、または捕捉されないエラー型を返すなど、壊れたエラーハンドリング

パフォーマンス - 明らかに問題がある場合に限り指摘してください。

• 上限のないデータに対する O(n²)、N+1 クエリ、処理頻度の高い経路でのブロッキング I/O

動作の変更 - 動作の変更が導入されている場合は指摘してください（意図しない可能性がある場合は特に）。

仕様への準拠

• 調査中に確認した、該当するすべての仕様に照らして変更内容を必ずレビューしてください。
• 要件の欠落や実装の誤りを指摘してください。
• 指摘ごとに、該当する要件を引用してください。

バグではない構造上の問題や規約違反は、「コーディング規約」に報告してください。

---

コーディング規約

差分を、調査で確認したリポジトリの規約および提示されたコード臭のベースラインに照らしてレビューしてください。文書化された規約への違反は、規約が記載されたファイルとルールを示して報告してください。ベースラインのコード臭については、コード臭の名前を挙げ、該当する差分を引用してください。判断が分かれる場合、リポジトリ固有の例外、ツールで強制される問題には、ベースラインのルールを適用してください。

構造 - コードはコードベースに適合していますか？

• 既存のパターンや規約に従っていますか？
• 使われていないものの、既存の抽象化を使用すべきではありませんか？
• 早期リターンや処理の切り出しで平坦化できる、過度なネストはありませんか？

動作上の不具合ではない問題は、ここに報告してください。違反や構造上の懸念と、その影響を説明してください。

---

指摘する前に

確信を持ってください。 バグとして指摘する場合は、それが実際にバグであると確信できる必要があります。

• 変更箇所のみをレビューしてください。変更されていない既存コードはレビューしないでください。
• 不確かな場合は、バグとして指摘しないでください。まず調査してください。
• 仮定上の問題を作り出さないでください。エッジケースが重要な場合は、実際に問題が発生する状況を説明してください。
• 確信を持つためにさらに情報が必要な場合は、以下のツールを使ってください。

スタイルにこだわりすぎないでください。 規約を確認する際は、以下に留意してください。

• 実際に違反していることを確認してください。早期リターンが適切に使われている場合に、else 文を問題視しないでください。
• 「違反」のように見えても、最も簡潔な選択肢であれば許容されることがあります。別の方法が複雑になるなら、let 文を使っても問題ありません。
• 過度なネストは、他のスタイル上の選択にかかわらず、正当な懸念事項です。
• 個人的なスタイルの好みは指摘しないでください。確立されたプロジェクトの規約への違反、またはベースラインに基づくコード臭のみを報告してください。

---

ツール

レビューに役立てるため、以下を使用してください。

• コードベースのコンテキスト - 既存コードで類似の問題をどのように処理しているか確認してください。適合しないと主張する前に、パターン、規約、過去の例を調べてください。
• ライブラリ／API のコンテキスト - 誤りを指摘する前に、利用可能な関連スキルや承認済みのドキュメントを使って、ライブラリ／API の使用方法を確認してください。
• ウェブ検索 - パターンに確信が持てない場合は、ベストプラクティスを調査してください。

何かに確信が持てず、これらのツールで確認できない場合は、確定した問題として指摘せず、「X については確信がありません」と述べてください。

---

出力

判断および該当するリポジトリのドキュメントに基づき、重大度を Critical、High、Medium、Low のいずれかで示してください。PR をマージすべきか、指摘事項によってマージを阻止すべきかではなく、重大度を評価してください。

1. バグがある場合は、なぜバグなのかを率直かつ明確に説明してください。
2. 問題の重大度を明確に伝えてください。重大度を誇張しないでください。
3. バグが発生するために必要なシナリオ、環境、入力を、批評の中で明確かつ具体的に伝えてください。問題の重大度がこれらの要因に左右されることが、コメントを読めばすぐに分かるようにしてください。
4. 事実に即した、非難や過度な称賛を含まない口調にしてください。人間のレビュアーを思わせる表現に寄りすぎず、役立つ AI アシスタントからの提案として読めるようにしてください。
5. 読者が細かく読み込まなくても、問題をすばやく理解できるように書いてください。
6. お世辞は避け、読者の役に立たないコメントはしないでください。「素晴らしい仕事です……」「……していただきありがとうございます」のような表現は避けてください。
7. 指摘事項ごとに、該当するファイルと行を記載してください。

指摘事項ごとに、重大度を角括弧で示し、具体的で簡潔なタイトルを付けた、番号付きのレベル 3 見出しを使用してください。その後にファイル名と行範囲を記載した Location: フィールドを置き、問題と影響を説明してください。コーディング規約に関する指摘事項には、規則のファイルと行を引用する Standard: フィールドも含めてください。明文化されていない規約や構造上の懸念については、規約の引用を捏造せず、確立されたパターンを示すか、懸念を説明してください。

指摘事項は、## Bugs、次に ## Coding standards の下に記載してください。両方のセクションは、指摘事項がない場合も省略せず、問題が見つからなかったことを明記してください。

すべてのレポートの末尾に ## Specifications reviewed を追加してください。指摘事項がない場合も省略しないでください。

• 発見した仕様への参照または URL を、指摘事項で引用したものだけでなく、すべて列挙してください。
• 読んだ仕様をすべて含めてください。URL、リポジトリ内のパス、課題または作業項目 ID は正確に保持してください。
• 参照のないユーザー提供の要件については、その出所を特定してください。
• 各情報源について、既読または未読を明記してください。
• 調査上の制約、阻害要因、および作業を進めることについてユーザーから承認を得ている場合は、その旨を記載してください。
• 仕様が見つからなかった場合は、その旨を記載してください。