| name | review-pr |
| description | PRコードレビュー。複数の観点（ロジック・セキュリティ・パフォーマンス・設計整合性）で
並列レビューし、統合結果を出力する。
「PRをレビューして」「このPRの問題点を見て」「PR#123を確認して」
「コードレビューして」などのリクエストで使用する。
PR番号・URL指定、またはカレントブランチのPRを自動検出する。
|
review-pr — PRコードレビュー
PRの差分を複数の観点で並列レビューし、統合結果を出力する。
APIキー不要（Claude Codeがローカルで実行）。
トリガー
/review-pr — カレントブランチのPR、またはURLを指定/review-pr 123 — PR番号を指定/review-pr https://github.com/owner/repo/pull/123 — URLを指定- 「PRをレビューして」「このPRの問題点を見て」
入力
- PR番号、URL、またはなし（カレントブランチのPRを自動検出）
実行フロー
Step 1: PR情報取得
gh pr view {PR_NUMBER} --json title,body,baseRefName,headRefName,url,files
gh pr view --json title,body,baseRefName,headRefName,url,files
gh pr diff {PR_NUMBER}
Step 2: 並列レビュー（5つのサブエージェントを同時起動）
以下の5つのAgentを並列で起動する。各Agentには差分全文とPR情報を渡す。
Agent 1: セキュリティレビュー
観点:
- XSS脆弱性（
dangerouslySetInnerHTML、未サニタイズ入力）
- SQLインジェクション（Prisma
$queryRaw での未サニタイズ入力）
- 認証・認可バイパス（Guard欠落、JWT検証漏れ）
- 機密情報ハードコード（APIキー、パスワード、トークン）
- SSRF・パストラバーサル
出力形式:
重大度: CRITICAL / HIGH / MEDIUM / LOW / NONE
指摘一覧:
- [重大度] ファイル:行番号 — 指摘内容
Agent 2: コード品質レビュー
観点:
- TypeScript型安全性（
any 乱用、不適切な型アサーション）
- エラーハンドリング（例外握りつぶし、ユーザー通知漏れ）
- 命名規則（PascalCase/camelCase/UPPER_SNAKE）
- コード重複・デッドコード
- パフォーマンス（N+1、不要な再レンダリング、メモリリーク）
出力形式:
品質スコア: A / B / C / D
指摘一覧:
- [重要度] ファイル:行番号 — 指摘内容
Agent 3: アーキテクチャレビュー
観点:
- レイヤー分離（Controller → Usecase → Service の責務境界）
- コンポーネント分割（1ファイル300行超、責務過多）
- 状態管理（Recoil atom粒度、不要なグローバル状態）
- 依存方向（上位→下位の一方向か、循環依存がないか）
- API設計（RESTful規約、レスポンス形式の一貫性）
出力形式:
懸念レベル: NONE / MINOR / MODERATE / MAJOR
指摘一覧:
- [懸念度] ファイル — 指摘内容
Agent 4: ドメイン・ビジネスロジックレビュー
観点:
- ドメインロジックの配置（ビジネスルールがController/UIに漏れていないか、Service層に集約されているか）
- 集約の境界（1つのトランザクションで複数の集約ルートを跨いでいないか）
- ドメイン知識の散在（同じビジネスルールが複数箇所に重複実装されていないか）
- 値オブジェクト/エンティティの区別（IDで識別すべきものと値で比較すべきものが混同されていないか）
- ユビキタス言語（コード上の命名が業務用語と乖離していないか、英語/日本語が混在していないか）
- 暗黙のドメインルール（マジックナンバー、ハードコードされた業務条件がないか）
- 外部サービス依存（ドメインロジックが外部API（CloudLogi等）の詳細に直接依存していないか、ポート/アダプタが分離されているか）
出力形式:
ドメイン健全性: GOOD / FAIR / POOR / CRITICAL
指摘一覧:
- [重要度] ファイル:行番号 — 指摘内容（どのドメインルールに違反しているか）
Agent 5: テスト・ドキュメントレビュー
観点:
- テスト更新漏れ（ロジック変更にテスト追加があるか）
- テストデータ安全性（本番データ、個人情報の混入）
- E2Eテスト影響（UI変更でセレクタが壊れていないか）
- ドキュメント更新漏れ（API変更にSwaggerデコレータ更新があるか）
出力形式:
カバレッジ懸念: NONE / LOW / MEDIUM / HIGH
指摘一覧:
- [重要度] ファイル — 指摘内容
Step 3: 結果統合
5つのAgentの結果を統合し、以下の形式で出力する:
## 🤖 コードレビュー結果
**PR:** #{番号} {タイトル}
**判定:** ✅ 承認 / ⚠️ 要修正 / ❌ 差し戻し
### サマリー
{全体の1-2行サマリー}
### セキュリティ {重大度アイコン}
{指摘一覧 or "問題なし"}
### コード品質 {品質スコア}
{指摘一覧 or "問題なし"}
### アーキテクチャ {懸念アイコン}
{指摘一覧 or "問題なし"}
### テスト・ドキュメント {カバレッジアイコン}
{指摘一覧 or "問題なし"}
判定基準
- 承認: セキュリティCRITICAL/HIGHが0件 かつ ドメインCRITICALが0件 かつ 他の重大指摘が0件
- 要修正: セキュリティMEDIUM以上が1件以上、またはドメインPOOR以下、または品質D以下
- 差し戻し: セキュリティCRITICALが1件以上、またはドメインCRITICAL、またはアーキテクチャMAJOR
Step 4: GitHubコメント投稿（オプション）
ユーザーが「コメントして」「PRに投稿して」と指示した場合のみ:
gh pr comment {PR_NUMBER} --body "$(cat review-result.md)"
注意事項
- 差分が10,000行を超える場合は変更ファイル一覧を表示して対象を絞る
- バイナリファイル（画像、Excel等）はスキップ
node_modules/、package-lock.json、.prisma/ の変更は無視- テンプレートリポ（
yamasaki）のPRの場合は観点を自動調整（テンプレート品質重視）
