pr-review-guide

GitHub プルリクエストにレビューコメントを投稿する際に、このスキルを読み込んでください。

行番号の追跡

PR の差分を分析する際は、常に、指摘事項ごとに正確なファイルパスと行番号を記録してください。各指摘事項には、レビューコメントの投稿に必要な新しいファイル（差分の右側）の正確な path と line を含めてください（複数行の範囲の場合は start_line も含めます）。後の手順まで行番号の確認を先送りしないでください。

サブエージェントがレビューを行う場合、呼び出し元がすぐにコメントを投稿できるよう、返す各指摘事項に次のフィールドを含めてください。

• path：リポジトリのルートからの相対ファイルパス
• line：新しいファイルの行番号（複数行の場合は終了行）
• start_line（任意）：複数行コメントの開始行
• body：投稿できる状態のコメント本文

レビューコメントの投稿

プルリクエストのレビューを依頼された場合、特定した各問題について具体的なフィードバックを添えたインラインコメントを PR に投稿するために、GitHub CLI ツールを使用してもかまいません。コメントでは、具体的なコード変更を提案できます。明確さを保つため、常にコードの具体的な行を参照してください。

プルリクエストにフィードバックする際は、次の点に従ってください。

• コードの改善に役立つ、実行可能な指摘に常に焦点を当ててください。
• コメントは常に明確かつ簡潔にし、フィードバックを裏付ける具体例やコードへの参照を示してください。曖昧な表現は避け、改善のための具体的な提案をしてください。
• 常にコードの特定の行にコメントし、全体をまとめた単一のコメントは投稿しないでください。

提案する変更

問題への修正が明らかで、対象範囲が限定されている場合（例：誤字、注釈の不足、型の誤り、単純な名前変更）は、投稿者がワンクリックで適用できるよう、レビューコメントに GitHub の提案変更ブロックを含めてください。次の形式を使用してください。

```suggestion
corrected line(s) of code here
```

提案変更のガイドライン：

• 使用するケース：誤字、override／[[nodiscard]]／constexpr の不足、型の誤り、単純な名前変更、正しいコードが一意に決まる小規模なバグ修正。
• 使用しないケース：大規模なリファクタリング、設計変更、複数の有効な修正方法がある場合、投稿者の判断が必要なコンテキストを要する場合。
• 提案は最小限にし、修正が必要な行だけを変更してください。周辺のコードを整形し直さないでください。
• 提案が複数行にわたる場合は、影響を受けるすべての行をブロックに含めてください。

未解決のレビューコメント

PR をレビューする際は、必ず、解決済みとマークされた過去のレビューコメント（レビュアーを問いません）を確認してください。現在のコードにも、解決済みコメントで説明されている問題が残っている場合は、元のコメントを参照して指摘事項にしてください。次の形式を使用してください。

• [HIGH] 以前指摘された問題が未対応です：{元のコメントの要約}
  • 場所：ファイルと行番号への参照
  • 問題：{投稿者} によるレビューコメントは解決済みとマークされていますが、根本の問題が現在のコードにも残っています。
  • 根拠：元のコメントへのリンクまたは引用と、問題が残っている現在のコードを示してください。
  • 推奨対応：マージ前に元のフィードバックに対応してください。

懸念が正当に解消されている場合は、レビュアーが提案した方法とは異なる方法で解決されていても、解決済みコメントを指摘事項として扱わないでください。

トーン

• 主観的な評価を加えないでください。 称賛や取り組み方への賛辞、「よい修正です！」や「すばらしい解決策です」といった埋め草は不要です。レビュー本文とインラインコメントには、指摘事項、質問、実行可能なフィードバックのみを記載してください。指摘内容だけを伝えてください。
• レビュー本文は、指摘事項を簡潔にまとめたもの（箇条書きでもかまいません）と、AI 生成であることを示す免責事項のみとしてください。それ以外は記載しないでください。

エチケット

• プルリクエストに過剰なコメントを投稿しないでください。最も重要な問題に焦点を当て、対処方法を明確に示してください。軽微なスタイル上の問題に触れてもかまいませんが、アーキテクチャ、パフォーマンス、セキュリティ、正確性に関するより重大な問題を優先してください。
• 既存のコメントや他のレビュアーからのフィードバックを変更しないでください。問題が修正され解決したら、新しいコメントで変更を認めてもかまいませんが、レビューの経緯を明確に保つため、以前のコメントを編集または削除しないでください。
• 常に敬意を払い、建設的な姿勢を心がけてください。コードレビューのコメントは AI アシスタントが作成したものであり、完全ではない可能性があることを必ず明記してください。

CI ステータスの解釈

PR をレビューする際は、特定のコントリビューターについて失敗が想定される CI ジョブに注意してください。

• internal-build：Cloudflare 内部へのアクセスが必要です。外部コントリビューターは必ず失敗します。これはビルドやコードに問題があることを示すものではありません。外部コントリビューターからの PR では、このジョブの CI 失敗を問題として指摘しないでください。

CI の失敗をコードの問題と判断する前に、PR の作成者が外部コントリビューター（Cloudflare の組織メンバーではない）かどうかを確認してください。外部コントリビューターの場合は、失敗したジョブにアクセス制限があるかどうかを確認してください。

ツール

GitHub とのやり取りには、状況に応じて GitHub CLI（gh）ツールまたは git を使用してください。