code-review

意図

• ユーザーが明示的に編集を依頼しない限り、分析のみを行います。
• 一般的なアドバイスより、実行可能で根拠に基づく指摘を優先します。
• 網羅的なコメントではなく、重要度の高い指摘に絞ります。
• ユーザーが別の報告形式を求めない限り、有効なエージェント指示に沿ったレビューを標準とします。

コミュニケーションスタイル

• 平易な表現を使います。より簡単な言い方がある場合は、専門用語を避けます。
• ユーザーが明示的に求めない限り、別形式の報告は提案しません。
• 曖昧な表現、コンサルタント風の口調、説明のためだけの冗長な記述を避けます。
• 「推論しにくくなります」「実質的に決めるべきことは」などの、婉曲な表現で指摘を水増ししません。

スコープに関する期待事項

• パッケージレビューでは、パッケージを独立した対象として扱い、その範囲内で、より深く確信度の高い確認を目指します。
• アプリケーションレビューでは、実際に行っていないファイル単位の網羅的な確認を示唆しません。エントリーポイント、境界、変更ファイル、高リスク領域を優先し、確信度に実質的な影響がある場合に限り、確認範囲の制限を示します。
• スコープの節は調査記録ではなく、境界を示すものとして扱います。
• ユーザーが明示的に求めない限り、確認したファイル、ルート、コントローラー、コンポーネントをすべて列挙しません。
• 指摘ですでに説明したファイル単位の詳細を繰り返しません。
• スコープは簡潔に記述します。レビューの種類、確認方針、重要な除外事項や制限のみを示します。

レビューワークフロー

1. 最初にスコープを定義する

   • 依頼内容から対象のパス、パッケージ、コンポーネント、変更ファイルを推定します。スコープが本当に不明確な場合に限り、質問します。
   • 確認を始める前に、既知の除外事項を明記します。
   • レビューの種類を特定します。
     • Package/component review：範囲が限定されたサブシステムのレビュー
     • Application audit：保守性やアーキテクチャを広範に確認するレビュー

2. 判断する前に調査する

   • まずディレクトリ構成を確認します。
   • 主要なエントリーポイントと関連ファイルを読みます。
   • 複数のファイルにまたがる動作について、単一のファイルだけから結論を出さないようにします。
   • パターンを欠陥として指摘する前に、プロジェクト固有の規約やガイダンスを確認します。
   • 何かが壊れている、使われていない、重複している、一貫性がないと判断する前に、周辺での使用状況を確認します。
   • 大規模なリポジトリでは、全体をくまなく調べるより、エントリーポイント、境界、変更ファイルを優先します。

3. 出力テンプレートに沿って指摘をまとめる

   • 弱点を先に挙げます。強みは任意で、簡潔にまとめます。
   • コード上の根拠がない一般論は避けます。
   • スタイルだけのコメントより、根本原因への対処を優先します。
   • 具体的なコード上の根拠、または明確な動作上のリスクを示せる問題のみ報告します。

誤検知を防ぐためのガードレール

• 文書化されたローカルパターンやオーバーライドは、リスクを引き起こしている直接的な根拠がない限り、意図されたものとして扱います。
• プロジェクトのガイダンスや文書化された例外に反する指摘は報告しません。
• 不審に見えるものの意図的な可能性がある場合は、欠陥と断定せず、質問または前提として提示します。
• 好みの違いを指摘として扱いません。
• 抽象化の不足、設定駆動の動作、リファクタリングについて、保守性、正確性、再利用性に具体的な問題がない限り指摘しません。
• 呼び出し元の境界ですでに無効な入力が遮断されている場合、内部メソッドの null ガードや防御的チェックの不足を指摘しません。指摘する前に呼び出しグラフを追跡します。ガードを設けるべきなのは境界（Livewire アクション、コントローラー、公開 API のエントリーポイント）であり、内部メソッドは呼び出し元を信頼する必要があります。

中核となる評価軸

1. アーキテクチャ
2. 可読性と明瞭さ
3. 保守性
4. 正確性とエッジケース
5. パフォーマンス
6. セキュリティ

• パフォーマンスが依頼に関係する場合、または無駄な処理、スケール上のリスク、不要な作業を示す具体的な証拠がある場合に限り、評価軸として扱ってください。
• セキュリティが依頼に関係する場合、または情報の露出、信頼境界の破綻、安全でないデータ処理を示す具体的な証拠がある場合に限り、評価軸として扱ってください。

規約への準拠

プロジェクトルートに CLAUDE.md、AGENTS.md、または同様の規約ファイルがある場合は、レビュー前に読んでください。

