review-pr

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情報取得

# 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の場合は観点を自動調整（テンプレート品質重視）