Pr Review

---
name: pr-review
description: PRレビュー。PR番号・URL・ブランチ名・Slackリンク等を添えてPRの「レビュー」を依頼された時に使用（PRのレビュー依頼ではビルトインの/reviewでなく本スキルを使う。ローカル未コミット変更のレビュー→/code-review、自ブランチの提出前チェック→self-review、特定レビューコメントへの対応→pr-comment、PRの状態確認・PR作成相談では使わない）。Claude Codeと外部CLI（codex / cursor agent）のマルチモデルレビューでCritical/High/Medium分類の指摘を報告。
allowed-tools: Read, Grep, Bash(gh:*), Bash(git:*)
---

# PRレビュー

## トリガー条件

- PRのレビューを依頼された場合（「レビューして」「見ておいて」等）
- 対象はPR番号・URL・ブランチ名・Slack/Confluenceリンクのいずれでも指定され得る
- 非トリガー: PRのCI状態確認、マージ可否の事務確認、PR作成の相談

## 実行手順

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

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

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

### 1. PR情報の取得

```bash
# 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を省略した場合でも、Step 4の「削除・リネームの残存確認」は必ず全リポジトリ検索で実施する（diffに現れないファイルの見落とし防止）。その際、現在のローカルツリーではなく**PR headのツリーを検索対象にする**こと:

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

### 3. PJルールの確認

CLAUDE.mdを読み、以下を把握:
- アーキテクチャルール
- 命名規則
- コーディング規約

### 4. Claude Codeによるレビュー

変更された各ファイルについて:
1. ファイル全体を読む（diffだけでなく）
2. 既存パターンとの整合性を確認
3. 問題点を特定
4. **削除・リネームの残存確認（必須）**: diffで削除・リネームされた識別子（メソッド名・クラス名・定数・env key・docker service名・キュー名・設定キー等）を `git grep` / `rg` で**PR headのツリー全体**から検索する（checkout済みならそのツリー、未checkoutなら Step 2 の `git grep <pattern> FETCH_HEAD` 方式）。検索対象にはコードだけでなく config / docker-compose / .env / CI定義 / docs を含める。残存があればCriticalに昇格（過去実績: diffのみの確認でdocker-compose 2ファイルのキュー定義残存を見落とし）

### 4.5 棄却と投稿前の裏取り

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

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

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

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

### 5. 外部CLIによるレビュー（codex優先 / cursor fallback）

別モデルの観点を追加する。CLI判定（codex優先／cursor fallback、両方使えなければ fable subagent）・コマンド形式（codexの`-c model_reasoning_effort`・cursorの`--trust`／`--output-format json`・jq抽出等）は @context/agent-cli-guide.md「使用するCLIの選択」「基本コマンド」に従う。プロンプト本文は共通で以下を渡す:

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

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

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

### 6. 結果の統合

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

以下のレポート形式は**ユーザーへの提示用**。GitHubへ投稿するときはこの形をそのまま貼らず、`skills/ukwhatn-writing/references/github.md`「2-0. レビュー本文と行コメントの役割分担」に従って、指摘を行コメントに割り、本文は交通整理1〜2文（または本文なし）に落とす。

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

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

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

## Claude Codeによる指摘

### Critical
- [指摘内容]

### High
- [指摘内容]

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

### Critical
- [指摘内容]

### High
- [指摘内容]

## 統合サマリ

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

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

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

## 問題の分類

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