Create Review Fix Plan

GitHub PRの未解決レビューコメントとCI失敗を分析し、後続スキル（fix-review-point等）が並列実行できる粒度の修正プランに分解して返却するスキル。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

フェーズ0: 事前チェック

並列で以下を確認する。1つでも失敗したら、その場で原因を解消してから先に進むこと。

• カレントPRの number / state / title / headRefName を取得できることを確認する。PR 番号は bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh pr-for-branch で確定し（カレントブランチからの導出は MCP に代替が無く、gh pr view --json number はクラウドでは 403 になる）、詳細は GitHub MCP の pull_request_read（method: get）を優先、利用不可なら gh pr view <番号> --json state,title,headRefName にフォールバックする。取得できない場合は呼び出し元にエラーを返す
• PRの state が OPEN であることを確認する。MERGED/CLOSED の場合は呼び出し元にその旨を返して終了

完了条件: PRが特定でき、OPEN状態であることが確認できていること。

フェーズ1: 情報収集（並列実行）

以下を 同一メッセージ内で並列に実行 する（順次実行は遅いため）。

1-1. レビューコメント・会話コメントの取得

GitHub MCP の pull_request_read（method: get_review_comments）で未解決レビュースレッド（unresolved_threads[]）を取得することを第一手段とする。get_review_comments はレビュースレッド専用で、Conversationタブの会話コメント（conversation_comments[]）は返さない。会話コメントは PR が Issue 番号空間を共有することを利用し、issue_read（method: get_comments）を別途呼んで取得する。どちらか一方でも利用不可なら以下の共有スクリプトへフォールバックする。

bash ${CLAUDE_SKILL_DIR}/scripts/fetch-unresolved-comments.sh

scripts/fetch-unresolved-comments.sh は triage-pr スキルからも ${CLAUDE_SKILL_DIR}/../create-review-fix-plan/scripts/fetch-unresolved-comments.sh として参照される共有スクリプト。パス・ファイル名を変更する場合は triage-pr 側の参照も合わせて直すこと。

取得失敗を「指摘0件」と読み替えないこと。 MCP・スクリプトのどちらの経路でも、取得に失敗した場合（スクリプトが非0で終了した／MCP がエラーを返した）は空の結果として扱わず、失敗として扱う。スクリプトは失敗時に非0で終了し stderr に原因を出す（正常に0件だった場合は exit 0 と空配列）。両経路とも失敗した場合は修正プランを組み立てず、「レビューコメントを取得できなかった」ことと原因を呼び出し元へ返して終了する。空の結果を返すと、呼び出し元（triage-pr）が指摘なしと判断してPRをマージしてしまう。

ページング: unresolved_threads[] はレビュースレッドが100件を超える場合、get_review_comments の返却にページ情報（カーソル/次ページの有無）があれば全ページを取得し終えるまで呼び続ける。get_comments（会話コメント）も同様に、1回の呼び出しで全件を返すとは限らないため、返却が尽きるまでページングする。共有スクリプトの fetch_all_review_threads() がレビュースレッド側で行っているのと同じ「次ページが無くなるまでループする」動作を、MCP経路でも徹底すること（片方だけ取得して打ち切ると、後続フェーズが古い/一部の指摘だけを対象にしてしまう）。

MCP経路で取得する場合も、スクリプトが返すJSONと同じ意味の情報を同じ観点で抽出すること（unresolved_threads[] の thread_id / path / line / is_outdated / comments[]、conversation_comments[] の author / body / url / created_at / is_minimized）。後続フェーズと fix-review-point がこれらのキーに依存するため、キー名・粒度をどちらの経路でも揃える。

重要: thread_id（スレッドの node ID。PRRT_... 形式）はレビュースレッドのResolve（resolve-pr-commentsスキル）で必要になる。MCP経路では get_review_comments が同じ node ID を返すため、そのまま pull_request_review_write（method: resolve_thread）へ渡せる。

返却されるJSONから2系統のフィードバックを抽出する。

• unresolved_threads[]: コード行に紐づく未解決のインラインレビューコメント。各スレッドの path / line / body / author / is_outdated を保持する。is_outdated: true のスレッドは差分が変わっている可能性があるため、対応方針の判断時に注記する。
• conversation_comments[]: PRのConversationタブに投稿された一般コメント（コード行に紐づかない総評や「ここも直して」系の指摘）。各コメントの author / body / url / created_at / is_minimized を保持する。Gemini・CodeRabbit等の自動レビューのサマリーや人間レビュアーの行外フィードバックが含まれるため、インラインコメントだけ見ていると対応漏れが起きる。

