pr-review

name	pr-review
description	指定されたGitHubプルリクエストに対して、複数の専門エージェント（CLAUDE.md準拠/バグ検出/REVIEW.md準拠）を並列起動して多角的なコードレビューを実施するスキル。
allowed-tools	Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr view:*), Bash(gh pr list:*), Bash(gh repo view:*), Bash(gh api:*), Bash(git rev-parse:*), Bash(git diff:*), Bash(git show:*), Bash(node:*), Bash(jq:*), Write
disable-model-invocation	true

指定されたプルリクエストに対してコードレビューを行います。

引数: <PR> （必須）、--comment（任意。指定時は GitHub にインラインコメントを投稿する）

0. PR HEAD とローカルの一致を確認する（最初に必ず実行）。 このスキルはプロジェクトルール（CLAUDE.md / .claude/rules/ / REVIEW.md / 観点ファイル）と .gitattributes をローカル作業ツリーから読み、diff もローカル git diff で取得するため、ローカルの HEAD が対象 PR の HEAD コミットと一致している必要がある。この確認は --comment 引数の有無に関わらず必須であり、一致しない場合は無条件に処理を終了する。以下を実行して照合する:
   • gh pr view <PR> --json headRefOid --jq .headRefOid で PR HEAD の commit sha を取得する。
   • git rev-parse HEAD でローカル HEAD の commit sha を取得する。
   • 両者が完全一致しない場合は、レビューを行わずに次の旨を報告して処理を終了する: 「ローカルの HEAD が PR # の HEAD（<headRefOid>）と一致しません（ローカル: <localSha>）。このスキルはルールファイルをローカルから読み diff もローカルで取得するため、対象 PR のブランチをチェックアウト（または最新化）してから再実行してください。」
   • 一致する場合のみ、以降のステップに進む。

モード別パラメータ

${CLAUDE_PLUGIN_ROOT}/shared/review-core.md の太字名に、pr-review では以下の値を与える:

パラメータ	値
context引数	--pr <PR>
サマリエージェント入力	gh pr view <PR> --json title,body,commits --jq '{title: .title, body: .body, commits: [.commits[] | {headline: .messageHeadline, body: .messageBody}]}'（PRタイトル・説明文・コミットメッセージ一覧）+ 統一 diff
著者意図情報	PRタイトル・説明文
ステップ3の起動タイミング	エージェント1・2・3・5 はステップ2と並列に起動してよい（ステップ2に依存しない）。エージェント4のみステップ2完了を待つ
tiny時のサマリエージェント	起動しない（tier が tiny のとき）。著者意図は PRタイトル・説明文で代替でき（サマリ失敗時の縮退と同経路）、クラスタは validate-clusters.mjs が tier 縮退で単一化するため、ステップ2のサマリ+クラスタ分割エージェントを省略する。clusters は [] を Write してステップ2b に通す
サマリ失敗時の縮退	著者意図情報（PRタイトル・説明文）は常に存在するため、summary が失敗してもエージェント4は PRタイトル・説明文を著者意図として起動できる
既存問題の基準	「PR以前から」
ステップ8の追加要素と完了後の動作	追加要素なし（冒頭に「変更概要」は載せない）。--comment 指定時は下記ステップ9へ進む。未指定なら GitHub への投稿を一切行わずここで終了する

実行

${CLAUDE_PLUGIN_ROOT}/shared/review-core.md を読み込み、上記モード別パラメータを適用してステップ1〜8を一字一句そのとおりに実行する。独自の追加・省略・解釈変更をしない。ルールファイル・.gitattributes はローカル作業ツリーから読むため、ステップ0の HEAD 一致確認が前提となっている。

ステップ8まで完了したら、--comment が指定されている場合のみ以下のステップ9〜10へ進む（未指定ならステップ8で終了）。--comment 指定時は課題の有無にかかわらずステップ9に進む（課題ゼロの場合もPRレビューとして投稿する）。行番号（line / startLine / side）はステップ4のスクリプトが確定済みで FINAL の各 issue の params に入っている。行番号を自分で推測・変更してはならない。 --comment はユーザーが GitHub への投稿を明示的に指示した引数であり、ステップ10の投稿はその指示の実行そのものである。ステップ10の投稿前にユーザーへ追加の承認を求めてはならない（headless 実行では応答が来ずハングし、レビューが完了しなくなるため）。

