Menu
Use when addressing PR review comments - checking pending reviews, fetching unresolved threads, evaluating each comment, and deciding to fix or explain non-problematic
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
WHEN: the user wants a critical review by the `code-critic` agent. The skill gathers the agent's required Invocation Contract inputs (review target, intent, layer), dispatches the agent via the Agent tool, and drives the **address-then-resubmit** loop until the agent returns an `Approved` verdict or the user explicitly defers what is left.
WHEN: PROACTIVELY when the change introduces or modifies design (new abstraction, new boundary, new module, contract change, security-sensitive interaction, refactor that reshapes responsibility). INPUT: File paths/directory + intent of the change. OUTPUT: Design-level critical issues — contract gaps, architectural misalignment, over-/under-engineered abstractions, security-designed-in failures, systemic problems hidden behind local fixes — with root causes and structural fixes. Implementation defects (logic bugs, races, resource leaks) are out of scope; route those to critic-implementation-review.
WHEN: PROACTIVELY when reviewing code that implements an already-settled design (bug fixes, feature implementation against an agreed shape, optimizations inside an existing module). INPUT: File paths/directory + the design contract being implemented. OUTPUT: Implementation-level critical defects — logic errors, race conditions, resource leaks, concrete security bugs, error-handling gaps, performance problems on real-sized inputs, contract drift between signature and behavior — with concrete fixes. Design-level concerns (abstraction quality, contract shape, architectural fit) are out of scope; route those to critic-design-review.
PRのライフサイクル全体をゲート付きで管理する。PR作成、レビュー対応、マージ、ポストマージまでの一連のワークフローを強制する。PRを作りたい、レビュー対応したい、マージしたい、といった場面で使用する。
OrbStack がホストの Docker runtime として常に利用可能である前提で、Docker Compose 開発環境にアクセスする方法。OrbStack 特有の自動 DNS・自動 port forwarding を活用し、dnsmasq や ports: 公開の手間を省く。Docker Compose 上の Rails/Node 等のサーバーにローカルからアクセスする場面、マルチテナントアプリのサブドメインルーティングを検証する場面で使用する。
Five Whys分析で問題の根本原因を特定し、本質的な解決策を導出する。問題の原因分析、根本原因の特定、なぜなぜ分析、トラブルシューティング、障害分析、インシデント振り返り、ポストモーテムなど、「なぜこの問題が起きたのか」を深掘りして解決策を考えたい場面で使用する。ユーザーが問題の原因について悩んでいたり、表面的な対処ではなく根本的な解決を求めている場合にも発動する。
| name | address-pr-review |
| description | Use when addressing PR review comments - checking pending reviews, fetching unresolved threads, evaluating each comment, and deciding to fix or explain non-problematic |
| user-invocable | true |
PRのレビューコメントに体系的に対応する。PR番号は $ARGUMENTS で与えられる。与えられなければカレントブランチのPRを対象とする。
digraph workflow {
"1. PR状態確認" -> "pending reviewerあり？";
"pending reviewerあり？" -> "Copilot？" [label="yes"];
"pending reviewerあり？" -> "2. 未解決コメント取得" [label="no"];
"Copilot？" -> "待機: Copilotレビュー完了まで" [label="yes"];
"Copilot？" -> "ユーザーに待機か続行か確認" [label="no"];
"待機: Copilotレビュー完了まで" -> "2. 未解決コメント取得";
"ユーザーに待機か続行か確認" -> "終了" [label="待機"];
"ユーザーに待機か続行か確認" -> "2. 未解決コメント取得" [label="続行"];
"2. 未解決コメント取得" -> "未解決コメントなし？";
"未解決コメントなし？" -> "終了: 対応不要" [label="yes"];
"未解決コメントなし？" -> "3. PRブランチをチェックアウト" [label="no"];
"3. PRブランチをチェックアウト" -> "4. 各コメントを評価・対応";
"4. 各コメントを評価・対応" -> "5. 完了確認";
}
gh pr view <NUMBER> --json reviewRequests,reviews,reviewDecision,state,headRefName
reviewRequests: 未提出のレビュアー一覧reviewDecision: APPROVED / CHANGES_REQUESTED / REVIEW_REQUIREDstate: OPEN / CLOSED / MERGED未提出レビュアーの扱い:
gh pr view --json には reviewThreads フィールドがない。GraphQL API必須。
同梱スクリプトを使用:
~/.claude/skills/address-pr-review/fetch-unresolved-threads.sh <NUMBER>
出力: 未解決スレッド(isResolved == false)のみのJSON配列。各要素は threadId, outdated, path, line, firstComment, replies を含む。outdated: true のスレッドも含まれるが、コード変更済みのため対応不要の可能性が高い。内容は確認すること。
gh pr checkout <NUMBER>
未解決スレッドごとに以下を実行:
path と line から対象ファイル・行を確認修正する:
問題なしと主張する:
対応を実行:
評価結果をユーザーに提示: 各コメントについて「修正する / 問題なしと主張する」の判断と理由をユーザーに示し、承認を得てから 返信する
スレッドに返信し、resolve する:
# スレッドの最初のコメントの databaseId を使用
gh api repos/{owner}/{repo}/pulls/<NUMBER>/comments \
-f body="<返信内容>" \
-F in_reply_to=<COMMENT_DATABASE_ID>
# 返信後、スレッドを resolve する（threadId は fetch-unresolved-threads.sh の出力から取得）
gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "<THREAD_ID>"}) { thread { isResolved } } }'
# 修正をpush
git push
# CIステータス確認
gh pr checks <NUMBER>
修正完了後、レビュアーに再レビューを依頼する場合:
gh api repos/{owner}/{repo}/pulls/<NUMBER>/requested_reviewers \
-f 'reviewers[]=<REVIEWER_LOGIN>'
gh api の {owner} と {repo} はカレントリポジトリから自動補完される