Imported from getty104/claude-task-worker (plugin/skills/create-review-fix-plan/SKILL.md). Install upstream with npx skills add getty104/claude-task-worker --skill create-review-fix-plan. Copyright stays with the author.

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

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

フェーズ2: 分析

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

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

指摘箇所の 現在のコード確認・修正対象の特定・影響範囲の見積もり は explore-agent サブエージェントに委譲する（自前で Read を繰り返すより fan-out 探索で速く正確なため）。スレッドやコメントが複数ある場合は、同一メッセージ内で複数の explore-agent を 並列に 起動して待ち時間を圧縮する。

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行>

## 未解決レビューコメント（<件数>件）
### コメント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等）がこの返却内容だけを見て、追加調査なしにサブエージェントへブリーフィングできる状態になっていること。

注意事項

• 指摘の字面に引きずられない: コメント本文をそのままコピーせず、レビュアーの意図を抽出して修正方針に変換する
• CIの「PR外起因」を理由に放置しない: マージ可能にするのが目的なので、原因がどこであれ通す方策を提案する
• タスクは具体的に: 「リファクタする」等の曖昧な表現を避け、対象ファイル・変更内容・完了条件を明示する。サブエージェントは会話履歴を持たないため、タスク定義の具体性が品質を決める
• outdatedスレッド: 既にコードが変わっている可能性があるため、explore-agent で現在のコードを必ず確認してから修正方針を立てる。「既に解消済み・Resolveのみで対応」が正解の場合もある
• 会話コメントはノイズと本物を切り分ける: is_minimized や本文の性質で機械的に弾き、残った「未対応の修正要求」だけを修正タスクに昇格させる。逆に、自動レビューのサマリーに含まれる重要指摘を見落とさないこと