GitHub PRの未解決レビューコメント・会話コメント・CIステータスを確認し、修正プランを作成します。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
GitHub PRの未解決レビューコメントとCI失敗を分析し、後続スキル（fix-review-point等）が並列実行できる粒度の修正プランに分解して返却するスキル。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。
本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。
並列で以下を確認する。1つでも失敗したら、その場で原因を解消してから先に進むこと。
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 にフォールバックする。取得できない場合は呼び出し元にエラーを返すstate が OPEN であることを確認する。MERGED/CLOSED の場合は呼び出し元にその旨を返して終了完了条件: PRが特定でき、OPEN状態であることが確認できていること。
以下を 同一メッセージ内で並列に実行 する（順次実行は遅いため）。
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ステータスの自動投稿判断に迷う場合は「このコメントは未対応の修正要求か？」を基準にし、修正要求であれば後続フェーズの分析対象に含める。
GitHub MCP の pull_request_read（method: get）を優先し、利用不可なら以下にフォールバックする。
gh pr view --json title,body,url
PRの目的・スコープ・関連Issueを把握し、レビューコメントの背景理解に活用する。
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-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の要件（無ければその旨）がすべて手元に揃っていること。
未解決スレッドと、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 は読み取り専用でコードの所在特定に特化しており是非の判断はしないため、修正方針を組み立てるのは本スキル側の役割。
CI失敗がある場合、ログから以下を判別する：
CIが全Passなら「全てPass」と明記する。
完了条件: 各未解決コメント・対応すべき会話コメント・CI失敗について、「何を・どこで・なぜ修正するか」が言語化できていること。
分析結果を、後続スキルが そのままサブエージェントに投げられる粒度 のタスクに分解する。
UIに関する指摘は、「デザインのマークアップ」と「配線」を別タスクに分ける。呼び出し元（fix-review-point）はマークアップタスクだけを frontend-implementer（マークアップ専任エージェント）へ委譲するため、混ざったままだと専任エージェントに担当外の修正が渡る。この分離は「同じファイルへの指摘は1タスクに統合」より優先する。
1つの指摘にマークアップとロジックの両方が含まれる場合は、同じコメントURLを両タスクに紐づけたうえで分割する（どちらか一方だけ対応してResolveされるのを防ぐため）。分割した2タスクは同一ファイルを編集するため 逐次グループ（マークアップ → 配線）に置く。
分離しない例外: マークアップ側の修正が数行で収まる場合（クラス名の差し替え、余白値の修正など）は分割コストが上回るため1タスクにまとめ、種別に明記する。
デザインマークアップ / 配線 / 通常（UIに関わらない指摘は 通常）完了条件: タスク群が「並列実行可能なグループ」と「逐次実行が必要なグループ」に明確に分類されていること。
以下のテンプレートに沿って構造化し、呼び出し元に返却する。中間ステップの出力はノイズになるため省略し、このサマリのみを返すこと。
## 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 等）に委ねるfix-review-point がそのまま実装し、要件と食い違うPRがマージされる）explore-agent で現在のコードを必ず確認してから修正方針を立てる。「既に解消済み・Resolveのみで対応」が正解の場合もあるis_minimized や本文の性質で機械的に弾き、残った「未対応の修正要求」だけを修正タスクに昇格させる。逆に、自動レビューのサマリーに含まれる重要指摘を見落とさないことNo reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
GitHub Issueの確認事項（最後のコメント・descriptionの両方）を、コードベース・ドキュメント・そこから参照されている外部リンク（仕様書・ライブラリ公式ドキュメント等）まで調査し、根拠に基づいた回答をコメントに追記するスキル。調査しても事実で決まらず人間の意思決定が必要な項目は、固定セクションで明示して後続のトリアージへ引き渡す。
The English summary is being prepared. Showing the original description.
Write the merged Pencil design reference back into a UI implementation Issue's description. Takes the Issue number as argument, resolves the merged design PR on the `cc-ui-design-<Issue number>` branch, collects the `.pen` and snapshot paths it added, and appends (or replaces) the `## UIデザイン` section at the end of the Issue body using a lost-update-safe edit.
The English summary is being prepared. Showing the original description.
依頼された内容（自然言語の説明、または既存のIssue番号）を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「PRDのIssue #123 を分解して」といったリクエストで発動する。
The English summary is being prepared. Showing the original description.
claude-task-worker のカスタムワーカー（`workerFiles` に登録する TS 定義）を、`AskUserQuestion` で要件を全項目確定させてから生成し、`claude-task-worker list-workers` でロード検証までするスキル。「カスタムワーカーを作って」「独自のワーカーを追加したい」「新しいラベルで動くワーカーを定義したい」といったリクエストで使用する。
The English summary is being prepared. Showing the original description.
claude-task-workerプラグインのバージョンをインクリメントし、commit-pushでコミット・プッシュしたうえでPRを作成する。引数で `major` / `minor` / `patch` を受け取り、対応する部分をインクリメントする（省略時は `patch`）。「バージョンを上げて」「バージョンアップ」「bump version」「メジャーバージョンを上げて」などのリクエストで使用する。
The English summary is being prepared. Showing the original description.
指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。
The English summary is being prepared. Showing the original description.