start-pr-review

プルリクエストのレビューを開始する

この変更を書いたのは別の人であり、これからユーザーがあなたと一緒に内容を判断します。 あなたの役割はレビュアーです。問題を見つけ、根拠を示し、推奨事項を提示します。何をブロッカーとするかはユーザーが決め、その理由を作者が学びます。見つかった問題もセッション中の変更もすべて、作者が読む場所、つまりPRに記録されます。そのため、end-pr-review は記憶ではなく記録に基づく要約でセッションを締めくくれます。

差分を読む前に

1. 仕様を確認します。 変更は、本来何を実現するはずだったかに照らしてレビューします。どの文書に基づいて作成されたのか、PLAN.final.md、TECHNICAL.final.md、イシュー、会話などを確認して読みます。該当するものがなければ、その旨を伝えます。その場合、レビューの基準はPRの説明だけとなり、「依頼どおりに動作するか」という問いの精度が下がるため、指摘を提示する前にユーザーへ知らせておく必要があります。
2. プロジェクトが定める原則とベストプラクティスを読みます — PRINCIPLES.md（通常はdocs/PRINCIPLES.md）、AGENTS.md、CONTRIBUTING.md、PRが変更するコード領域のドキュメント、プロジェクトに存在する場合はdocs/acceptances/ATTENTION.mdを確認します。これらがレビューの基準です。すべての指摘で、そのいずれか、仕様、またはコードを根拠として引用します。
3. PRの概要を把握します。説明、git log --oneline <main>..<branch>、git diff --stat <main>...<branch>を確認し、ブランチがメインの統合ブランチより遅れていないかも調べます。コミットメッセージから各変更の意図が明確に伝わる必要があります。そうでない場合、それ自体が指摘事項です。

レビュー

重要なハンクを読み、変更全体と各部分について、次の3つの問いを確認します。

• 仕様どおりに、それ以上でもそれ以下でもなく、実装されていますか？ 判断を経ずに拡大したスコープも、欠けている要件も指摘事項です。作者がひそかに決めた製品上の判断は、レビュアーがそのまま承認するのではなく、ユーザーが判断するものです。
• 不要に複雑な部分はありませんか？ 既存の仕組みと並行する仕組み、同じものの二重実装、汎用的な入れ物、呼び出し元が1つしかない抽象化、依頼されていない設定、すでにコードが備えている機能を実現するための依存関係などです。原則は複雑さよりシンプルさです。複雑さを正当化する責任は、それを持ち込む側にあります。
• 不自然なところはありませんか？ 分割せずに肥大化した長い関数や大きなファイル、重複した状態、関心事の混在、意図ではなく仕組みを表す名前、握りつぶされたエラー、デッドコード、典型的なバグの原因となる問題 — マージブランチのリストに見られるタイムスタンプ比較、人の応答を担うスレッド上でのブロッキングI/O、バイト単位でのテキスト処理、ローカライズされていない文字列などです。変更に見合ったテストがあるか、またはテストが欠けていないかも確認します。

まず指摘事項を報告し、重要度順に並べます。それぞれにファイルと行番号、根拠、推奨事項を含めます。ユーザーがどの問題をブロッカーとし、どれを後続作業とし、どれを却下するかを決めます。質問ごとに判断は1つとし、平易な言葉で、まず推奨事項を伝えます。その話し合いの前に修正してはいけません。変更を書き換えてしまえば、レビュアーはレビューをやめたことになります。

記録と変更

• 記録はPRに残します。 各指摘について、可能であれば（ghまたはプロジェクトの同等のツールを使って）、判断内容を添えて該当行にレビューコメントを投稿します。ここから投稿できない場合は、ユーザーが投稿できるよう、同じ内容を1つのメッセージにまとめ、その旨を伝えます。
• ユーザーから指摘の修正を求められた場合は、fix-bugを使い、PRブランチ上で独立したコミットとして修正します。コミットメッセージには理由を明記し、commit-changesを介してコミットします。作者のコミットを書き換えたり、上書きするために強制プッシュしたりしてはいけません。また、依頼されない限りプッシュもしません。作者が自分の作業について、何が、なぜ変更されたのかをコミットごとに確認できるようにします。

指摘事項が確定したら

すべてのブロッキング指摘を修正するか、意識的に受け入れたら、start-acceptance で受け入れテストを開始します。PR のブランチが機能であり、仕様がスコープです。担当者が変更を実際に試すまではレビューは終わりません。セッションは end-pr-review で終了します。