| name | pr-review |
| description | PRレビュー。PR番号・URL・ブランチ名・Slackリンク等を添えてPRの「レビュー」を依頼された時に使用（PRのレビュー依頼ではビルトインの/reviewでなく本スキルを使う。ローカル未コミット変更のレビュー→/code-review、自ブランチの提出前チェック→self-review、特定レビューコメントへの対応→pr-comment、PRの状態確認・PR作成相談では使わない）。Claude Codeと外部CLI（cursor agent / codex）のマルチモデルレビューで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情報の取得
gh pr view <番号> --json title,body,author,headRefName,baseRefName,files
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のツリーを検索対象にすること:
git fetch origin pull/<番号>/head
git grep -n "<identifier>" FETCH_HEAD
3. PJルールの確認
CLAUDE.mdを読み、以下を把握:
4. Claude Codeによるレビュー
変更された各ファイルについて:
- ファイル全体を読む（diffだけでなく）
- 既存パターンとの整合性を確認
- 問題点を特定
- 削除・リネームの残存確認（必須）: 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によるレビュー（cursor優先 / codex fallback）
別モデルの観点を追加する。CLI判定（cursor優先／codex fallback）・コマンド形式（--trust・--output-format json・jq抽出等）は @context/agent-cli-guide.md「使用するCLIの選択」「基本コマンド」に従う。プロンプト本文は両CLI共通で以下を渡す:
gh pr diff <番号> を実行してPR #<番号> の変更内容をレビューしてください。
- コードの品質（バグ、セキュリティ、パフォーマンス）
- 設計の妥当性
- テストの十分性
- ドキュメントの必要性
PR情報:
タイトル: <タイトル>
ブランチ: <ブランチ>
指摘がなければ「指摘なし」とだけ回答してください。
6. 結果の統合
以下のレポート形式はユーザーへの提示用。GitHubへ投稿するときはこの形をそのまま貼らず、skills/ukwhatn-writing/references/github.md「2-0. レビュー本文と行コメントの役割分担」に従って、指摘を行コメントに割り、本文は交通整理1〜2文（または本文なし）に落とす。
Claude Codeとagentの両方の指摘を統合し、以下の形式でレポート:
# 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 | 良い実装 | 賞賛 |
