PRレビュー

実行手順

0. 入力の正規化（対象PRの特定）

PR番号/URL以外の形式で依頼された場合、まず対象PRを特定する:

• Slackリンク: Slack MCPでスレッドを読み、本文・返信からPR URLを抽出
• Confluenceリンク: ページを取得し、関連PRリンクを抽出
• ブランチ名のみ: gh pr list --head <branch> でPRを特定
• 複数PRが見つかった場合や特定できない場合は、推測せずユーザーに確認

1. PR情報の取得

# PR詳細を取得
gh pr view <番号> --json title,body,author,headRefName,baseRefName,files

# diffを確認（必要に応じて）
gh pr diff <番号>

2. checkout / worktreeの判断

ケース	対応
diff読解 + git grep/rg での静的確認で足りる	checkout不要（現在のブランチのまま）
ビルド・テスト実行・型チェック等の動的検証が必要	PJのworktree手段でPR headをcheckout（PJ CLAUDE.mdに定義された手段を使用）

注意: checkoutを省略した場合でも、手順3の「削除・リネームの残存確認」は必ず全リポジトリ検索で実施する（diffに現れないファイルの見落とし防止）。その際、現在のローカルツリーではなくPR headのツリーを検索対象にすること:

git fetch origin pull/<番号>/head
git grep -n "<identifier>" FETCH_HEAD

3. Claude Codeによるレビュー

変更された各ファイルについて:

1. ファイル全体を読む（diffだけでなく）
2. 既存パターンとの整合性を確認
3. 問題点を特定
4. 削除・リネームの残存確認（必須）: diffで削除・リネームされた識別子（メソッド名・クラス名・定数・env key・docker service名・キュー名・設定キー等）を git grep / rg でPR headのツリー全体から検索する（checkout済みならそのツリー、未checkoutなら手順2の git grep <pattern> FETCH_HEAD 方式）。検索対象にはコードだけでなくconfig / docker-compose / .env / CI定義 / docsを含める。残存があればCriticalに昇格（diff だけを見ると、config・compose・CI 定義に残った参照を見落とすため）
5. 削れるものの確認: 追加されたコードのうち、消せるもの（使われないコード・誰も設定しないオプション・先回りの機能）、リポジトリの既存の helper で置き換えられるもの（その helper のパスを示す）、標準ライブラリやプラットフォームの機能で足りるもの・数行のための新しい依存、実装が1つしかない抽象や素通しの wrapper、一緒に変える必要がある近い複製を挙げる。既定は Medium（バグ・セキュリティより優先しない）

4. 棄却と投稿前の裏取り

指摘を並べた直後に、投稿・報告する前に2段通す。

1. 棄却: ~/.claude/context/code-review-checklist.md §16の類型に該当するものを除外する。特に「退行でないもの」「diffの外」「PR本文がスコープ外と明示しているもの」「既存precedentと同形で悪化しないもの」「直しても部分的にしか消えないもの」は、事実として正しくても出さない。逆に「退行」と「PR本文が保留している判断の前提を一次ソースで確定させたもの」は必ず出す。

2. 裏取り: 残した指摘の根拠を一次情報で確認する。

• ライブラリ・ランタイム・DBの挙動に依存する主張は、型定義・公式ドキュメント・一般論で終わらせず実機で1回確かめる（ローカルDB・最小スクリプト）。上限値・エラー発生条件・デフォルト挙動はここで反証されることがある
• 数値を伴う主張は実測値にする（メモリ・件数・所要時間）。見積もりで書かない
• 確かめられなかったものは断定せず 〜ではないかと思います（おそらく） の表現に弱める。弱められないなら指摘そのものを取り下げる。逆に、ここで確かめた指摘（コードの経路を追った・実測した）は断定で書く。確かめていない部分があるなら、その部分だけをぼかす
• 設定値・タイムアウト・上限は該当リポジトリの実設定を読んで確認する（フレームワークの既定値を前提にしない）

5. 外部CLIによるレビュー

別モデルの観点を追加する。実行前に context/agent-cli-guide.md を Read し、CLI の選択と fallback・コマンド形式はそれに従う（Agent tool に fallback するときは model: "fable" を渡す）。プロンプト本文は共通で以下を渡す:

gh pr diff <番号> を実行してPR #<番号> の変更内容をレビューしてください。
- コードの品質（バグ、セキュリティ、パフォーマンス）
- 設計の妥当性
- テストの十分性
- ドキュメントの必要性

PR情報:
タイトル: <タイトル>
ブランチ: <ブランチ>

指摘がなければ「指摘なし」とだけ回答してください。

6. 結果の統合

Critical/High/Mediumが0件のときは、コメントのドラフトを作らずapproveだけを提示する（文面が必要なら明示の依頼を待つ）。GitHubのレビュー手順が「pending review → コメント追加 → submit」であっても、指摘がないなら承認だけで完結させる。

以下のレポート形式はユーザーへの提示用。GitHubへ投稿するときはこの形をそのまま貼らず、/ukwhatn-writing スキルを実行し、その GitHub 向けガイドの「レビュー本文と行コメントの役割分担」に従って、指摘を行コメントに割り、本文は交通整理1〜2文（または本文なし）にとどめる。

Claude Codeとagentの両方の指摘を統合し、以下の形式でレポート:

# PRレビュー: #<番号>

## 対象
- PR: #<番号> - <タイトル>
- ブランチ: <ブランチ> → <ベース>

## Claude Codeによる指摘

### Critical
- [指摘内容]

### High
- [指摘内容]

### Medium
- [指摘内容]

## agent（外部CLI）による指摘

### Critical
- [指摘内容]

### High
- [指摘内容]

### Medium
- [指摘内容]

## 統合サマリ

| 観点 | Claude Code | agent | 統合判断 |
|------|------------|--------|---------|
| セキュリティ | OK | OK | OK |
| パフォーマンス | 指摘あり | OK | 要確認 |

## 推奨アクション
1. [アクション1]
2. [アクション2]

## マージ推奨: [Yes/No/条件付き]

問題の分類

分類	説明	対応
Critical	バグ、セキュリティ、破壊的変更	マージ前に必須修正
High	アーキテクチャ違反、テスト不足	強く推奨
Medium	命名、コメント	改善推奨