/review-response

引数

• <pr-number>: 対象 PR 番号（省略時はカレント branch の PR を ccx pr context が推論）
• --worktree: 対象 PR の worktree に切替（既存があれば再利用、無ければ作成）
• --dry-run: 修正案・コメント返信案を報告する。返信・再依頼・決定の書き下ろしは実行せず、修正はユーザーの承認後に行う

/loop 10m /review-response のように /loop の下で実行しているときは、最初のステップの前に references/loop.md を読む。

実行内容

以下の各リストは書かれた順に実行するステップの列で、他の節からはステップ名で参照する。

Worktree 解決（--worktree 指定時のみ、最初に実行）

Skill ツールで worktree-resolution を起動し、その「PR worktree 解決手順」に従って対象 PR の worktree に session を切り替える。

共通手順（両モードで実行）

• コンテキスト取得: ccx pr context <scratchpadディレクトリ> [<pr-number>] を実行する。返された path がこの実行の唯一のドキュメントで、以降のステップはすべてこれを指す。work_dir / threads_path も返された値だけを使う。取得は1実行1回で、修正を push した後も取り直さない。ドキュメントは jq で必要部分を段階的に参照する。打ち切りが発生したら ccx pr context --help が示す環境変数で上限を引き上げて再実行する
• 鮮度確認: Skill ツールで worktree-resolution を起動し、その「共通サブ手順: PR head との鮮度確認」を、ドキュメントのパスをコマンド引数にして実行する。--worktree の有無に関わらず実行し、--dry-run でも同期は省略しない。停止条件に該当したら修正・返信を開始しない
• 判断対象の有無の確認: ドキュメントから pending・reviewers・reviews_truncated だけを jq で取り出して読み、pending.threads[] / pending.reviews[] / pending.comments[] がすべて空なら「判断対象なし」を1行報告してこの実行（/loop では当該イテレーション）を終える。判断の記録も行わない。終了報告には ball: "theirs" の一覧（「行コメントスレッドの扱い」）と、下記のレビュアーの立ち位置を添える。件数の判定は pending の3リストだけを出典とし、reviews[] / comments[] を自前のセレクタで数え直さない
  • レビュアーの立ち位置の報告: reviewers[] の各要素を author と state で1行ずつ書き、状態を自分で導出しない。author_type が Bot の要素にはその旨を添え、author が null の要素は (deleted account) と書く。reviews_truncated: true のときは、一覧が取得窓の内側しか表さない旨を併記する。途中停止を含め、実行を閉じるユーザーへの報告すべてに載せる（is_own_pr は条件にしない）
  • PR の状態は出典を持つものだけ書く: 報告で PR の状態に触れるときはドキュメントの当該フィールドを出典にし、「まだ誰もレビューしていない」「マージできる状態」等を推測で書かない（reviewers[] を読まずに推測で答え、事実と食い違ったことがある）
• PR 全体の読解: 「PR 全体の読解」に従って PR を読む
• 指摘の列挙: review_threads[]・reviews[]・comments[] の3種類を必ず読んで突き合わせ、重複と通常コメント上で合意済みの議題を除いた上で指摘を列挙する（規定は「ソース別の扱い」）。出力は「対応対象の指摘」と「反応待ちスレッド」の2グループで、後者は修正要否の判断へ進めず報告する
• 修正要否の判断: 各指摘について修正すべきか判断する（「判断基準」）

dry-runモード（--dry-run）

--dry-run のときは通常モードの代わりに、共通手順に続けて references/dry-run.md に従う。判断と案の報告では references/posting.md も読む。

通常モード（--dry-run なし）

• 修正の実装: 修正すべき指摘を実装し、コミット・プッシュまで行う。プッシュ前に、プロジェクト CLAUDE.md が修正後に求める手順（テスト・Lint・品質レビュー等）をすべて実行する（明示がなければ推測で実行せずスキップする。数分以上かかる見込みなら run_in_background: true）
• 修正不要の返信起案: 修正不要な指摘には理由を説明する返信文を起案する（「修正不要と判断して返信する場合」）
• 返信の投稿とスレッドの解決: references/posting.md を読み、その「スレッドへの返信と解決」に従って、用意した返信をまとめて投稿し、解決できるスレッドを解決する。完了報告の文面は同ファイルの「修正完了報告フォーマット」に従う
• レビュー再依頼: references/posting.md の「レビュー再依頼」に従う
• 判断の記録: ccx pr seen <ドキュメント> を実行する。ユーザーへエスカレーションした指摘があっても必ず行う

PR 全体の読解

指摘を1件も読む前に、PR が何をしようとしていて何を変えたのかを組み立て直す。

実行条件: 判断対象の有無の確認を通ったすべての実行。--dry-run と /loop の各イテレーションでも省略しない（pr-reading の「ステートレス」）。

手順: Skill ツールで pr-reading を起動し、その手順に従って読む。起動時に名指すのは、container がドキュメントの linked_issues[] と warnings[]、文書がそのドキュメント、差分・コミットの取得元が同じ文書、報告先が下記「報告」。ahead_own（未 push のローカル commit がある状態）でも取得元は文書側 — 指摘が付いているのは push 済みの行なので、手元の差分に読み替えない。comments_truncated: true の上限の上げ方は ccx pr context --help にある。

会話を読む位置: 指摘の本文（reviews[] / review_threads[] / comments[]）を読むのは読解の後。唯一の例外は「行コメントスレッドの扱い」の theirs 報告。

報告: pr-reading の「報告」の1文を、判断前の既存の出力（「対応対象の指摘」「反応待ちスレッド」）より前に出す。

ソース別の扱い

行コメントスレッドの扱い

