code-review

コードレビュー

基本姿勢

• 依頼された内容だけをレビューします。範囲が不明確な場合は、確認してください。
• 深く調べ、報告は絞ります。現実的な入力、状態、手順でコードが壊れる状況を試してください。批判するのは作業内容であり、作者ではありません。
• 「変更すべき点はありません」という結果も有効です。短いレビューは良いレビューです。
• 依頼されていない限り、コードを編集しないでください。

指摘事項に該当する条件

以下の条件をすべて満たす場合にのみ報告してください。

• 具体的に失敗する、または害を及ぼす状況がある。
• その状況が現実的に起こり得る。
• ユーザー、データ、セキュリティ、または保守に実際の影響がある。
• 修正によって、修正がもたらすリスクや複雑さよりも大きなリスクを取り除ける。

ニッチなエッジケース、仮定上の規模、スタイルの好み、問題のない重複、ヘルパーやファイルの数、「より柔軟にする」ためのアイデアは、決して報告しないでください。

確認する点

変更内容に当てはまる項目を確認してください。

• **正確性：**誤った前提、エラー処理、競合や非同期処理の順序、状態とクリーンアップ、リファクタリングで失われた動作。
• **セキュリティ：**認証と認可、インジェクション、クライアント入力への過信、コード・ログ・URL 内のシークレットや個人データ。
• **ライブラリ：**記憶に頼らず、インストール済みバージョンの型定義とドキュメントに照らして動作を確認してください。
• **テスト：**重要な動作を保護できているかを確認します。実際の動作に関するカバレッジの欠如、実装の詳細に対するアサーション、過剰なモック、何も証明しないまま成功するテストを指摘してください。テストを求めること自体を目的にしないでください。
• **データと API：**破壊的変更、マイグレーション、安全に繰り返せない副作用のリトライ。
• **UI：**実行可能な場合は、agent-browser を使って実際のブラウザーで変更された画面を操作してください。
• **複雑さ：**不要なレイヤーやラッパー、一度しか使わないヘルパー、先回りしたオプションや汎用 API、起こり得ない状況に対する防御的コード。優先順位は、削除、直接利用、ローカルヘルパー、共有の抽象化、新たな抽象化の順です。
• **計画と ADR：**変更が計画を実装する場合、未対応または未検証の計画項目や、承認済み ADR との矛盾を報告してください。

報告

指摘事項は、重大なものから順にチャットで報告してください。各指摘には、深刻度（high、medium、low）、file:line、何がどのような場合に起こるか、最小限の修正方法を記載してください。細かな指摘は省略してください。軽微な問題が多数ある場合は、列挙せずに一行でまとめてください。