create-review-fix-plan

name	create-review-fix-plan
description	GitHub PRの未解決レビューコメント・会話コメント・CIステータスを確認し、修正プランを作成します。
model	sonnet
effort	high
context	fork

Create Review Fix Plan

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

Instructions

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

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

• gh pr view --json number,state,title,headRefName でカレントPRが取得できることを確認する。取得できない場合は呼び出し元にエラーを返す
• PRの state が OPEN であることを確認する。MERGED/CLOSED の場合は呼び出し元にその旨を返して終了

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

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

以下を 同一メッセージ内で並列に実行 する。順次実行すると遅いため、必ずまとめて発行すること。

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

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 側の参照も合わせて直すこと。

返却される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本文の取得

gh pr view --json title,body,url

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

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

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

state が FAILURE / STARTUP_FAILURE のチェックがあれば、各 link から run-id を抽出して以下で詳細ログを取得：

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タスクに統合（編集競合を避けるため）
• 異なるファイル/モジュールへの指摘は 別タスクに分離（並列実行を可能にするため）
• 関連する指摘でも、依存関係がなければ別タスクにする

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

• 目的: 何を達成するか（指摘の意図ベース）
• 対象範囲: 編集してよいファイル/ディレクトリの具体パス
• 修正内容: 具体的な変更方針（コード断片レベルではなく、設計レベル）
• 完了条件: 受け入れ基準（ユニットテストが追加され通る・該当指摘が解消される など）。プロジェクトに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 や本文の性質で機械的に弾き、残った「未対応の修正要求」だけを修正タスクに昇格させる。逆に、自動レビューのサマリーに含まれる重要指摘を見落とさないこと