メニュー
PRのレビューコメントを確認し、対応・返信するSkill。 ユーザーが「レビューコメントに対応して」「PRコメントに返信して」のように依頼したら使うこと。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | github-resolve-pr-comment |
| description | PRのレビューコメントを確認し、対応・返信するSkill。 ユーザーが「レビューコメントに対応して」「PRコメントに返信して」のように依頼したら使うこと。 |
| allowed-tools | Read, Edit, Write, Bash(git:*), Bash(gh:*), Bash(cat:*), Bash(ls:*), Bash(bat:*), Bash(eza:*), Bash(grep:*), Bash(head:*), Bash(tail:*), Bash(jq:*), Bash(mktemp:*), Bash(bash:*) |
GitHub操作は必ずgh CLIで行うこと。GitHub connector/pluginやMCPのGitHubツールは使用しない。
PR number: 対応するPR番号（任意、デフォルトは現在のブランチのPR）--dry-run: コメントの分類結果（Must Fix/Should Fix/質問/情報共有）と対応方針のみを提示し、ファイル編集・commit・push・リプライ投稿を一切行わない対応後は常にGitHubへリプライコメントを投稿する。
inline review thread / conversation は isResolved を基準にし、すべての unresolved thread を対応対象にする。
review 全体の state や isOutdated だけで対応対象から除外しない。
PR には性質の異なる3種類のコメントがある。それぞれ取得方法もリプライ方法も違うので混同しないこと。
reviewThreads (fetch_review_threads.sh)repos/{owner/repo}/pulls/{pr}/comments/{root-comment-id}/replies に thread 内コメントとして追記databaseId（root comment id）を使うこと。スレッド内の途中コメントのIDではない。fetch_review_threads.sh は root_comment_id フィールドにこのIDを入れて返す。COMMENTED / CHANGES_REQUESTED などの state を持つ。
gh pr view <pr> --json reviewsgh pr view <pr> --json comments または gh api /issues/{pr}/commentsrepos/{owner/repo}/issues/{pr}/comments に新規 issue comment として投稿gh pr view --json number --jq '.number'owner/repo を取得する: gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'以下を並列に実行する。
全 unresolved review thread を取得（inline コメント）:
bash <skill-dir>/scripts/fetch_review_threads.sh \
--repo "<owner/repo>" \
--pr <number> \
--only-unresolved > /tmp/pr-<number>-respond-threads.json
--only-unresolved は isResolved=false の thread を返す。isOutdated=true でも unresolved なら対象に含めるthread_id / path / line / root_comment_id / comments[] を持つroot_comment_id（スレッド先頭コメントの databaseId）を使うReview summary body を取得:
gh pr view <number> --json reviews \
--jq '.reviews | map(select(.state != "APPROVED" and (.body | length) > 0))' \
> /tmp/pr-<number>-respond-reviews.json
state == "APPROVED" で本文が空のものは「LGTM」相当なので除外するPR-level issue comments を取得:
gh pr view <number> --json comments \
--jq '.comments' > /tmp/pr-<number>-respond-issue-comments.json
複数レビュー・複数コメントを横断して整理する。最新のレビューだけでなく、過去のレビューや issue comment も含めて全件を対象にする。
集約ルール:
集約後、次のように分類する（inline review thread は全 unresolved thread を対象にし、review 全体の state では除外しない）。
レビューコメントの重要度を Must Fix / Should Fix に分け、対応方針を決定する。
Must Fix / must / blocking / required と明示している指摘Should Fix / should / suggestion / nit と明示している指摘判断時は次を確認する:
--dry-run が指定された場合は、Phase 3 で確定したコメントの分類結果（Must Fix/Should Fix/質問/情報共有）と対応方針のみを提示し、以降のファイル編集・commit・push・リプライ投稿は行わずに終了する。
検出された言語でコミットメッセージを記述してコミット・プッシュする。 コード変更が一切ない場合（質問への回答のみ等）はこのフェーズをスキップする。
対応した各コメントへのリプライを常に投稿する。 リプライ先により使用するスクリプトが異なる。
コード行に紐づく review thread に対するリプライ。全 unresolved thread にリプライする。
スレッド内コメントとして追記される。使用するスクリプトは post_review_reply.sh。
リプライ本文はアクションに応じて内容を変える:
Fixed in abc1234. Changed X to Y as suggested.abc1234 で修正しました。ご指摘の通り X を Y に変更しました。Thanks for the suggestion! I chose X because [reason]. However, I see your point about Y. Could you clarify [question]?ご提案ありがとうございます。[理由] のため X を選択しましたが、Y についてのご指摘も理解できます。[question] について教えていただけますか？I'd like to keep this as-is because [technical reason]. ...[技術的な理由] のため、現状維持としたいです。...手順:
/tmp/pr-reply-<root-comment-id>.mdpost_review_reply.sh で投稿する
<root-comment-id> は fetch_review_threads.sh の出力の root_comment_id を使う（スレッド先頭コメントの databaseId）bash <skill-dir>/scripts/post_review_reply.sh \
--repo "<owner/repo>" \
--pr <number> \
--review-comment-id <root-comment-id> \
--body-file /tmp/pr-reply-<root-comment-id>.md
PR 全体への対応サマリーを1つの issue comment として投稿する。使用するスクリプトは post_issue_comment.sh。
本文の構成:
[filename:line](review-comment-url) 形式）で参照するtemplate:
references/comment_summary_template.mdreferences/comment_summary_template_ja.md記述ルール:
手順:
/tmp/pr-summary-<number>.mdpost_issue_comment.sh で投稿するbash <skill-dir>/scripts/post_issue_comment.sh \
--repo "<owner/repo>" \
--pr <number> \
--body-file /tmp/pr-summary-<number>.md
Phase 6-B で投稿した PR-level コメント（コメントサマリー）の本文をそのまま出力する。
isResolved=true) はスキップする。isOutdated=true は単独では除外条件にせず、unresolved なら対応対象に含める-f body=... や --body "..." でのシェル引数渡しは禁止databaseId（root_comment_id）を使う。スレッド内途中のコメントIDだと 404 になるGitHubのPull Request(PR)のコードレビューを行うSkill。worktreeを作成してソースコード全体を読みながらFinder SubAgentで指摘候補を発見し、Verifier SubAgentで検証する。レビューをレポートとインラインコメントで投稿する。self reviewにも対応する。 ユーザーが「このPRをレビューして」のように依頼したら使うこと。
Agent skill (SKILL.md)の品質を評価基準に沿って採点し、観点ごとの判定と修正案をレポートするSkill。 評価のみ行い、ファイルの編集はしない。 ユーザーが「このskillを評価して」「skillをレビューして」「SKILL.mdの品質を見て」のように依頼したら必ずこのSkillを使うこと。 skillの新規作成や編集そのものを依頼された場合は使わない。
GitHub issueを起点に「調査 → worktree作成 → 実装 → PR作成」を一気通貫で実行するSkill。実装はSubAgentに委譲し、commitとPR作成はgit-commit・github-pr-create skillに連結して実行する。「#N をsubagentで解決して」「実装をsubagentに任せてissueからPRまで」のような依頼に使う。
Pull Requestを作成するSkill。現在のbranchからpull requestを作成する。言語指定可能。 ユーザーが「PR作って」「pull request作成して」のように依頼したら使うこと。
計画や設計について、意思決定のあらゆる分岐点が解消されるまで、徹底的に質問を繰り返してください。ユーザーが計画の改善・詳細化・最適化を望んでいる場合や、設計について厳しく問い詰めてほしいと言われたとき、あるいは「計画(Plan)を詰めて」、「計画(Plan)を改善して」と要望があった際にこの手順を使用してください。
weztermのpane・tab・windowを `wezterm cli` で操作するskill。paneの分割・フォーカス移動・リサイズ・zoom・close、 tab/windowの作成・切替・リネーム、paneの表示内容の読み取り、paneへのコマンド送信と実行結果の確認を行う。 ユーザーが「weztermのpaneを分割して」「weztermの別paneでコマンドを実行して」のように、weztermと明示して依頼したときだけ使うこと。 ユーザーはtmuxも併用しているため、「paneを分割して」のようにweztermと明示されていないpane/tab操作の依頼では使わない (どちらを指すかユーザーに確認する)。 tmuxの操作、およびwezterm自体の設定 (wezterm.luaやkeybinding) の変更にも使わない。