会話コメントには対応不要なノイズも混ざるため、次を除外して実際に対応すべきフィードバックだけを抽出する。

• is_minimized: true のコメント（折りたたみ済み＝outdated/resolved/spam等として処理済み）
• /gemini review のようなボット起動コマンドや、CIステータスの自動投稿
• PR作成者自身の単なる進捗報告・補足など、対応を求めていないチャット

判断に迷う場合は「このコメントは未対応の修正要求か？」を基準にし、修正要求であれば後続フェーズの分析対象に含める。

1-2. PR本文の取得

GitHub MCP の pull_request_read（method: get）を優先し、利用不可なら以下にフォールバックする。

gh pr view --json title,body,url

PRの目的・スコープ・関連Issueを把握し、レビューコメントの背景理解に活用する。

1-3. CIステータスの取得

GitHub MCP の pull_request_read（method: get_status / get_check_runs）を優先し、利用不可なら以下にフォールバックする。

gh pr checks --json state,name,link,workflow

state が FAILURE / STARTUP_FAILURE のチェックがあれば、各 link から run-id を抽出して詳細ログを取得する。GitHub MCP の get_job_logs（failed_only: true）を優先し、利用不可なら以下にフォールバックする。

gh run view <run-id> --log-failed

1-4. 関連Issueの要件の取得

1-2 で取得したPR本文から Closes / Fixes / Resolves / Refs #<N> で参照されているIssue番号を抽出し（複数あれば全件）、各Issueの本文とコメントを取得する。GitHub MCP の issue_read（method: get / get_comments）を優先し、利用不可なら以下にフォールバックする。MCP の get_comments はページングAPIなので、page / perPage を指定して返却件数が perPage 未満になるまで次ページを取得する（1ページ目で打ち切ると後続の回答コメントを落とす）。

gh issue view <N> --json body,comments

ここで「正」として扱うのは、descriptionの ## 要件 / ## 実装プラン / ## 影響範囲、確認事項への回答コメント（## 回答 見出し。descriptionに反映済みならdescriptionを優先）、依頼者・レビュアーの人間が書いたコメントのうち確定した要件・方針を明示しているもの（未決着の議論・案の提示・質問は含めない）。参照Issueが無い・取得に失敗した場合は要件不明として扱い、2-1 の要件突き合わせを省略する（エラーにしない。Issueを持たないPRも存在する）。取得に失敗した事実は返却に残す。

完了条件: 未解決スレッド一覧・対応すべき会話コメント一覧・PR概要・CIステータス（失敗時はログ）・関連Issueの要件（無ければその旨）がすべて手元に揃っていること。

フェーズ2: 分析

2-1. レビューコメント・会話コメントの分析（コード調査は explore-agent に委譲）

未解決スレッドと、1-1で絞り込んだ会話コメントの両方について、まず各指摘の 意図（字面ではなく、レビュアーが懸念している根本問題）を読み取る。会話コメントは行番号を持たないため、本文から「どのファイル・どの観点の話か」を読み取り、必要なら explore-agent に該当箇所の特定も委ねる。

指摘箇所の 現在のコード確認・修正対象の特定・影響範囲の見積もり は explore-agent サブエージェントに委譲する（自前で Read を繰り返すより fan-out 探索で速く正確なため）。スレッドやコメントが複数ある場合は、同一メッセージ内で複数の explore-agent を 並列に 起動して待ち時間を圧縮する。Agent ツールの effort は毎回指定する（explore-agent は定義に effort を持たない。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md）。指摘箇所の現状確認・関連テストの所在特定は medium、影響範囲の見積もりが要る指摘（設計・責務分割・安全性の指摘、outdated スレッドの現状確認）は high。

