pr-review-comments-resolve

name	pr-review-comments-resolve
description	GitHub PRのレビューコメントのうち、Hide・解決済みでないものだけを抽出して対応する。
argument-hint	<PR番号 または PR URL> [--non-interactive]
disable-model-invocation	true
license	MIT

PRレビューコメント対応

引数としてPR番号またはPR URLを受け取る。省略された場合、手順1のスクリプトが現在のブランチに紐づくPRを自動検出する（gh pr viewベース）。ユーザーへの質問で立ち止まる必要はない。自動検出できなかった場合はスクリプトがエラー終了するので、その時点でPR番号またはPR URLをユーザーに尋ねる。

GitHub PRのレビューコメントに対応する。ここでいう「対応」は、コメントを読んで終わりではなく、 実際にコードを直し、コミットし、PRに反映するところまでを指す。

実行モード

引数に --non-interactive が含まれる場合は非対話モードとして振る舞う（claude -p などユーザーへ対話的に承認を取れない実行を想定）。含まれなければ通常の対話モード。

• モード判定はこの引数フラグの有無だけで行う。環境変数（CLAUDE_CODE_ENTRYPOINT など）で非対話かどうかを推測しない（確実に判定する公式手段がなく不安定なため）。
• --non-interactive はPR番号/URLとは独立した引数であり、順序は問わない。手順1のスクリプトに渡す位置引数はPR番号/URLのみなので、--non-interactive はスクリプトへ渡さず、このSKILL側で読み取って手順4の分岐に使う。

両モードで異なるのは手順4（PR本文の更新）だけ。それ以外の手順（PR自動検出・修正・コミット・push）はどちらのモードでも同じく自動で進めてよい。

なぜHide/解決状態で絞り込むのか

PRには「もう見なくていい」コメントが溜まっていることが多い：

• スパムや誤検知としてMinimize（Hide）されたコメント
• 既に対応済みでresolveされたスレッド

見なくていいコメントまで拾うと、本人が意図的にHideしたものを蒸し返したり、無関係な修正が紛れ込んだりする。 この絞り込み（Hide/解決の判定とページング）は判断の要らない定型処理なので、手順1のスクリプトに切り出してある。

手順

1. 未対応コメントを抽出する

スクリプトはこの SKILL.md と同じディレクトリの scripts/fetch-unresolved-comments.sh にある。

bash "<この SKILL.md のあるディレクトリ>/scripts/fetch-unresolved-comments.sh" <PR番号 または PR URL>

引数を省略すると現在のブランチに紐づくPRを対象にする。owner/repoはPR URLから抽出するか、無ければ現在のリポジトリから自動検出する。

stdout に isResolved == false かつ isMinimized == false のコメントだけを整形済みJSON配列で返す（reviewThreads のページングも内部で処理済み）:

[{ "id": "...", "databaseId": 123, "path": "...", "line": 10, "body": "..." }, ...]

抽出できたら、対象件数と各コメントの要旨（ファイル・指摘内容）を短く報告してから着手する。 0件だった場合はそこで完了を伝えて終わる（無理に何かを直そうとしない）。

2. 各指摘を実際に調査してから直す

レビューコメント、特にbotによる自動レビューは、提案（suggestionブロックなど）をそのまま鵜呑みにできるとは限らない。 指摘が指しているファイル・シンボルが現在のコードにまだその形で存在するか、提案されている修正先が 実際に正しい移行先かを、そのつど調べる。具体的には：

• 指摘が「参照切れ」「移行漏れ」を主張しているなら、grep/git logで参照元と移行先の実体を確認する
• 指摘が特定の関数・設定・ファイルを名指ししているなら、それが現在も同じ名前・同じ場所にあるか確認する
• コメントに suggestion ブロックが付いている場合も、周辺の実装や命名規則と整合するか一度目で確認してから採用する（コピペで即採用しない）

調査の結果、指摘が的外れ・スコープ外（例: 過去の設計判断の記録であって実害のあるリンク切れではない）と判断した場合は、 その理由を添えて対応をスキップしてよい。全部を無理やり直す必要はない。

3. 修正・コミット・push

手順2で全件スキップし、修正対象が0件になった場合はこの手順を省略し、次の「対応が終わったら」に進む。

• コミットの単位はファイル数ではなく関心事の一致度で決める。同じ問題・同じ意図に属する修正はファイルをまたいでいても1コミットにまとめ（例:「廃止されたパスへの参照をすべて新パスに直す」）、無関係な指摘への修正がたまたま同じファイルに集まった場合は分ける
• コミットメッセージはそのリポジトリの既存コミット（git log）のスタイルに倣う
• 修正・コミット・pushはここまで自動で進めてよい。ユーザーに都度確認を挟む必要はない

4. PR本文への反映

手順3を省略した場合（追加コミットが0件）は、この手順も省略する。

追加コミットによってPRの変更内容が増えた場合、既存のPR本文に反映漏れが出ることがある。 base branchとの git diff/git log（base..HEAD）からPR全体の変更点を洗い出し、 本文に反映すべき内容があるか判断する。反映すべき内容がなければこの手順は何もせず終える。 反映すべき内容がある場合の扱いは実行モードで分岐する。 追記の粒度は、コミット単位（＝関心事）ごとに1〜2行の要約でよい。詳細な理由や調査過程まで書き込む必要はない。 タイトルは全体を的確に要約できていれば変更不要のことが多い。

• 対話モード: 反映すべき内容を更新前にユーザーに提示して承認を取り、承認後にPR本文を更新する（PR本文の更新は外向きの操作なので、承認なしに自動で書き換えない）。

• 非対話モード（--non-interactive）: 承認を取れないためPR本文は書き換えない。代わりに反映すべき内容をPRにコメントとして投稿する。コメント本文の冒頭に、これがPR本文への反映提案であり非対話実行のため自動投稿したものである旨の短い前置きを付ける。

  gh pr comment <PR番号 または PR URL> --body "<提案本文>"
  

対応が終わったら

• どのコメントに対応し、どれをスキップしたか（理由付きで）を簡潔にまとめる
• commitのSHA・件名、PRのURLを報告する。追加コミットが0件だった場合（抽出0件、または全件スキップ）は、SHA・件名の欄を「新規コミットなし」と記載し、対象PRのURLのみ添える
• 非対話モードで手順4のPR本文反映提案コメントを投稿した場合は、そのコメントURL（取得できなければ投稿した旨）も報告に含める