メニュー
PRレビュー。PR番号・URL・ブランチ名・Slackリンク等を添えてPRの「レビュー」を依頼された時に使用（PRのレビュー依頼ではビルトインの/reviewでなく本スキルを使う。ローカル未コミット変更のレビュー→/code-review、自ブランチの提出前チェック→self-review、特定レビューコメントへの対応→pr-comment、PRの状態確認・PR作成相談では使わない）。Claude Codeと外部CLI（cursor agent / codex）のマルチモデルレビューでCritical/High/Medium分類の指摘を報告。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| 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分類の指摘を報告。 |
PR番号/URL以外の形式で依頼された場合、まず対象PRを特定する:
gh pr list --head <branch> でPRを特定# PR詳細を取得
gh pr view <番号> --json title,body,author,headRefName,baseRefName,files
# diffを確認（必要に応じて）
gh pr diff <番号>
| ケース | 対応 |
|---|---|
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
CLAUDE.mdを読み、以下を把握:
変更された各ファイルについて:
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ファイルのキュー定義残存を見落とし）別モデルの観点を追加する。CLI判定（cursor優先／codex fallback）・コマンド形式（--trust・--output-format json・jq抽出等）は @context/agent-cli-guide.md「使用するCLIの選択」「基本コマンド」に従う。プロンプト本文は両CLI共通で以下を渡す:
gh pr diff <番号> を実行してPR #<番号> の変更内容をレビューしてください。
- コードの品質（バグ、セキュリティ、パフォーマンス）
- 設計の妥当性
- テストの十分性
- ドキュメントの必要性
PR情報:
タイトル: <タイトル>
ブランチ: <ブランチ>
指摘がなければ「指摘なし」とだけ回答してください。
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 | 良い実装 | 賞賛 |
コードベース包括的レビュー。6観点（perf/sec/test/arch/cq/docs）を並列サブエージェントで実行し、優先度付きissueファイルをメモリディレクトリに生成。使用タイミング: コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review実行時。境界: PR単位のレビュー→pr-review、自ブランチの提出前確認→self-review、ローカル未コミット変更→/code-review、ドキュメントのレビュー→doc-review。
既存設定と整合したスキルを新規作成。「スキルを作って」「この手順をスキル化して」等の依頼時、/create-skill実行時に使用。~/.claude/AGENTS.md（CLAUDE.mdは互換symlink）、context/*.md、既存スキルを自動参照し、重複・競合を避けたスキルを生成。境界: 既存スキル・指示ファイルの修正→update-inst、指示ファイル全体の監査→instructions-audit。
抽象的な要件・Biz 要求から要求を深掘りし、コードベース SSoT で既存実装整合性を確認した上で「実装マスタ（01_requirements_skeleton.md）」と「システム要件書（02_system_requirements.md）」を作成する。使用タイミング (1)「○○って機能を作りたい」「このBiz要求を満たす機能を設計して」等の抽象要件提示時、(2) 既存機能の拡張・Phase 分割等の要件定義開始時、(3) `/design-feature ...` 実行時。
Agent Teamsによる多角的ドキュメントレビュー。設計書・仕様書・計画書等のドキュメントを6 Agent（通常4 + Devil's Advocate + agent CLI）で並列レビュー。使用タイミング: (1) /doc-review 明示実行時、(2) 「チームでレビューして」「多角的にレビューして」等の明示依頼時（Agent Teams発動条件(c)相当）。通常の「レビューして」だけの依頼では発火しない（単独レビューまたはagent CLIで対応し、必要なら本スキルを提案する）。
既存の計画・設計・アイデアを徹底的に尋問し、共有理解に至るまでストレステストする対話スキル。使用タイミング: (1) 「グリルして」「grillして」「この計画を詰めて」「計画の穴を突いて」「ストレステストして」等の依頼時、(2) 実装着手前に計画・設計の前提や未決定事項を洗い出したい時。境界: ゼロからの要件定義・要件書作成→design-feature、完成した文書の多角的レビュー→doc-review。本スキルは既に存在する計画・アイデアの対話的な検証を行う。要件書等の成果物は生成せず、確定した重要決定のみADRとして.local/docs/に記録する。
現在のセッション内容を、別セッションのエージェントが引き継げるハンドオフ文書に圧縮し、メモリディレクトリに書き出す。セッションを切り替えたい時・作業を中断して後日再開したい時に /handoff で実行。