Address unresolved review comments on specified PR
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
GitHub PR $0 の未解決レビューコメントに対応し、修正のコミット・push・Resolve・description更新までを完遂するスキル。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。
自律実行モード: ユーザーへの確認を求めず最後まで自律的に完遂する。判断が必要な場面では本ドキュメントの既定挙動に従って自動で意思決定し、処理を継続する。確認のために停止することは禁止（フェーズ0の安全ガード条件に該当する場合のみ中断可）。
本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。
本スキル固有のリスク: 本スキルは claude-task-worker の cc-fix-onetime ラベルをトリガーに自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-fix-onetime の除去やコールバックコメント投稿を進める。処理未完のままターンを終えると、修正コミット未 push のまま Resolve だけ済まされたり、レビュー未対応のまま fix ラベルが外れて放置される状態壊れが起きる。
create-review-fix-plan が「要件優先で対応しない指摘」に載せた指摘は実装せず、フェーズ6で該当スレッドへ要件・回答の該当箇所を引いて1-2行で返信する。プランの修正方針が要件と矛盾すると実装中に気づいた場合も同じ扱いにし、要件に無い挙動を足して指摘を解消しない。逆に、実装が要件を満たしていない点を突く指摘は、文面が軽くても対応するメインエージェント（本スキルを実行しているセッション本体）の役割は「指摘の分解・委譲・検証・統合」であり、規模の大きい指摘・並列化できる指摘の修正主体はサブエージェントである。ただし、レビュー指摘には1ファイル数行で済むものが相当数あり、数回のツール呼び出しで終わる修正まで委譲すると、ブリーフィング作成とサブエージェント側の再探索でコストと時間が倍になる。指摘ごとに下記の判定を行って委譲/直接編集を決める（プラン全体で一括判定しない）。
判定は着手前に行い、判定結果（どちらを選んだか・根拠となった条件）を記録して最終報告の自己監査に載せる。
frontend-implementer（マークアップ以外のフロントエンド指摘＝状態管理・データ取得・API連携・ロジックは同エージェントの担当外。general-purpose-assistant へ委譲する）.pen ファイルの編集・更新 → pencil-design-updatercreate-review-fix-plan の返却が file:line を直接指している、自分で Read 済み、CodeGraph の出力に含まれる、または失敗ログが該当行を指している）import の追加、型注釈の修正、リテラルの定数化など）フェーズ4の収束ループ（テスト/Lint/ビルド失敗の修正）にも同じ条件を適用する。
git diff / テスト・Lintの実行でメインが自分で行うどちらとも言い切れない場合は委譲側に倒す。「たぶん小さい」「たぶん1ファイルで済む」は該当しない根拠にならない。軽量な指摘の受け皿として lightweight-assistant を使う。
小修正の直接編集を積み上げてPR全体を自分で直してしまう事故を防ぐため、以下を守る。
Edit / Write を使う。sed -i / ファイルへの > >> リダイレクト / patch / cp / mv / rm などシェル経由の書き換えは、差分が検証できずレビューにも残らないため使わないgh ... --body-file - へのヒアドキュメントのように、リポジトリのファイルを変更しない標準入力の利用は可git stash / gh pr checkout / git commit など、スキル本文が指示する git 操作は可npm install <pkg> など）はステップ1で委譲対象のため、メインからは実行しない対象プロジェクトにE2Eテストが存在し、かつ修正がユーザー操作フローに影響する場合、E2Eテストの実装・更新も本スキルの完遂条件に含める。フェーズ1の完了後（サブエージェント起動前）に以下のいずれかに該当するかを一度だけ確認し、判定結果（存在有無・テストの所在・実行コマンド）を後続フェーズで使い回す：
playwright.config.* / cypress.config.* / wdio.conf.* / nightwatch.conf.* など）e2e/ / tests/e2e/ / cypress/ などのE2Eテスト用ディレクトリが存在するpackage.json の scripts に test:e2e / e2e 等のE2Eテスト実行コマンドがある存在すると判定した場合、ユーザー操作フロー（画面遷移・フォーム入力・API連携・CLIの入出力など、既存E2Eテストが検証している境界）に影響する修正タスクの完了条件に「該当フローのE2Eテストの追加・更新」を含め、フェーズ3のブリーフィングにE2Eテストの所在・実行コマンド・既存テストの記述パターンの参照先を含め、フェーズ4の収束ループでE2Eテストも実行する。
存在しない場合は、レビュー指摘が明示的に要求しない限りE2Eテスト基盤を新規導入しない（スコープ外の変更となるため）。
並列で以下を確認する。1つでも失敗したら、その場で原因を解消してから先に進むこと。
pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。
gh pr view $0 --json number,state,headRefName,isDraft,labels でPRが存在し OPEN であることを確認する。CLOSED/MERGEDなら処理を中断。取得したラベル一覧は「修正点がない場合」の Epic PR 判定で使う（再取得しない）gh pr checkout $0 >/dev/null 2>&1 でPRブランチをチェックアウト（ローカル作業ツリーへの checkout はリモート API では代替できないため gh のまま残す）。クラウド実行時は実行しない — セッションはワーカーが --on-branch で指定した PR の head ブランチ上で開始しており、gh pr checkout はクラウドでは GraphQL ゲートにより 403 で失敗する。git rev-parse --abbrev-ref HEAD が既に対象PRの head ブランチなら省略してよいgit rev-parse --abbrev-ref HEAD の値が、直前で取得済みの headRefName と一致することを確認する。一致しない場合は --on-branch が反映されていない想定外の状態のため、以降のフェーズ（修正コミット・force-push・Resolve）に進まずその場で中断するpwd で .claude/worktrees/ 配下にいることを確認する。worktree外なら安全のため処理を中断する（デフォルトブランチで作業してはならない）。ただし起動プロンプトに「このセッションはクラウド実行のため worktree を持たず、cwd はリポジトリルートである」旨の指示がある場合はこの確認をスキップする — クラウド実行ではワーカーが worktree を作らないため常に worktree 外になる。ガードの目的である「デフォルトブランチで作業しない」は次の確認で担保する。指示が無く worktree 外でもある場合は従来どおり中断する（クラウドかもしれないという推測で続行しない）bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch でデフォルトブランチ名を取得し、git rev-parse --abbrev-ref HEAD の現在ブランチと一致する場合は中断する。デフォルトブランチ名の取得失敗も中断する（fail-safe）git status --short で未コミット変更があれば git stash push -u -m "fix-review-point auto-stash $0" で自動退避してから先に進む（ユーザーへの確認は行わない）完了条件: worktree内（クラウド実行では上記のとおり免除）、PRブランチ（デフォルトブランチ以外）にチェックアウト済み、PR OPEN が確認できていること。
create-review-fix-plan skill を $0 で呼び出し、以下を取得する：
## Issueの要件（正））と、要件優先で対応しない指摘の一覧（コメントURL・根拠となる要件・回答の箇所）修正点がない場合（要件優先で対応しない指摘だけが残った場合も含む。その場合はフェーズ6の返信を先に済ませる）: GitHub MCP が使える場合は pull_request_read（method: get_status / get_check_runs）を使う。以下は MCP 利用不可時のフォールバック。
gh pr checks $0 でCIの全チェックが Pass していることを確認する。チェックが失敗中の場合はマージせず、CI失敗状況をレビュアーに報告して終了する。Pass している場合は、ステップ0で取得したラベル一覧で Epic PR（cc-epic-issue ラベル付き）かどうかを確認して分岐する:
Epic PR の場合: マージするとデフォルトブランチへの集約反映（＝リリース）になるため、マージしない。triage-pr の Epic PR 判定と同じリリースゲートとして cc-release-ready ラベルのみを付与して終了する（関連Issueの連動Closeにも進まない）。
gh pr edit $0 --add-label "cc-release-ready"
通常のPRの場合: PRをマージする。GitHub MCP の pull_request_write（method: merge）を優先し、利用不可なら gh pr merge $0 --merge --delete-branch へフォールバックする（フォールバックした場合はその旨を最終報告に1行残す）。マージ後、下記「マージ後の関連Issue連動Close」を実行して終了する。
GitHubの Closes #<issue番号> 記法による自動クローズはデフォルトブランチへのマージ時にのみ発動する。cc-epic-<N> のような非デフォルトブランチへ向いたPRをマージしてもIssueは閉じず、Epic のサブIssueが未完のまま残って create-epic-pr の起動条件（全サブIssueのクローズ）が満たされなくなる。そのため、マージ前にベースブランチを控えておき、デフォルトブランチと一致しない場合のみ明示的にクローズする。
GitHub MCP が使える場合は
pull_request_read（method:get）を使う。以下は MCP 利用不可時のフォールバック。
BASE_BRANCH=$(gh pr view $0 --json baseRefName -q .baseRefName)
DEFAULT_BRANCH=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch)
マージ成功後、BASE_BRANCH が DEFAULT_BRANCH と一致する場合はGitHubが自動でクローズするためスキップする。一致しない場合はPR本文から関連Issue番号を抽出し、抽出できたすべての番号を completed（実装がEpicブランチへ取り込まれた完了クローズ。マージせずクローズする場合の not_planned とは異なる）でクローズする。クローズは gh issue close（GraphQL 経由でクラウドセッションのゲートに掛かる）ではなく gh-compat.sh close-issue を使う。
GitHub MCP が使える場合は
pull_request_read（method:get）を使う。以下は MCP 利用不可時のフォールバック。
gh pr view $0 --json body --jq '.body' | grep -ioE '(close[sd]?|fix(e[sd])?|resolve[sd]?)[[:space:]]+#[0-9]+' | grep -oE '[0-9]+'
bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh close-issue <issue番号> completed
関連Issueが抽出できない場合は、その旨を最終報告に含めること。
返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。
完了条件: 修正タスクが「並列実行可能なグループ」と「逐次グループ」に分類できていること。
修正タスク（指摘）ごとに、まず「実装の委任（判断ロジック）」のステップ1〜3で委譲するか直接編集するかを判定する。委譲すると決めたタスクは、以下の判断軸でサブエージェントを選定し、実行を委任する：
.pen を参照元としてUIに変換する指摘は必ずこのエージェントを使う。逆に、状態管理・データ取得・API連携・バリデーション/ビジネスロジックへの指摘はフロントエンドのファイルが対象でもこのエージェントに渡さない.pen）自体の編集・更新（要素追加、レイアウト変更、スタイル修正、テキスト差し替えなど）は必ずこのエージェントに任せるlightweight-assistant / general-purpose-assistant を起動するときは、Agent ツールの effort を毎回指定する（両エージェントとも定義に effort を持たない）。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md の表で、本スキルでは次のとおり選ぶ: lightweight-assistant は変更を伴うので medium、general-purpose-assistant は失敗ログ付きのテスト/Lint修正や指示が一意な単一の指摘なら medium、複数ファイルにまたがる・原因調査を伴う・設計の再考を求めるものなら high。判定が割れたら上の段を選ぶ
1つの指摘にマークアップの修正とロジックの修正が混ざっている場合（例: 「この一覧の余白がデザインとずれているうえ、取得件数の上限も違う」）は、create-review-fix-plan の返却の分離に従って別タスクとして扱う。返却が分離されていない場合は本フェーズで分割し、マークアップ部分だけを frontend-implementer に、残りを general-purpose-assistant に委譲する。同一ファイルを触るため、この2タスクは逐次で実行し、両方が同じ指摘に紐づくことをブリーフィングに明記する（Resolve時に取りこぼさないため）。
マークアップ修正が数行で完結し、分割コストが上回る場合は分割せず1タスクにまとめてよい。その場合の担当は general-purpose-assistant にする。
以下のいずれかに該当するタスク同士は 逐次 で実行する：
それ以外は 並列 で実行する。並列実行する場合は、1メッセージ内で複数のAgent tool callを発行すること（順次呼び出しでは並列にならない）。
サブエージェントは現在の会話履歴を持たないため、起動時は以下を すべて プロンプトに含めること。自己完結したブリーフィングが品質を決める。
【背景】PR #$0 のレビュー指摘対応: <PRタイトル要約>
【あなたが担当する指摘】
<レビューコメント本文を引用>
- 対象ファイル: <path:line>
- 指摘者の意図: <create-review-fix-plan が抽出した要約>
【Issueの要件（正）】
<関連Issue番号と、担当する指摘に関わる要件・確認事項の回答の引用。無ければ「関連Issueなし」>
指摘の解消がこれと矛盾する場合は実装せず、矛盾する箇所を報告して終える。要件に無い挙動を足して指摘を解消しない。
【対象範囲（編集可ファイル/ディレクトリ）】
<具体パスを列挙。範囲外を触らないこと>
【触れてはいけないファイル】
<並列実行中の他タスクが触る予定のファイル>
【完了条件】
- レビュアーの指摘内容が解消されていること
- 該当箇所のユニットテストが追加・更新され、すべてpassすること
- プロジェクトにE2Eテストが存在し、担当する修正がユーザー操作フローに影響する場合: 該当フローのE2Eテストが追加・更新され、passすること（E2Eテストの所在・実行コマンド: <パスとコマンド。存在しない場合はこの行ごと削除>）
- `npm run lint`（またはプロジェクト指定のlint）に該当ファイルでエラーがないこと
- 既存の挙動を意図せず変更していないこと
【スコープ】
上記の指摘を解消する変更だけを行う。範囲外のリファクタ・命名整理・周辺の改善を足さない。気づいた別の問題は修正せず、報告に1行で挙げるだけにする。
【参考情報】
- レビューコメントへの直リンク
- 既存の類似実装の参照先（あれば）
【作業ディレクトリ】
<worktreeの絶対パス>。すべてのコマンドはここを基準に実行すること。
【報告】
指摘をどう解消したか（対象ファイルと要点）・完了条件の充足状況・残課題を簡潔に。埋め草の要約セクションは不要。
サブエージェントが完了報告を返したら、本体側で git diff --stat を実行して変更範囲が宣言通りか検証する。範囲外の変更や指摘と無関係な変更があれば、当該サブエージェントを再起動して修正させる。
すべてのサブエージェントが完了したら、本体で以下を順に実行：
package.json の scripts.test を確認）scripts の test:e2e / e2e 等）scripts.lint）general-purpose-assistant（単一ファイルの自明な修正なら lightweight-assistant）に 失敗ログ全文と該当ファイルパス を渡して修正させるEdit で修正する。滑り坂ガード（1件ごとに独立判定・範囲を広げない・3件で以降は委譲へ切替）を必ず守るユニットテスト/E2Eテスト/Lintコマンドがプロジェクトに存在しない場合はスキップしてよい（その旨を最終報告に含めること）。
commit-push skill を呼び出し、変更をコミット・push。git status --short が空（要件優先で見送った指摘だけでコード変更が無い）の場合は、コミット・pushを行わずにフェーズ5を完了扱いとしてフェーズ6へ進む（見送りの返信と Resolve に修正 push は不要なため）フェーズ5の push が完了してから（差分が無くフェーズ5を完了扱いにした場合はその時点から）このフェーズに入ること。 本フェーズの Resolve は未解決スレッドを全件対象にするため、修正が push されていない段階で実行すると、対応していない指摘まで Resolve されてレビュー未対応のままマージされうる。フェーズ2〜5のいずれかで中断した場合は、Resolve を行わずに中断理由を報告して終了する。
add_reply_to_pull_request_comment を優先し、利用不可なら gh api repos/{owner}/{repo}/pulls/$0/comments/<comment_id>/replies -f body=... へフォールバックする。会話コメント由来なら gh pr comment $0（MCP は add_issue_comment）で返す。返信せずに Resolve すると、要件を理由に見送った事実がGitHub上に残らず、後から「指摘を無視した」ようにしか見えない。MCP・フォールバックの両方で返信に失敗したインラインスレッドは thread ID（PRRT_...）を記録し、次の Resolve の対象から外す。失敗件数と thread ID は最終報告に含めるresolve-pr-comments skill を PR 番号 $0（返信に失敗したスレッドがあれば、続けてその thread ID を除外対象として列挙）を渡して呼び出し、対応済みのレビューコメントをすべてResolveする。同スキルは GitHub MCP（pull_request_review_write の resolve_thread）を優先し、利用不可なら gh の GraphQL へフォールバックする。Resolve に失敗したスレッドが報告された場合は、件数と thread ID を本スキルの最終報告にも引き継ぐgh pr edit $0 --body "<更新後の本文>" を使用## 修正履歴 セクションを必ず設ける。既存のdescriptionに無ければ末尾に新規追加し、既にあれば追記する形で残す。各エントリは以下のフォーマットに従う:
## 修正履歴
### YYYY-MM-DD: レビュー指摘対応（<件数>件）
- <対応した指摘の要約1>（対応コミット: <commit hash 短縮>）
- <対応した指摘の要約2>（対応コミット: <commit hash 短縮>）
- 要件優先で見送り: <指摘の要約>（根拠: Issue #<N> の<要件・回答の箇所>）
date +%Y-%m-%d で取得した実行日を使用する## 実装委任の自己監査
- 起動したサブエージェント: <エージェント名 × 件数。例: general-purpose-assistant × 2, lightweight-assistant × 1>
- メインエージェントによる直接編集: なし / あり（<件数>件）
- <対象ファイル>: <変更行数> / <判定根拠。ステップ2の1〜5をどう満たしたか>
実行中に何らかの理由でPRをクローズする判断に至った場合（例: 指摘が別アプローチでの再実装を求めている、要件の陳腐化、別PRで対応済み、コンフリクト解消不能など）は、PRと 関連Issueを必ず連動してクローズする。PRだけ閉じてIssueをOPENのまま残すと他の作業者が同じスコープに重複着手するため、片側だけのクローズは禁止する。クローズ判断はフェーズ0の安全ガードとは独立に発生し得るため、判断時点でこのルールを適用すること。
手順:
gh pr close $0 --comment "<クローズ理由。代替PR/Issueがあればそのリンクを含める>"
pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。優先順位:
gh pr view $0 --json closingIssuesReferences -q '.closingIssuesReferences[].number'（GitHubが自動認識したリンク）gh pr view $0 --json body -q '.body' の本文から Closes #<n> / Fixes #<n> / Resolves #<n> を正規表現で抽出するOPEN の場合のみ以下を実行する。GitHub MCP が使える場合は issue_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。
gh issue view <n> --json state -q '.state'
gh issue comment <n> --body-file - <<EOF
## 関連PRクローズに伴うクローズ
PR #$0 を以下の理由でクローズしました。本Issueの作業はこのPR内では行いません。
### クローズ理由
<理由>
### 今後の扱い
<代替PR/Issueがあればリンク。再着手が必要な場合はその旨と新規Issue番号>
EOF
bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh close-issue <n> not_planned
pwd 再確認を推奨git diff で実際の差分を必ず検証する--no-verify やテストのスキップで誤魔化さず、原因を特定してから修正する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.