Issueの要件を正とする: 各指摘の意図を読み取ったら、1-4 で「正」とした確定事項（要件・実装プラン・確認事項への回答・確定方針を示す人間コメント）と突き合わせる。レビュー指摘（特に自動レビュー）はPRの差分しか見ておらず、Issueで確定した要件や回答を知らないため、次の指摘は修正タスクにしない: 要件・回答で確定している挙動を別の挙動へ変える提案、要件に無い利用者から見える挙動の追加を求める提案。これらは返却の「要件優先で対応しない指摘」へ、該当する要件・回答の箇所を引いて列挙する（呼び出し元がスレッドへ返信する材料になる）。該当箇所を特定できない場合は対応する側へ倒す。逆に、PRの実装が要件を満たしていない点を突く指摘は、文面が軽くても修正タスクに含める。修正方針も要件の範囲内に収め、指摘を解消するために要件に無い挙動を足さない。

explore-agent には確認したい観点を具体的に渡す（例: 該当ファイルの現在の実装、その呼び出し元、関連テスト（ユニット・E2E）、類似パターンの有無）。あわせて「E2Eテスト基盤の有無と所在」も調査観点に含める（E2Eフレームワークの設定ファイル playwright.config.* / cypress.config.* / wdio.conf.* / nightwatch.conf.* など、e2e/ / tests/e2e/ / cypress/ 等のディレクトリ、package.json の test:e2e / e2e 系 scripts のいずれかが存在すれば「E2Eテストあり」と判定する）。explore-agent は読み取り専用でコードの所在特定に特化しており是非の判断はしないため、修正方針を組み立てるのは本スキル側の役割。

2-2. CI失敗の分析

CI失敗がある場合、ログから以下を判別する：

• このPRの変更が原因: 失敗しているテスト/Lintを修正対象に含める
• このPRの変更とは無関係（flaky・環境依存・デフォルトブランチで既に壊れている等）: それでも修正タスクとして含める。理由を明記する
• テスト自体が古い/誤っている: テスト側を修正するタスクとして起票する

CIが全Passなら「全てPass」と明記する。

完了条件: 各未解決コメント・対応すべき会話コメント・CI失敗について、「何を・どこで・なぜ修正するか」が言語化できていること。

フェーズ3: タスク分解

分析結果を、後続スキルが そのままサブエージェントに投げられる粒度 のタスクに分解する。

タスク粒度の指針

• 1タスク = 1サブエージェントが10〜30分で完結できる範囲
• 同じファイルを編集する複数指摘は 1タスクに統合（編集競合を避けるため）
• 異なるファイル/モジュールへの指摘は 別タスクに分離（並列実行を可能にするため）
• 関連する指摘でも、依存関係がなければ別タスクにする

UIデザインのマークアップタスクの分離

UIに関する指摘は、「デザインのマークアップ」と「配線」を別タスクに分ける。呼び出し元（fix-review-point）はマークアップタスクだけを frontend-implementer（マークアップ専任エージェント）へ委譲するため、混ざったままだと専任エージェントに担当外の修正が渡る。この分離は「同じファイルへの指摘は1タスクに統合」より優先する。

• マークアップタスク: デザインとの視覚的な差異、スタイル、マークアップ構造、a11yマークアップ、視覚的な状態（hover / focus / disabled / エラー / ローディング / 空状態）の指摘。完了条件は「指摘された見た目が解消されていること」と「表示に必要な props のシグネチャが定義されていること」に閉じる
• 配線タスク: 状態管理・データ取得・API連携・ルーティング・バリデーション/送信処理・ビジネスロジックへの指摘

1つの指摘にマークアップとロジックの両方が含まれる場合は、同じコメントURLを両タスクに紐づけたうえで分割する（どちらか一方だけ対応してResolveされるのを防ぐため）。分割した2タスクは同一ファイルを編集するため 逐次グループ（マークアップ → 配線）に置く。

分離しない例外: マークアップ側の修正が数行で収まる場合（クラス名の差し替え、余白値の修正など）は分割コストが上回るため1タスクにまとめ、種別に明記する。

各タスクに含めるべき情報

• 目的: 何を達成するか（指摘の意図ベース）
• 種別: デザインマークアップ / 配線 / 通常（UIに関わらない指摘は 通常）
• 対象範囲: 編集してよいファイル/ディレクトリの具体パス
• 修正内容: 具体的な変更方針（コード断片レベルではなく、設計レベル）
• 完了条件: 受け入れ基準（ユニットテストが追加され通る・該当指摘が解消される など）。プロジェクトにE2Eテストが存在し、修正がユーザー操作フロー（画面遷移・フォーム入力・API連携・CLIの入出力など）に影響する場合は「該当フローのE2Eテストの追加・更新」も完了条件に含め、E2Eテストの所在・実行コマンドを明記する
• 関連レビューコメント: 元コメントへのURLと該当行
• 依存タスク: 先に完了しているべきタスクのID（あれば）

