# Create Review Fix Plan

> GitHub PRの未解決レビューコメント・会話コメント・CIステータスを確認し、修正プランを作成します。

- Skill: `getty104/create-review-fix-plan` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add getty104/create-review-fix-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/getty104/create-review-fix-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: getty104 (https://skillmd.com/u/getty104)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/getty104/create-review-fix-plan

---


# Create Review Fix Plan

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

> **呼び出し側への必須ルール**: 本スキルは `context: fork` のサブエージェントとして起動する場合でも、**絶対にバックグラウンド実行しないこと**。`Agent` ツール経由で呼び出す場合は **既定が `run_in_background: true`（バックグラウンド）** のため、**必ず `run_in_background: false` を明示指定** すること。`Skill` ツール経由の場合も `run_in_background: true` を指定してはならない（既定は同期）。呼び出し元はフェーズ4の構造化サマリを同期的に受け取って初めて後続のタスク分割・並列実装に進める設計であり、バックグラウンド化すると分析結果を待たずに制御が戻って後続処理が空振りする。他スキル（`fix-review-point`・`triage-pr` 等）や上位エージェントから呼ぶ際もこの制約を守ること。

# Instructions

## 実行モードの制約

本スキルは `context: fork` によりサブエージェントとして起動されるが、**内部で呼び出す Bash・Skill・Agent は絶対にバックグラウンド実行しないこと**。呼び出し元へ「修正プランの構造化サマリ」を同期返却する契約であり、バックグラウンド化するとサマリ生成前に制御が戻って後続のタスク分割が空振りするため。

- **`Agent` ツールは既定が `run_in_background: true`（バックグラウンド）**。呼び出しごとに **必ず `run_in_background: false` を明示指定** し、フォアグラウンドで同期的に結果を受け取ってから次の処理に進む。指定を省略した場合はバックグラウンドで走り、本スキルが未完のまま終了する
- `Bash` / `Skill` ツール呼び出し時に `run_in_background: true` を指定しない（既定は同期）。既定の同期実行でstdout・最終出力を受け取ってから次の処理に進む
- シェルコマンド末尾に `&` を付けない。`nohup` / `disown` / `setsid` でのデタッチ、`ScheduleWakeup` 等での後回しも禁止
- フェーズ2で並列起動する `Explore` サブエージェントも、同一メッセージ内で並列に投げるだけであり「バックグラウンド」ではない

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

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

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

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

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

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

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

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

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

```bash
gh pr view --json title,body,url
```

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

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

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

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

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

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

## フェーズ2: 分析

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

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

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

Explore には確認したい観点を具体的に渡す（例: 該当ファイルの現在の実装、その呼び出し元、関連テスト、類似パターンの有無）。Explore は読み取り専用でコードの所在特定に特化しており是非の判断はしないため、修正方針を組み立てるのは本スキル側の役割。

### 2-2. CI失敗の分析

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

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

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

## フェーズ3: タスク分解

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

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

### 各タスクに含めるべき情報
- **目的**: 何を達成するか（指摘の意図ベース）
- **対象範囲**: 編集してよいファイル/ディレクトリの具体パス
- **修正内容**: 具体的な変更方針（コード断片レベルではなく、設計レベル）
- **完了条件**: 受け入れ基準（テストが追加され通る・該当指摘が解消される など）
- **関連レビューコメント**: 元コメントへのURLと該当行
- **依存タスク**: 先に完了しているべきタスクのID（あれば）

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

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

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

```markdown
## 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` で現在のコードを必ず確認してから修正方針を立てる。「既に解消済み・Resolveのみで対応」が正解の場合もある
- **会話コメントはノイズと本物を切り分ける**: `is_minimized` や本文の性質で機械的に弾き、残った「未対応の修正要求」だけを修正タスクに昇格させる。逆に、自動レビューのサマリーに含まれる重要指摘を見落とさないこと