| name | review-all |
| description | PRを3つの観点(アーキテクチャ・テックリード・デグレ)で並列レビューし、指摘を統合・重複排除して一発で全指摘を出す。 |
PR #$ARGUMENTS の総合レビューを実行する。PR番号が空の場合、今のブランチのPRをレビューする。PRにコメントはしないこと。
差分を取得する前に、必ず BASE=$(bash ~/.claude/docs/get-base-branch.sh) を実行してベースブランチを特定し、git diff ${BASE}...HEAD で差分を取得すること。developやmainを勝手に仮定しないこと。
実行方法
3つのSub Agent(general-purpose)を並列で起動し、それぞれ異なる観点でレビューさせる。各Agentには以下を共通で伝えること:
- PRの差分(
gh pr diffまたはベースブランチとのgit diffの結果)
- 変更ファイルの一覧
- PRの説明文
- 「PRにコメントはしないこと。結果をテキストで返すこと。」
Agent 1: アーキテクチャ観点
以下の観点で包括的に評価する:
-
アーキテクチャレベルの評価
- この機能はアプリケーション層で実装すべきか?
- インフラ層(API Gateway、ロードバランサー等)での実装との比較
- 既存のアーキテクチャとの整合性
-
実装の必要性
- この機能は本当に必要か?
- 問題の本質的な解決になっているか?
- より良い代替案はないか?
-
長期的な視点
- 保守性とメンテナンス性
- 将来的な拡張性
- 技術的負債になる可能性
-
ベストプラクティスとの比較
- 業界標準のアプローチとの違い
- フレームワークのベストプラクティスに従っているか
Agent 2: テックリード観点
テックリードとして、以下を重点的にチェックする:
-
コードの品質と正確性
- ロジックの正しさ
- エッジケースの考慮
- エラーハンドリングの適切性
-
パフォーマンスへの影響
- N+1クエリ、不要なループ、重い処理
- メモリ使用量、DB負荷
-
セキュリティ面
-
設定の柔軟性と運用面
- 環境変数等の設定
- モニタリング・ログ出力
- トラブルシューティングの容易さ
Agent 3: デグレ観点
既存機能が壊れていないかを重点的に確認する:
-
既存機能への影響
- 変更されたファイルを使用している他の箇所の確認
- 公開API/インターフェースの変更有無
- 型の変更による影響範囲
-
データの整合性
- DB変更がある場合、既存データへの影響
- マイグレーションの安全性
-
依存関係
- 削除・変更された関数/メソッドの呼び出し元
- import/exportの変更による影響
-
テストへの影響
結果の統合
3つのAgentの結果を受け取ったら、以下の手順で統合する:
Step 1: 重複排除
同じファイル・同じ箇所への類似指摘は1つにマージする。最も具体的な指摘を残す。
Step 2: 指摘の仕分け
全指摘を以下の4分類でラベル付けする:
- [必須] 実行時エラー、データ不整合、CIブレーク、セキュリティリスク
- [原則修正] 命名不一致、重複コード、既存ライブラリで代替可能、ファイル分離
- [人間確認] 設計判断、パフォーマンス改善、コスト影響、複数案の選択
- [原則無視] 壊れないスタイル的指摘、YAGNI的提案、eslint警告の機械的報告
Step 3: 出力フォーマット
## 総合レビュー結果
### [必須] (X件)
| # | 観点 | ファイル | 指摘 | 修正案 |
|---|---|---|---|---|
| 1 | arch/tekku/degure | path/to/file.ts:L10 | 内容 | 具体的な修正方法 |
### [原則修正] (X件)
| # | 観点 | ファイル | 指摘 | 修正案 |
|---|---|---|---|---|
| 1 | arch/tekku/degure | path/to/file.ts:L10 | 内容 | 具体的な修正方法 |
### [人間確認] (X件)
| # | 観点 | ファイル | 指摘 | 判断ポイント |
|---|---|---|---|---|
| 1 | arch/tekku/degure | path/to/file.ts:L10 | 内容 | 何を基準に判断すべきか |
### サマリー
- 必須: X件
- 原則修正: X件
- 人間確認: X件
- 無視(除外済み): X件
禁止事項
- 分析対象を確認せずに提案しない
- フレームワーク規約に反する提案をしない
- UIの配置・見た目を推測で提案しない
- 運用実態を無視した仮説を出さない
- 一般論だけで設計提案しない
- [原則無視]に該当する指摘は出力しない