完了条件: タスク群が「並列実行可能なグループ」と「逐次実行が必要なグループ」に明確に分類されていること。

フェーズ4: 呼び出し元への返却

以下のテンプレートに沿って構造化し、呼び出し元に返却する。中間ステップの出力はノイズになるため省略し、このサマリのみを返すこと。

## PR概要
- 番号/タイトル: #<num> <title>
- URL: <url>
- 目的の要約: <1-2行>

## Issueの要件（正）
- 関連Issue: #<N> <title>（複数あれば列挙。無ければ「関連Issueなし」、取得失敗なら「取得失敗（理由）」）
- 指摘の判定に関わる要件・回答: <該当箇所の引用または要約。指摘ごとに参照できる粒度で>

## 要件優先で対応しない指摘（<件数>件）
- <コメントURL>: <指摘の要約> / 根拠: <矛盾する要件・回答の箇所>

（該当がなければ「なし」と明記）

## 未解決レビューコメント（<件数>件）
### コメント1: <path>:<line>（@<author>）
- 指摘内容: <要約>
- 意図: <レビュアーの懸念の根本>
- 修正方針: <具体策>
- リンク: <comment url>
- 備考: <is_outdatedの場合などここに記載>

（以下繰り返し）

## 会話コメント（<件数>件）
### コメント1: @<author>
- 指摘内容: <要約>
- 意図: <レビュアーの懸念の根本>
- 修正方針: <具体策>
- リンク: <comment url>

（以下繰り返し。対応すべきものがなければ「対応が必要な会話コメントなし」と明記）

## CIステータス
- 全体: <PASS / FAIL n件>
- 失敗チェック1: <name>
  - 原因: <ログ要約>
  - PRとの関係: <PR起因 / 無関係>
  - 修正方針: <具体策>

## 修正タスク一覧
### 並列実行可能グループ
- [task-1] <目的> / 種別: <通常 / デザインマークアップ / 配線> / 対象: <path> / 完了条件: <...> / 関連: <comment url>
- [task-2] <目的> / 種別: <...> / 対象: <path> / 完了条件: <...> / 関連: <comment url>

### 逐次実行グループ（依存あり）
- [task-3] <目的> / 種別: <...> / 依存: task-1 / 対象: <path> / 完了条件: <...>

## タスク間の依存関係
- task-3 は task-1 完了後に実行（理由: <型/スキーマ依存など>）

完了条件: 呼び出し元（fix-review-point等）がこの返却内容だけを見て、追加調査なしにサブエージェントへブリーフィングできる状態になっていること。

注意事項

• プランを返して終える: 本スキルの成果物は修正プランであり、コードの修正・コミット・コメントへの返信は行わない。修正内容が自明に見えても着手せず、プランに書いて呼び出し元（fix-review-point 等）に委ねる
• 指摘の字面に引きずられない: コメント本文をそのままコピーせず、レビュアーの意図を抽出して修正方針に変換する
• Issueの要件に反する指摘をタスク化しない: 要件・確認事項の回答と矛盾する指摘は「要件優先で対応しない指摘」に根拠付きで載せ、修正タスクに混ぜない（混ぜると fix-review-point がそのまま実装し、要件と食い違うPRがマージされる）
• CIの「PR外起因」を理由に放置しない: マージ可能にするのが目的なので、原因がどこであれ通す方策を提案する
• タスクは具体的に: 「リファクタする」等の曖昧な表現を避け、対象ファイル・変更内容・完了条件を明示する。サブエージェントは会話履歴を持たないため、タスク定義の具体性が品質を決める
• outdatedスレッド: 既にコードが変わっている可能性があるため、explore-agent で現在のコードを必ず確認してから修正方針を立てる。「既に解消済み・Resolveのみで対応」が正解の場合もある
• 会話コメントはノイズと本物を切り分ける: is_minimized や本文の性質で機械的に弾き、残った「未対応の修正要求」だけを修正タスクに昇格させる。逆に、自動レビューのサマリーに含まれる重要指摘を見落とさないこと