review-changes

変更のレビュー

概要

リポジトリに文書化されたガイドラインに照らして、最近のコード変更をレビューします。

既定ではレビューを行い、具体的な違反、リスク、リグレッション、テスト不足を最初に指摘します。意味のある指摘がない場合に限り、問題がないことを簡潔に伝えます。

ワークフロー

1. 最新の変更セットを調べます。
2. プロジェクトのガイドライン（AGENTS.md、CLAUDE.md、またはそこから参照されているオンボーディング文書）の関連箇所を読みます。
3. 変更されたコードを直接読みます。
4. 一般的なスタイル上の意見ではなく、リポジトリのルールと実装を照らし合わせます。
5. ファイルへの参照を添えて、重要度の高い順に指摘事項を報告します。
6. 指摘事項がない場合は、その旨を明記し、残るリスクや検証上の不足があれば記載します。

変更セットの確認

レビューの依頼に答えるのに必要な、最小限の信頼できる情報源を優先します。

• git status --short
• git diff --stat
• git diff -- <path>
• git log -1 --stat
• git show <commit>

ユーザーがコミット済みの変更について尋ねている場合は、作業ツリーではなく、該当するコミットまたはコミット範囲をレビューします。

要約だけをもとにレビューしないでください。影響を受けるファイルを読みます。

レビューの重点項目

プロジェクトに文書化されたガイドラインをレビュー基準として使用します。特に以下に重点を置きます。

• プロジェクトのディレクトリ規約に沿った、適切なファイルと機能の配置
• ロジック、コンポーネント、フローの DRY と再利用
• プロジェクトで採用しているパターンに沿った状態管理
• プロジェクトの規約に沿った依存性注入とサービスの解決
• 確立されたパターンに合致するリポジトリとデータアクセスの契約
• 動作変更時にテストが追加または更新されているか
• 分割されないまま、おおむね 800 行を超えて増大したファイル

リポジトリに文書化された基準を超える独自の基準を作らないでください。ただし、変更がそれ自体で明らかに壊れている場合は除きます。

リポジトリ固有の確認事項

以下は重要度の高い確認事項として扱います。

• 重複したコンポーネント、または共有化・パラメーター化すべき酷似した UI
• ビューやコンポーネント内で場当たり的にインスタンス化された新しいサービスやリポジトリ
• 状態管理層や UI 層に漏れ出す生の例外
• ハードコードされたユーザー向けテキスト（プロジェクトで i18n を使用している場合）
• 動作変更に対応するテストの更新がないこと
• 分割すべき大きなファイル

素早く確認する必要がある場合は、以下のチェックリストを使用してください。

レビューチェックリスト

アーキテクチャ

• このコードは共有／コア層、またはそれを所有する機能のどちらに置くべきですか？
• 既存コードを再利用せず、共有される関心事を重複して実装していませんか？
• 分割されないまま、おおむね 800 行を超えて増大したファイルはありませんか？

状態管理

• 状態管理の手法は、プロジェクトで採用しているパターンに沿っていますか？
• 新しいパターンを導入した場合、それを正当化するだけの実際の複雑さがありますか？

データと DI

• 依存関係は場当たり的に構築せず、プロジェクトの DI システムを通じて解決していますか？
• リポジトリとデータアクセス層は、確立された契約に従っていますか？
• モックやテスト用の実装は、引き続き実際の契約に適合していますか？

UI と再利用

• 再利用すべき既存のコンポーネントはありませんか？
• 新しい UI を複製するのではなく、パラメーター化できますか？
• 複数の機能で利用できるよう、コンポーネントを共有コードに置くべきですか？

ユーザー向けの動作

• 表示されるテキストはすべてローカライズされていますか（プロジェクトで i18n を使用している場合）？
• 永続化の変更によって、部分的または不整合な状態が発生する可能性はありませんか？

テスト

• 動作変更に対してテストが更新されていませんか？
• 再利用可能な抽象化を変更した場合、既存の呼び出し元をテストで保護していますか？
• 検証が実行されていないために、残るリスクはありませんか？

出力形式

主な出力は指摘事項です。

各指摘事項について、次の内容を記載してください。

• 重大度
• 問題点
• プロジェクトのガイドラインに違反する理由、または具体的なリスクが生じる理由
• ファイル参照
• 修正方針の簡潔な提案

指摘事項の後に、必要に応じて次の内容を記載してください。

• 未解決の質問や前提
• 必要であれば、簡潔な概要

指摘事項がない場合は、その旨を明記してください。未実行のテスト、差分の確認範囲が不完全であること、実行時の動作を未検証であることなど、残存するリスクにも触れてください。

レビューの方針

• 一般的なベストプラクティスに基づく説明より、リポジトリ固有の理由を優先してください。
• ユーザーが別途ドキュメントの保守を依頼していない限り、ドキュメントの更新を求めないでください。
• リポジトリのルールを満たすために、局所的な修正で十分な場合は、大規模な書き換えを提案しないでください。
• アーキテクチャの逸脱、重複、テストの不足については厳密に指摘してください。
• 誤検知に注意し、指摘する前に、コードが実際にルールに違反していることを確認してください。