| name | pr-review-fix |
| description | GitHub Pull Request のレビューコメントに一括対応する時に使う。トリガー: 「PR レビュー直して」「レビューコメント対応」「レビューフィードバック反映」「PR の指摘対応」「PR #123 のコメント対応」「review fix」「apply PR review」「address PR feedback」等のユーザー指示、または `/pr-review-fix` スラッシュコマンド、`pr-review-fix` スキル指定。未解決 (isResolved=false) スレッドを網羅収集 → 分類 → 承認付き修正計画 → 実装コミット → push → 返信 & resolve まで 7 フェーズで一気通貫。 |
pr-review-fix
現在のブランチに紐づく PR の 未解決 (unresolved) レビューコメント を全件集約し、
分類 → 計画 → ユーザー承認 → 実装 → コミット → push → 返信 + resolve まで 7 フェーズで進める。
前提
- 現在のブランチに PR が紐づいていない場合は即座に作業終了する。
- GitHub の「Resolve conversation」で閉じたスレッドは 既に対応済み と見なし、以降のすべてのフェーズから除外する。判定は GraphQL の
reviewThreads.isResolved == false を基準にする (REST /pulls/{N}/comments には isResolved フィールドが無いため単独判定不可)。
- スキルディレクトリは
~/.claude/skills/pr-review-fix/ で、配下に scripts/ と references/ を持つ。スクリプトは常に絶対パス ~/.claude/skills/pr-review-fix/scripts/<name>.sh で呼び出す (Claude の cwd は通常プロジェクトルートなので相対パスは不可)。
- 依存:
gh CLI (authenticated、v2.4.0+ 推奨)、git。Phase 1〜6 で使うスクリプトは jq 不要 (gh api --jq の内蔵 gojq を使用)。Phase 7 の process_replies.sh は mapping.json 解析に jq を使用する。
ワークフロー (7 Phase)
Phase 1 — 未解決レビュースレッド収集
fetch_unresolved_threads.sh を実行して isResolved == false の review thread を NDJSON (1 行 1 thread) で取得する。fork PR の base repository を自動参照し、gh api --paginate で 100 件超の大 PR も全ページ取得する。
~/.claude/skills/pr-review-fix/scripts/fetch_unresolved_threads.sh
~/.claude/skills/pr-review-fix/scripts/fetch_unresolved_threads.sh <pr_number>
出力 (NDJSON, 1 行 = 1 thread) の各行から以下を抜き出し 対応表 (通し番号 ↔ thread_id / comment_id / path / line / body / author) を作る:
.id → thread_id (PRRT_... 形式、Phase 7 の resolve に使う).comments.nodes[].databaseId → comment_id (Phase 7 の返信に使う)
対応表の永続化 (必須):
コメント数が多い / context が長くなる場合に備え、対応表をプロジェクトの outputs/pr-review-fix/pr-<N>-mapping.json に書き出す。Claude は context が切れても再開できる。
mkdir -p outputs/pr-review-fix
~/.claude/skills/pr-review-fix/scripts/fetch_unresolved_threads.sh <pr_number> \
> outputs/pr-review-fix/pr-<pr_number>-threads.ndjson
その後 Claude が以下のスキーマで pr-<N>-mapping.json を作成・維持する:
[
{"seq": 1, "thread_id": "PRRT_...", "comment_id": 123, "path": "src/a.py", "line": 42,
"classification": "🔴", "category": "アーキテクチャ", "author": "reviewer1",
"body_summary": "...", "fix_plan": "...",
"commit_hash": null, "reply_eligible": false, "reply_body": null,
"replied": false, "resolved": false}
]
reply_eligible / reply_body は Phase 7 で process_replies.sh が読む判定フィールド (詳細は Phase 7 参照)。Phase 1〜6 では false / null のままにする。
Phase 6 でコミットするたび commit_hash を、Phase 7 で返信・resolve するたび replied / resolved を更新する。利用する各プロジェクトで outputs/ を .gitignore に含めて、これらの生成ファイルが誤って commit されないようにする。
補助的に以下も見てよい (判断材料ではなく概要把握):
gh pr view --comments — PR 全体の概要gh api repos/{owner}/{repo}/pulls/{N}/reviews — レビュー本体サマリーgh api repos/{owner}/{repo}/issues/{N}/comments — PR 一般コメント (resolve 概念なし、全件対象)
Phase 2 — 分類
各コメントに対して、以下 2 軸で分類する。詳細タクソノミーは references/classification.md を参照。
- 対応方針: 🔴 必須 / 🟡 推奨 / 🟢 質問・議論
- カテゴリー: 仕様適合性 / コーディングルール / パフォーマンス / アーキテクチャ / テスト品質 / エラーハンドリング / 可読性・保守性
Phase 3 — 修正計画の立案
深く考え (ultrathink) 修正計画を作る。テンプレートとセルフチェックリストは references/plan_template.md を参照。
必須ルール:
- 修正対象は 🔴 と 🟡 のみ。🟢 は計画対象外。
- 全ての表は対応方針の降順 (🔴 > 🟡 > 🟢) → 収集順 (stable) でソートして表示する。通し番号
# はソート後に 1 から振り、以降 Phase 6 / Phase 7 でも同じ番号で参照する (表示順 = 処理順 = 重要度順)。
Phase 4 — 計画品質チェック
references/plan_template.md の「Phase 4 セルフチェックリスト」を 内部で 実行し、80% 以上満たすまで Phase 5 に進まない。チェックリストの実行結果はユーザーに出力しない (内部判定のみ)。
Phase 5 — 計画提示 (正常系は自動継続)
原則: 正常系ではユーザー確認を取らず、計画を提示したら即 Phase 6 に進む。以下のいずれかに該当する場合に限り、ユーザーに確認を求めて停止する。
停止条件 (いずれかに該当する場合のみ):
- 🟢 質問・議論カテゴリのコメントがあり、ユーザー判断が必要 (返信内容 / resolve するか等)。
- 修正方針に複数案があり、どちらを採るかで成果物が大きく変わる。
- 分類 (🔴 / 🟡 / 🟢) や修正範囲に Claude 側で確信が持てない論点がある。
- レビュアー指摘とコードベース現状が矛盾しており、前提確認が必要。
- Phase 4 セルフチェックが 80% 未満で、不足要素にユーザー入力が必要。
停止条件に該当しない (= 正常系) の場合は、計画を簡潔に提示してそのまま Phase 6 を開始する。「承認しますか？」「進めてよいですか？」の類の確認は出さない。
リトライフロー: ユーザーが差し戻し (方針変更・優先度変更・追加の検討事項・分類変更) を指示した場合は Phase 3 に戻って計画を再作成 し、Phase 4 セルフチェック → Phase 5 再提示を繰り返す。差し戻し内容を outputs/pr-review-fix/pr-<N>-mapping.json の該当エントリの fix_plan に反映させる。
Phase 6 — 実装
Phase 5 を抜けたら (正常系は即時、停止条件に該当した場合はユーザー応答後):
- ブランチ状態・依存関係・計画を再確認。
- 通し番号順に修正実施。論理単位でコミットを分割する。
- コミットメッセージには修正内容を記載。実行コマンドには
CLAUDE_GIT_SKILL=pr-review-fix を前置する (PreToolUse hook ~/.claude/hooks/enforce-git-skill.sh が本スキル経由かどうかをこのマーカーで判定し、無いと git commit / git push の直接実行はブロックされる): CLAUDE_GIT_SKILL=pr-review-fix git commit -m "<件名>"。コミット直後に対応表 (outputs/pr-review-fix/pr-<N>-mapping.json) の該当エントリに commit_hash (完全 SHA) を書き込む。
- lint / typecheck / test を実行してグリーンを確認。
CLAUDE_GIT_SKILL=pr-review-fix git push でリモート反映。
注意: push 前に resolve するとコミットが GitHub に未到達で返信リンクが壊れる可能性がある。
必ず push 後に Phase 7 に進む。
非コード修正のパターン:
PR description の修正など、コミットを作らずに対応する場合の典型:
gh pr view <pr_number> --json body -q .body > /tmp/pr_body.md
gh pr edit <pr_number> --body-file /tmp/pr_body.md
対応表では commit_hash を null のままにし、代わりに fix_plan に "PR description 更新 (kv=6_000 に合わせた)" 等の説明を残す。reply_eligible は false のままにする (非コード修正は Phase 7 で返信しない、下記参照)。
Phase 7 — 返信 & resolve
本フェーズでは reply_to_comment.sh / resolve_thread.sh を直接呼び出さない。 両スクリプトは process_replies.sh の内部依存であり、Claude が直接叩くと「返信対象ではないコメントに誤って返信する」事故を機械的に防げなくなる。Phase 7 の唯一の実行経路は次の 2 ステップ。
1. mapping.json に reply_eligible / reply_body を設定する
対応表の各エントリについて、Phase 6 で本スキルが新規コミットを作成したエントリのみ reply_eligible: true を設定し、reply_body に <FULL_SHA> で修正しました。 (完全 40 文字 SHA、複数コミットに跨る場合は読点区切り) を書く。例: abc1234567890abcdef1234567890abcdef12345678 で修正しました。
- 対象外 (常に
reply_eligible: false、返信も resolve もしない):
- PR description 更新等、コミットを作らない非コード修正のエントリ。
- 🟢 質問・議論カテゴリのコメント (Claude からの返信は禁止。回答はユーザー自身が行う)。
- 修正不要と判断したコメント (議論を残す目的)。
- 既存コミットで既に対応済みのコメント (新規コミットなし)。
reply_body は <FULL_SHA(、FULL_SHA...)> で修正しました。 の形のみ許可される (他の形式は process_replies.sh が機械的に拒否する)。同じエントリの commit_hash に同一の完全 SHA を書くこと。process_replies.sh は reply_body 中の SHA と commit_hash が完全一致しないエントリを拒否する (誤った SHA を貼る事故を防ぐ)。完全 SHA は git rev-parse HEAD / git log --format=%H -1 で取得する。
2. process_replies.sh を実行する
~/.claude/skills/pr-review-fix/scripts/process_replies.sh outputs/pr-review-fix/pr-<N>-mapping.json --dry-run
~/.claude/skills/pr-review-fix/scripts/process_replies.sh outputs/pr-review-fix/pr-<N>-mapping.json
このスクリプトが reply_eligible == true かつ reply_body が上記 2 パターンに合致するエントリのみを対象に、reply_to_comment.sh (署名自動付加) → resolve_thread.sh を順に実行し、成功したエントリの replied / resolved を mapping.json 上で true に更新する。判定を満たさないエントリは API を一切呼ばずにスキップされ、その理由が stderr に出力される。
- 既に
replied: true のエントリは再送されない (再実行の安全性)。
- 返信 or resolve に失敗した場合はエラーを出力し、残りの処理は継続する。
- スキップされたエントリが想定と異なる場合は、mapping.json の
reply_eligible / reply_body を見直してから再実行する。
3. 完了報告
references/plan_template.md の「Phase 7 完了報告テーブル」でユーザーに提示する。先頭列に Phase 3 と同じ通し番号を必ず付ける。
トラブルシューティング
- PR が見つからない:
gh pr view で紐付け確認。無ければスキル終了。
- 返信 API が 422:
comment_id が top-level か確認 (既に返信スレッド内のコメント ID に対しては in_reply_to できない場合がある — その場合はスレッドの先頭コメント ID を使う)。
- resolve が 403: ログイン中のアカウントにリポジトリへの triage 以上の権限があるか確認。
- 古い情報が必要: Web 情報を参照する場合は 2026 年 1 月以降の最新情報を参照する。