行コメントスレッド（review_threads[]）は ball で分類する（各値の意味は ccx pr context --help）:

• ball: "mine": 対応対象。修正要否の判断へ進める
• ball: "theirs": 「反応待ち」に分類し、修正要否の判断へ進めない
• ball: "none": skip

補足:

• theirs に分類したスレッドは必ず報告する: path:line と last_comment の要旨を列挙する。通常モードは対応開始前、dry-run は指摘の報告と併せて出す。判断対象の有無の確認で終える実行に限り、読解前に review_threads[].last_comment を読んでよい。該当0件なら何も出さない。「対応済み」と推定しない
• ユーザーが theirs のスレッドへの再対応を明示的に指示した場合は返信する（エントリの書き方は references/posting.md の「スレッドへの返信と解決」）。none のスレッドは報告に含めるところまでで、返信・解決はできない
• 人間が1人でも参加したスレッドは作者側では閉じず、未解決のまま残す（レビュアー側が /deep-review の「コメントモードON時: 前回指摘スレッドへの返信・解決」で閉じる）

レビュー本文の扱い

レビュー本文（reviews[].body）には、行コメントに存在しない独立した指摘（優先度付きリスト、「テストが不足」等のサマリー指摘）が含まれうる:

• 本文の指摘も個別対応対象: 行コメントと同じ粒度で修正・返信判断を行う
• pending.reviews[] が挙げないレビュー本文も列挙の対象: ただしそれ自体は実行の理由にならない
• 重複チェック: 本文の指摘が行コメントと同じ内容なら1件として扱う
• 優先度付きリスト: 「優先度1/2/3」「Must/Should/Nice」等の構造がある場合、各項目を独立した指摘として列挙

通常コメントの扱い

• 主用途は議論経緯の参照: 通常コメント上で既に解決済みの議題を重複して修正・返信しない。自分の login のコメントも comments[] で議論経緯として参照する
• 明示的な修正依頼は指摘として扱う: レビュアーが通常コメントに書いた修正依頼は、行コメントと同じ粒度で修正・返信判断の対象に含める。対応報告・CI通知・雑談は対象外

レビュー本文・通常コメント由来の指摘は、PR 全体へのコメント（ccx pr comment）で対応完了を報告する。

判断基準

原則

• 技術的事実で判断する: 修正要否は好みではなく技術的事実・データに基づいて判断する
• 修正要否の確定前に検証する: Skill ツールで finding-triage を起動し、その規律で検証してから各指摘の修正・修正不要を確定する。同スキルの「検証根拠の記録」が根拠を求める修正は、修正完了報告に検証で確認した参照先を添える
• レビュアーのラベルを尊重する: issue(blocking): / suggestion(non-blocking): / nit: 等の Conventional Comments ラベルや優先度表記が付いている場合、スキル独自の分類より優先する。blocking は原則修正、non-blocking / nit は以下の基準で判断（検証の写像: blocking / non-blocking / nit はいずれも finding-triage の「対応が期待される指摘」、質問は対象外）
• 返信・コメントの言語は対象 PR に合わせる: 投稿する返信・PR コメントは対象 PR の記述言語（PR 本文・既存レビューコメント）で書き、セッションの言語設定に引きずられない

修正すべき指摘

• バグリスク: 実行時エラーの可能性、ロジック誤り
• セキュリティ: 脆弱な実装パターン
• 型安全性: any型の使用、型定義の不備
• パフォーマンス: 明らかな性能問題
• 保守性: コードの重複、複雑度問題
• 可読性（理解困難の指摘）: レビュアーが「分かりにくい」「なぜこうなっているのか」と述べた場合、スレッドの説明返信で済ませずコード自体を明確化する（リネーム・分割等）。難しければ理由をコードコメントとして残す
• 安価な nitpick: typo・リネーム等、修正コストがほぼゼロで内容に同意できるもの

修正不要と判断して返信する場合

返信には finding-triage の検証で確認した参照先（ファイル・grep 可能な識別子）を含める。非必須（「推奨」等）と記載されたルール、または既存パターンの踏襲を根拠にする見送りは、finding-triage の「一様準拠判定」を通してから確定する。

• 既存パターン踏襲: プロジェクト標準・既存規約に準拠している。踏襲元はその実行の中で checkout を grep して実在を確かめる。grep が何も見つけられなければ、または一様準拠判定で成立しなければこの根拠は使えない — 別の根拠で判断し直すか、「ユーザーに最終判断を委ねる場合」としてエスカレーションする
• 好みの問題: 技術的根拠のないスタイル選好で、修正コストに見合わないもの
• スコープ外の正当な指摘: 本PRでは対応しない場合、握りつぶさず Issue 化して返信にリンクする

ユーザーに最終判断を委ねる場合（自動で確定しない）

• 設計思想に関わる指摘: 意図的な設計判断への異論は、根拠を添えた返信で議論を開くまでを行い、スレッドは解決しない。修正するか押し返すかはユーザーに確認する
  • 議論を開く返信は、決定がどこに記録されているかを名指す。引用してよいのは linked_issues[].body / linked_issues[].comments[].body / parent.body / parent.comments[].body / pr.body / commits[].message / コードコメントのいずれかで、どこに書かれているかを返信に書く。記憶や推測を「意図的な設計です」と述べない
  • どれにも記録が無ければ、返信を投稿せずエスカレーションが先。何をどこで探したかを添えてユーザーに提示し、ユーザーが意図を確認したら references/write-down.md に従って先に書き下ろしてから返信する
• 人間レビュアーの blocking 指摘に反対する場合: 同上。反論の根拠を整理して提示し、ユーザーの判断を仰ぐ