| name | explain-pr |
| description | Pull Requestを客観的に分析・解説する。PR内容、コメント、技術的妥当性を評価し、忖度なしで総合的な意見を提示する。設計原則との整合性もチェックし、代替案やトレードオフを明示する。 |
| argument-hint | [PR番号またはURL] [--all] |
| allowed-tools | Bash, Read, mcp__acp__Read |
| disable-model-invocation | false |
PR解説スキル
Pull Request(PR)について、客観的に分析・解説します。
引数の扱い
引数は [PR番号またはURL] [--all] の形式で受け取る。
- デフォルト(
--all なし): 未resolveのレビューコメントのみを対象に分析する
--all を含む場合: resolve状態に関わらず、すべてのコメントを対象に分析する
冒頭で対象モードを明示する。
モード: 未resolveのみ / 全件 ( --all )
ステップ0: レビューコメントの取得とフィルタリング
GitHub REST API はレビュースレッドのresolve状態を返さないため、resolve状態を含めて取得するには GraphQL を使う。
取得コマンド例
gh api graphql -f query='
query($owner: String!, $repo: String!, $number: Int!) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $number) {
reviewThreads(first: 100) {
nodes {
isResolved
isOutdated
path
comments(first: 50) {
nodes {
databaseId
author { login }
body
path
line
originalLine
diffHunk
createdAt
}
}
}
}
}
}
}' -F owner={owner} -F repo={repo} -F number={number}
一般コメント(コードに紐づかない issue comments)は gh pr view {number} --json comments で取得する。一般コメントには resolve 概念がないため、モードに関わらず常に全件を扱う。
フィルタリングルール
- デフォルト:
reviewThreads.nodes[] のうち isResolved == false のスレッドのみ採用
--all: reviewThreads.nodes[] のすべてを採用し、各コメントに resolved=true/false を併記する
採用したレビュースレッドに含まれる各コメントを「ステップ2: コードに紐づくコメント」のテンプレートに流し込む。
ステップ1: PR情報の収集
基本情報
- PR番号: [...]
- タイトル: [...]
- 目的: [...]
- 変更ファイル数: [...]
変更内容の概要
[変更の要約]
ステップ2: コメントの分類と整理
コードに紐づくコメント(Line Comments)
各コメントについて:
コメント1: [ファイル名:行番号]
スレッド状態: resolved=true/false (--all モード時のみ表示。デフォルトモードでは全件未resolveなので省略)
コメント内容:
[元のコメント全文]
該当コード:
[コメントが指している部分のコード]
コメントの意図:
[このコメントは何を指摘しているか]
わかりづらい部分の補足:
[専門用語、暗黙の前提、背景知識などを補足]
客観的な評価:
- 指摘の妥当性: [...]
- 重要度: 高/中/低
- 代替案の有無: [...]
- 私の考え: [...]
コードに紐づかない一般コメント(General Comments)
コメント1
コメント内容:
[元のコメント全文]
コメントの意図:
[何について言及しているか]
補足説明:
[文脈や背景の説明]
客観的な評価:
- 指摘の妥当性: [...]
- 重要度: 高/中/低
- 私の考え: [...]
ステップ3: 各コメントへの客観的な評価
技術的観点
各コメントについて、以下の観点で評価:
[コメントID]
指摘内容: [...]
技術的妥当性:
- ✅ 正しい指摘
- ⚠️ 一理あるが、状況による
- ❌ 誤解または不適切
理由:
[なぜそう評価するか]
代替案:
[もし別のアプローチがあれば]
私の意見:
[忖度なしの客観的な考え]
- 賛成/反対/条件付き賛成
- 理由: [...]
- トレードオフ: [...]
設計・アーキテクチャ観点
[コメントID]
指摘内容: [...]
設計原則との整合性:
- 単一責任原則: [...]
- 依存性逆転: [...]
- 関心の分離: [...]
- その他: [...]
私の意見:
[設計判断として適切か、他の選択肢はあるか]
ステップ4: 補足が必要な技術的背景
コメントを理解する上で必要な背景知識:
技術用語・概念
設計パターン
プロジェクト固有の文脈
ステップ5: 総合的な意見(忖度なし)
PR変更内容について
評価: 適切/要改善/要大幅修正
理由:
[...]
推奨対応:
[...]
レビューコメントについて
各コメントへの総合的な意見:
| コメント | resolved | 妥当性 | 重要度 | 対応推奨 | 理由 |
|---|
| [ID] | true/false | ✅/⚠️/❌ | 高/中/低 | 必須/推奨/任意 | [...] |
resolved 列はデフォルトモードでは全て false になるので省略可。--all モード時のみ表示する。
議論の方向性
私が考える最適解:
[複数の選択肢がある場合、どれが最適と考えるか]
理由:
- 技術的理由: [...]
- 保守性: [...]
- パフォーマンス: [...]
- チームの文脈: [...]
トレードオフ:
- メリット: [...]
- デメリット: [...]
- リスク: [...]
重要な指針
- ✅ 客観的に評価する(忖度しない)
- ✅ 複数の視点を提示する
- ✅ トレードオフを明示する
- ✅ わかりにくい専門用語は補足する
- ✅ 背景知識を丁寧に説明する
- ✅ 「なぜそう考えるか」を明確にする
- ✅ 代替案があれば提示する
- ✅ コメント者の意図を推測して補足する
- ✅ 日本語で説明する