9. 各インラインコメントの本文を作成する。 FINAL（ステップ7で束ねた成果物パス）の confirmed かつ resolved:true の各 issue（jq -c '.issues[] | select(.resolved==true)' "$FINAL" で取得。id/path/title/body/existingCode/params/sourceFindingIds を含む）について、GitHub に投稿する commentBody（文章）と、必要なら suggestion（置換後の行）を作る。resolved:false の confirmed issue はインライン化せず、ステップ10のサマリ本文で言及する（行番号が未確定なので誤位置に貼らない）。課題が0件（FINAL.issues が空）の場合はこのステップの本文作成をスキップし、ステップ10で空の comments: [] を渡す。

   重要（suggestion の破壊的編集を防ぐ）: GitHub は params の行範囲（＝ existingCode の範囲）を suggestion 本文で丸ごと置換する。suggestion 本文の行数が範囲より短いと、余った既存行が削除される。過去に「コメント指摘のはずが次行の gitignore 本体まで消えた」事故が起きたのはこのため。これを防ぐため、suggestion 本文は existingCode を土台に機械的に作り、post-review.mjs が範囲との整合を検証（不整合なら suggestion を自動で捨てて文章のみ投稿）する。以下に従うこと:

   • commentBody: 本文の先頭に issue の [category · severity] バッジを付ける（jq -r '.issues[] | select(.id=="<id>") | "[\(.category) · \(.severity)]"' "$FINAL" で取得できる）。続けて課題の概要を簡潔に記述する（issue の title/body を基にする。引用元リンクを含める）。suggestion ブロック（```suggestion）を自分で書かない（スクリプトが組み立てる）。
   • 小規模で自己完結する修正には suggestion を付けてよい。手順: issue の existingCode を jq で逐語取得し（jq -r '.issues[] | select(.id=="<id>") | .existingCode' "$FINAL"）、それを土台に該当行だけを編集した最終形を作る。変更しない行は1文字も変えずそのまま残す。 これが「範囲を丸ごと置き換える最終形」になる。
   • 行を削除する修正（範囲から行を減らす）では、消す既存行を deleteLines（消してよい既存行の逐語）に明示する。この明示が無いと post-review.mjs の機械ガードが suggestion を捨てて文章のみにする。
   • 複数メンバーの統合 issue（sourceFindingIds が2件以上）には suggestion を付けない（existingCode が範囲全体を表さず、機械ガードが捨てるため）。文章で修正方針を書く。
   • 大規模な修正（6行以上、構造的変更、複数箇所にまたがる変更）は suggestion を付けず、課題と修正方針を文章で記述する。

重要: 同一課題につき1コメントのみ投稿する。重複コメントを投稿しないこと。

PR 固有の備考:

• GitHubとのやり取り（PR取得、コメント作成など）には gh CLI を使用すること。web fetch は使用しない。
• インラインコメントには各課題の引用元へのリンクを必ず含めること（例: CLAUDE.mdや .claude/rules/ 配下のルールファイルに言及する場合はそのファイルへのリンクを含める）。
• インラインコメント内でコードへリンクする際は、以下の形式を厳密に守ること。守らないとMarkdownプレビューが正しくレンダリングされない: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
  • フルのgit shaが必要。PRのHEADコミットのsha（ステップ0で取得済みの headRefOid）を使う。
  • フルのshaを直接記述すること。https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar のようなコマンド埋め込みはMarkdownでそのまま描画されるため動作しない。
  • リポジトリ名（owner/repo）は gh repo view --json nameWithOwner --jq .nameWithOwner で取得し、レビュー対象のリポジトリと一致させる
  • ファイル名のあとに # を入れる
  • 行範囲は L[start]-L[end] の形式
  • コメント対象行の前後に最低1行ずつコンテキストを含める（例: 5-6行目についてコメントするなら L4-L7 でリンクする）