Menu
GitHub PRの未解決レビューコメント・会話コメント・CIステータスを確認し、修正プランを作成します。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | create-review-fix-plan |
| description | GitHub PRの未解決レビューコメント・会話コメント・CIステータスを確認し、修正プランを作成します。 |
| model | sonnet |
| effort | high |
| context | fork |
GitHub PRの未解決レビューコメントとCI失敗を分析し、後続スキル（fix-review-point等）が並列実行できる粒度の修正プランに分解して返却するスキルです。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。
並列で以下を確認する。1つでも失敗したら、その場で原因を解消してから先に進むこと。
gh pr view --json number,state,title,headRefName でカレントPRが取得できることを確認する。取得できない場合は呼び出し元にエラーを返すstate が OPEN であることを確認する。MERGED/CLOSED の場合は呼び出し元にその旨を返して終了完了条件: PRが特定でき、OPEN状態であることが確認できていること。
以下を 同一メッセージ内で並列に実行 する。順次実行すると遅いため、必ずまとめて発行すること。
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ステータスの自動投稿判断に迷う場合は「このコメントは未対応の修正要求か？」を基準にし、修正要求であれば後続フェーズの分析対象に含める。
gh pr view --json title,body,url
PRの目的・スコープ・関連Issueを把握し、レビューコメントの背景理解に活用する。
gh pr checks --json state,name,link,workflow
state が FAILURE / STARTUP_FAILURE のチェックがあれば、各 link から run-id を抽出して以下で詳細ログを取得：
gh run view <run-id> --log-failed
完了条件: 未解決スレッド一覧・対応すべき会話コメント一覧・PR概要・CIステータス（失敗時はログ）がすべて手元に揃っていること。
未解決スレッドと、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 は読み取り専用でコードの所在特定に特化しており是非の判断はしないため、修正方針を組み立てるのは本スキル側の役割。
CI失敗がある場合、ログから以下を判別する：
CIが全Passなら「全てPass」と明記する。
完了条件: 各未解決コメント・対応すべき会話コメント・CI失敗について、「何を・どこで・なぜ修正するか」が言語化できていること。
分析結果を、後続スキルが そのままサブエージェントに投げられる粒度 のタスクに分解する。
完了条件: タスク群が「並列実行可能なグループ」と「逐次実行が必要なグループ」に明確に分類されていること。
以下のテンプレートに沿って構造化し、呼び出し元に返却する。中間ステップの出力はノイズになるため省略し、このサマリのみを返すこと。
## 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等）がこの返却内容だけを見て、追加調査なしにサブエージェントへブリーフィングできる状態になっていること。
explore-agent で現在のコードを必ず確認してから修正方針を立てる。「既に解消済み・Resolveのみで対応」が正解の場合もあるis_minimized や本文の性質で機械的に弾き、残った「未対応の修正要求」だけを修正タスクに昇格させる。逆に、自動レビューのサマリーに含まれる重要指摘を見落とさないことRe-analyze an existing GitHub Issue using its current title and body as input, refresh the implementation plan against the latest code state, and update the Issue in place. Use this when the user provides an Issue number (numeric, `#`-prefixed, or Issue URL) and wants to regenerate the code analysis via the explore-agent subagent. For reflecting comment-driven updates instead, use update-issue. For creating a brand-new Issue from a natural-language task description, use create-issue.
Create an implementation plan and a GitHub Issue based on the task description provided as an argument. Use this when the user supplies a natural-language task description (not an issue number) and wants a new implementation-ready Issue. If the input is an existing issue number, use create-issue-from-issue-number (re-analyze) or update-issue (reflect comments) instead.
GitHub Issueの確認事項に対して、コードベースやドキュメントを徹底的に調査し、根拠に基づいた回答を提供するスキル。Issueの最後のコメントに含まれる確認事項を調査・回答し、コメントに追記する。
ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。
Create or update the Pencil (`.pen`) design for a UI implementation Issue before any code is written, then open a design-only PR. Takes the Issue number as argument, extracts the design requirements from the Issue description and comments, delegates `.pen` edits to the pencil-design-updater agent, exports snapshot PNGs, pushes them on the fixed `cc-ui-design-<Issue number>` branch, and opens a PR that references the Issue with `Refs #<N>` (never a closing keyword).
Execute tasks based on GitHub Issue content