code-review

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

引数：$ARGUMENTS — PR 番号または URL、またはモードです。BUGS、SECURITY、PERFORMANCE を指定すると、その観点に絞ってレビューします。それ以外の場合は、すべての観点を適用します。

入力

差分がインラインで貼り付けられている場合 → そのテキストをレビューし、ほかの情報は取得しません。それ以外の場合は、PR 番号または URL、あるいは現在のブランチに紐づく PR を対象に、gh pr view と gh pr diff を実行します。PR が見つからない場合 → PR の提示を求めます。

承認基準

変更によってコード全体の健全性が確実に向上するなら、完璧でなくても承認します。自分なら別の書き方をするという理由で、変更を差し戻してはいけません。コードベースを改善し、その規約に従っているなら承認します。

変更が大きすぎて適切にレビューできない場合（約1000行以上）、作者に分割を依頼するのも妥当な対応です。分割方法を提案します。スタック方式（小さな変更を先に出し、それを土台に次の変更を重ねる）、ファイルグループごと、水平分割（共有コードを先に変更し、その後に利用側を変更する）、垂直分割（PR ごとにエンドツーエンドの一連の処理を実装する）などがあります。

レビュー基準

最新のコミットだけでなく、変更されたすべてのファイルをレビューします。まずテストを確認します。振る舞いをテストしているか、エッジケースを網羅しているか、回帰を検出できるかを確認します。ローカルでブランチをチェックアウトしている場合、最後の点は実験で確かめます。変更によって追加された条件をひとつ反転させ、テストスイートを実行してから、ファイルを元に戻します。それでもテストが成功するなら、テストが不足しています。不足しているテストを明記します。他のエージェントと並行してレビューしている場合は、この実験を省略します。test-auditor がスクラッチコピーでミュータントを実行するため、作業ツリー内で編集すると競合する可能性があります。

• 正確性：ロジックのバグ、オフバイワン、競合状態、未処理の状態、欠けているエラーパス
• 可読性：50行を超える関数、2階層を超えるネスト、デッドコード、未使用のインポート
• セキュリティ：露出したシークレット、検証されていない外部データ
• 型安全性と不変性：any や正当化されていない型アサーション、共有データのインプレース変更
• パターン：コードベースの規約との一貫性、既存の手段を再発明していないこと
• パフォーマンス：不要な再レンダリング、O(n) で済む処理における O(n²)
• コードの臭い：smells.md にあるベースラインと差分を照合します。いずれも判断を要するものであり、リポジトリに記載されたスタイルがベースラインより優先されます
• 依存関係のアップグレード（差分にマニフェスト／ロックファイルが含まれる場合）：変更ごとに依存関係はひとつにします。まとめて更新すると、問題を起こしたパッケージを特定しにくくなります。バージョン番号ではなく変更履歴で確認します。ロックファイルの差分もレビューします（直接依存関係をひとつ更新するだけで、多数の間接依存関係が変わることがあります）。手作業で編集されたロックファイルにはフラグを立てます

出力

重大度ごとに分類し、すべての指摘に file:line を記載します。Critical には修正案を必ず添えます。

• Critical — マージ前に必ず修正が必要（バグ、脆弱性）
• Suggestions — 検討に値する改善点
• Nit — 軽微で任意の指摘。ささいな指摘は省略したり重大度を誇張したりせず、Nit と明記します
• FYI — 情報共有
• Positives — 評価すべき良いパターン
• Verified — 実行したもの（テスト、ビルド、実験）と、読むだけにとどめたもの

構造上の問題がひとつと Nit が10件ある場合、レビューの要点は構造上の問題です。それを先頭に記載します。最後に、承認基準に照らした判定を示して締めくくります。