review

レビュー — デプロイ前のセキュリティ・品質チェック

保留中のすべての変更をレビューし、セキュリティの脆弱性、認証情報の漏えい、品質上の問題を確認します。

手順

1. 変更を集める：

   • git diff（ステージングされていない変更）と git diff --staged（ステージング済みの変更）
   • ローカルの変更がない場合は、ベースブランチとの差分を確認します：git diff main...HEAD（または master）

2. セキュリティスキャン — 差分で以下を確認します：

   • 認証情報の漏えい：API キー、パスワード、トークン、シークレット、ソースにハードコードされた .env の値
   • SQL インジェクション：パラメーター化せずにクエリへ渡されている、生のユーザー入力
   • XSS：HTML/JSX にエスケープされずに出力されるユーザー入力
   • コマンドインジェクション：シェルコマンドに渡されるユーザー入力
   • IDOR：ID でリソースにアクセスするエンドポイントにおける、認可チェックの欠如
   • デバッグコード：var_dump、機密データを出力する console.log、dd()、残された die() 呼び出し
   • .env の変更：.env が変更されていたら報告します。通常、コミットすべきではありません
   • API キーの露出：LLM API キー（OpenAI、Anthropic）、決済キー（Stripe）、クライアント側コードにハードコードされた認証シークレット
   • プロンプトインジェクション：サニタイズせずにユーザー入力を LLM のプロンプトへ直接連結している箇所
   • SSRF：検証されずに、ユーザーが指定した URL がサーバー側の fetch/curl に渡されている箇所

3. 品質スキャン — 以下を確認します：

   • 未完成の実装（新しいコード内の TODO/FIXME/HACK コメント）
   • エラーハンドリングの不足（空の catch ブロック、握りつぶされた例外）
   • 明らかなロジックエラー
   • 誤って含められたように見えるファイル（.DS_Store、node_modules、コンパイル済みアセット）

4. 報告：

   • 問題が見つかった場合：それぞれについてファイル、行番号、重大度（CRITICAL / WARNING / INFO）を記載します
   • 問題がない場合：「すべて問題なし」と一行で確認します
   • 簡潔に報告し、余計な内容は含めません

ルール

• レビュー中はコードを絶対に変更せず、問題の報告のみ行います
• コードベース全体ではなく、差分に注目します
• CRITICAL の問題＝デプロイ前に必ず修正（認証情報、インジェクション、認証のバイパス）
• WARNING＝修正を推奨（デバッグコード、エラーハンドリングの不足）
• INFO＝修正すると望ましい（スタイル、軽微な改善）
• 差分が非常に大きい場合（50 ファイル以上）は、Explore エージェントに委任します