explain-pr

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 を使う。

取得コマンド例

# {owner}, {repo}, {number} を置き換える
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 モード時のみ表示する。

議論の方向性

私が考える最適解： [複数の選択肢がある場合、どれが最適と考えるか]

理由：

• 技術的理由: [...]
• 保守性: [...]
• パフォーマンス: [...]
• チームの文脈: [...]

トレードオフ：

• メリット: [...]
• デメリット: [...]
• リスク: [...]

重要な指針

• ✅ 客観的に評価する（忖度しない）
• ✅ 複数の視点を提示する
• ✅ トレードオフを明示する
• ✅ わかりにくい専門用語は補足する
• ✅ 背景知識を丁寧に説明する
• ✅ 「なぜそう考えるか」を明確にする
• ✅ 代替案があれば提示する
• ✅ コメント者の意図を推測して補足する
• ✅ 日本語で説明する