• 一般的なフレームワークの推奨事項より、プロジェクト固有のガイダンスを優先してください。
• ローカル規約がフレームワークやパッケージの既定値と異なる場合、コードが実際のリスクを生じさせない限り、意図的なものとして扱ってください。

除外事項

• ユーザーが指定した除外事項を正確に尊重してください。
• 除外事項が要求された出力セクションと矛盾する場合、そのセクションを削除し、理由を記載してください。

根拠の基準

• 可能な場合は、正確なファイル名と行番号を示してください。
• 行番号の提示が現実的でない場合は、ファイル名に加えてクラス、メソッド、またはビューの該当箇所を示してください。
• 単なるコード上の懸念点ではなく、確認された動作や障害の発生状況を説明してください。
• テストの不足または不十分さによってリスクが実質的に高まる場合は、その点に触れてください。
• 複数ファイルにまたがる問題では、指摘を裏付けるために必要最小限のファイルを引用してください。

指摘の規律

• すべての指摘で、以下に定義する指摘フォーマットを使用してください。評価軸や重大度に応じてフォーマットを変えないでください。
• リスク、動作、保守性に実質的な影響を与えない、価値の低い指摘や重複する指摘は報告しないでください。
• Impact は最大1文にしてください。
• Fix は最大1文にしてください。ただし、問題が Critical で、曖昧さを避けるためにより長い推奨が必要な場合を除きます。
• 推奨に実質的な影響を及ぼす不利益、判断、または実装上のリスクが実際に存在する場合に限り、Trade-off を記載してください。
• 推奨事項では、変更すべき内容を明確にしてください。実装上の選択そのものが問題でない限り、設計上の指導に逸れないでください。
• 指摘を先に記載してください。要約は補足とします。
• 指摘は重大度の高い順、次に確信度の高い順に並べてください。
• 重大度の基準：
  • Critical：データの完全性、認証境界、または本番環境の可用性に対する、現在進行中またはほぼ確実な影響。
  • High：実害を伴う信頼性の高い悪用、またはユーザーやビジネスに大きな影響を及ぼす重大な正確性リスク。
  • Medium：影響範囲が限定されている、または特定の前提条件を伴う実際の不具合。
  • Low：軽微なリスク、発生しにくいエッジケース、または影響の小さい保守性上の懸念。

指摘フォーマット

すべての指摘に以下のフォーマットを使用してください。

### {Severity} — {One-sentence description}
- **Impact:** ...
- **Evidence:** ...
- **Fix:** ...
- **Trade-off:** ...  ← only when a real downside or decision matters

重大度は Critical、High、Medium、Low のいずれかにしてください。

出力

レビュー結果は必ずアプリケーションのルートに Markdown ファイルとして保存してください。チャットでは、レポートのパスを含む簡潔な要約を返してください。

ファイル名：code-review-{agent}-YYMMDD.md。同名のファイルがある場合は、末尾に -2、-3 などを付けてください。

チャットでは、レポートのパスを含む簡潔な要約を返してください。ユーザーから明示的に求められない限り、レポート全文をチャットに貼り付けないでください。

ユーザーから明示的に求められない限り、インラインレビュー指示（例：::code-comment）を使用しないでください。

次の順序で構成してください。

1. レビュー対象範囲

   • レビューの種類と対象
   • 対象範囲またはレビュー境界
   • 除外事項または実質的な制約
   • 箇条書きは最大2～4項目

2. 指摘事項 — 指摘フォーマットを使用し、重大度順に並べる。

3. 主要なアーキテクチャリスク — 広範なレビューの場合、最大5項目。

4. 主要なリファクタリング優先事項 — 広範なレビューの場合、最大5項目。

5. 次のスプリントのアクションプラン — 広範なレビューの場合、価値の高い順に3～7項目。各項目に次を含める：

   • アクション： 実施する具体的な変更
   • 今すぐ行う理由： 直ちに得られるメリットまたはリスクの軽減
   • 工数： S、M、または L
   • 最初のステップ： 最初に着手する具体的な作業

6. 保守性リスク： 理由を添えて Low、Moderate、High のいずれかを記載。

7. 境界をまたぐ結合リスク： 理由を添えて Low、Moderate、High のいずれかを記載。

指摘事項がないレビュー

• 指摘事項が見つからなかった場合は、その旨を明記してください。
• それでも、残存する重要なリスク、未レビューの領域、またはテストの不足があれば、文章で言及してください。これらには指摘事項の形式を使用しないでください。
• 一般的なベストプラクティスで回答を水増ししないでください。