Menu
Address unresolved review comments on specified PR
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | fix-review-point |
| description | Address unresolved review comments on specified PR |
| argument-hint | [pr-number] |
| hooks | {"Stop":[{"matcher":"","hooks":[{"type":"command","command":"node \"${CLAUDE_PLUGIN_ROOT}/scripts/stop-servers.mjs\""}]}]} |
GitHub PR $0 の未解決レビューコメントに対応し、修正のコミット・push・Resolve・description更新までを完遂するスキルです。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。
自律実行モード: ユーザーへの確認を求めずに最後まで自律的に完遂すること。判断が必要な場面では本ドキュメントの既定挙動に従って自動的に意思決定し、処理を継続する。確認のために停止することは禁止（フェーズ0の安全ガード条件に該当する場合のみ中断可）。
本スキル固有のリスク: 本スキルは claude-task-worker の cc-fix-onetime ラベルをトリガーに自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-fix-onetime の除去やコールバックコメント投稿を進める。処理が未完のままターンを終えると、修正コミット未 push のまま Resolve だけ済まされたり、レビュー未対応のまま fix ラベルが外れて放置される状態壊れが起きる。
メインエージェント（本スキルを実行しているセッション本体）の役割は「指摘の分解・委譲・検証・統合」であり、規模の大きい指摘・並列化できる指摘の修正主体はサブエージェントである。ただし、レビュー指摘には1ファイル数行で済むものが相当数あり、数回のツール呼び出しで自分で終わる修正まで委譲すると、ブリーフィング作成とサブエージェント側の再探索でコストと時間が倍になる。指摘ごとに下記の判定を行って委譲/直接編集を決める（プラン全体で一括判定しない）。
判定は着手前に行い、判定結果（どちらを選んだか・根拠となった条件）を記録して最終報告の自己監査に載せる。
frontend-implementer.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テスト実行コマンドがあるE2Eテストが存在すると判定した場合：
E2Eテストが存在しない場合は、レビュー指摘が明示的に要求しない限りE2Eテスト基盤を新規導入しない（スコープ外の変更となるため）。
並列で以下を確認する。1つでも失敗したら、その場で原因を解消してから先に進むこと。
gh pr view $0 --json number,state,headRefName,isDraft でPRが存在し OPEN であることを確認する。CLOSED/MERGEDなら処理を中断gh pr checkout $0 >/dev/null 2>&1 でPRブランチをチェックアウトpwd で .claude/worktrees/ 配下にいることを確認する。worktree外なら安全のため処理を中断する（デフォルトブランチで作業してはならない）gh repo view --json defaultBranchRef -q .defaultBranchRef.name でデフォルトブランチ名を取得し、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 で呼び出し、以下を取得する：
修正点がない場合: gh pr checks $0 でCIの全チェックが Pass していることを確認する。Pass している場合は gh pr merge $0 --merge --delete-branch でPRをマージして終了する。チェックが失敗中の場合はマージせず、CI失敗状況をレビュアーに報告して終了する。
返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。
完了条件: 修正タスクが「並列実行可能なグループ」と「逐次グループ」に分類できていること。
修正タスク（指摘）ごとに、まず「実装の委任（判断ロジック）」のステップ1〜3で委譲するか直接編集するかを判定する。委譲すると決めたタスクについて、以下の判断軸でサブエージェントを選定し、実行をそのサブエージェントに委任すること
.pen を参照元としてUIに変換する）場合は必ずこのエージェントを使うこと.pen）自体の編集・更新（要素追加、レイアウト変更、スタイル修正、テキスト差し替えなど）。.pen への編集タスクは必ずこのエージェントに任せること以下のいずれかに該当するタスク同士は 逐次 で実行する：
それ以外は 並列 で実行する。並列実行する場合は、1メッセージ内で複数のAgent tool callを発行すること（順次呼び出しでは並列にならない）。
サブエージェントは現在の会話履歴を持たないため、起動時は以下を すべて プロンプトに含めること。自己完結したブリーフィングが品質を決める。
【背景】PR #$0 のレビュー指摘対応: <PRタイトル要約>
【あなたが担当する指摘】
<レビューコメント本文を引用>
- 対象ファイル: <path:line>
- 指摘者の意図: <create-review-fix-plan が抽出した要約>
【対象範囲（編集可ファイル/ディレクトリ）】
<具体パスを列挙。範囲外を触らないこと>
【触れてはいけないファイル】
<並列実行中の他タスクが触る予定のファイル>
【完了条件】
- レビュアーの指摘内容が解消されていること
- 該当箇所のユニットテストが追加・更新され、すべて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 を呼び出し、変更をコミット・pushresolve-pr-comments skill を呼び出し、対応済みのレビューコメントをすべてResolveするgh pr edit $0 --body "<更新後の本文>" を使用## 修正履歴 セクションを必ず設ける。既存のdescriptionに無ければ末尾に新規追加し、既にあれば追記する形で残す。各エントリは以下のフォーマットに従う:
## 修正履歴
### YYYY-MM-DD: レビュー指摘対応（<件数>件）
- <対応した指摘の要約1>（対応コミット: <commit hash 短縮>）
- <対応した指摘の要約2>（対応コミット: <commit hash 短縮>）
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があればそのリンクを含める>"
gh pr view $0 --json closingIssuesReferences -q '.closingIssuesReferences[].number'（GitHubが自動認識したリンク）gh pr view $0 --json body -q '.body' の本文から Closes #<n> / Fixes #<n> / Resolves #<n> を正規表現で抽出するgh issue view <n> --json state -q '.state' で状態を確認し、OPEN の場合のみ以下を実行する。
gh issue comment <n> --body-file - <<EOF
## 関連PRクローズに伴うクローズ
PR #$0 を以下の理由でクローズしました。本Issueの作業はこのPR内では行いません。
### クローズ理由
<理由>
### 今後の扱い
<代替PR/Issueがあればリンク。再着手が必要な場合はその旨と新規Issue番号>
EOF
gh issue close <n> --reason "not planned"
pwd 再確認を推奨git diff で実際の差分を必ず検証する--no-verify やテストのスキップで誤魔化さず、原因を特定してから修正する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