/review-response

GitHubのレビューコメントに対応し、修正コミット・返信投稿・スレッド解決まで実行

使用方法

/review-response                          # 全自動：カレント branch の PR を対象に修正＋コメント返信＋解決
/review-response --dry-run                # 確認のみ：指摘点・修正案・コメント案を報告
/review-response 123                      # PR 123 を対象（カレント branch 以外を明示指定）
/review-response 123 --worktree           # PR 123 の worktree で対応（並列開発時の主要ユースケース）
/review-response 123 --worktree --dry-run # 上記 + 確認のみ
/loop 10m /review-response                # 定期実行（「/loop での定期実行」参照）

引数

• <pr-number>: 対象 PR 番号（省略時はカレント branch の PR を ccx pr context が推論）
• --worktree: 対象 PR の worktree に切替（既存があれば再利用、無ければ作成）。並列で別 issue を作業中にレビュー対応する際に推奨
• --dry-run: 修正案・コメント返信案を確認のみ（実行しない）

実行内容

以下の各リストは、書かれた順に実行するステップの列。他の節からはステップ名で参照する（番号を振ると、ステップの挿入で他所の参照が黙って壊れるため）。

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

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

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

• コンテキスト取得: ccx pr context で以下をすべて一括取得（「指摘・議論経緯の取得」参照）

- レビュー本文 (reviews[]): 総評・優先度付き指摘リスト・サマリー - 行コメント (review_threads[]): 未解決スレッド - 通常コメント (comments[]): PR本体へのタイムラインコメント（議論経緯・追加の修正依頼）

返された path がこの実行の唯一のドキュメントであり、以降のステップはすべてこれを指す。取得は1実行1回で、修正を push した後も取り直さない（投稿するコマンドが自分でローカル HEAD と GitHub の live head を突き合わせるため。「スレッドへの返信と解決」）。判断の記録もこのドキュメントの fetched_at を書くので、実行中に届いた指摘が未読のまま retire されることはない

• 鮮度確認: Skill ツールで worktree-resolution を起動し、その「共通サブ手順: PR head との鮮度確認」を、ドキュメントのパスをコマンド引数にして実行（停止条件に該当した場合は修正・返信を開始しない。stale なコードへの修正適用や、リモートで対応済みの指摘への二重対応を防ぐため。head branch の fetch はサブ手順のコマンドが毎回内部実行するため --worktree 時も省略されない — Worktree 解決後に取得したドキュメントの pr.head_oid が worktree 解決時の fetch より新しい可能性に対応する）。--dry-run でも同期は省略しない — 修正案・返信案の起案自体が最新 head を前提とし、同期は作業を破棄しない fast-forward のみのため
• 判断対象の有無の確認: ドキュメントから pending だけを jq で取り出して読み（文書全体を開かずに済ませるのがこのステップの意味）、pending.threads[] / pending.reviews[] / pending.comments[] がすべて空なら「判断対象なし」を1行報告してこの実行（/loop では当該イテレーション）を終える。以降のステップは1つも実行せず、判断に達していないので判断の記録も行わない。終了時の報告には ball: "theirs" の一覧を添える（内容は「行コメントスレッドの扱い」、/loop での省略は「/loop での定期実行」）。件数の判定は pending の3リストだけを出典とし、reviews[] / comments[] を自前のセレクタで数え直さない — 数え方が2箇所に分かれ、判断対象の有無で食い違うため
• PR 全体の読解: 「PR 全体の読解」に従って PR を読む。指摘の本文を読むのはこの後
• 指摘の列挙: 3種類を突き合わせ、重複と通常コメント上で合意済みの議題を除いた上で指摘を列挙（列挙・除外・返信先の規定は「ソース別の扱い」に従う）。出力は「対応対象の指摘」と「反応待ちスレッド」の2グループで、後者は修正要否の判断へ進めず報告する
• 修正要否の判断: 各指摘について修正すべきか判断（「判断基準」参照）

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

共通手順に続けて実行する。

• 修正の実装: 修正すべき指摘は実装で対応（コミット・プッシュまで。「品質確認」参照）
• 修正不要の返信起案: 修正不要な指摘には理由を説明する返信文を起案する（「修正不要と判断して返信する場合」参照）
• 返信の投稿とスレッドの解決: 修正の実装・修正不要の返信起案で用意した返信をまとめて投稿し、解決できるスレッドを解決する（手順は「スレッドへの返信と解決」。完了報告の文面は「修正完了報告フォーマット」に従う）
• レビュー再依頼: 対応が済んだレビュアーにレビューを再依頼（対象の判定・実行条件・失敗時の扱いは「レビュー再依頼」に従う）
• 判断の記録: ccx pr seen <ドキュメント> を実行する。何を投稿したかに関わらず — 1件も投稿しなかった実行でも、ユーザーへエスカレーションした指摘があっても — 必ず行う（持ち越されるのはユーザーの回答であって pending ではない）

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

共通手順に続けて実行する。--dry-run でも「PR 全体の読解」は pending が空でない実行で毎回行う（投稿しないだけで、判断そのものは通常モードと同じ根拠を要する）。

• 判断と案の報告: 指摘ごとに以下を報告（出所が本文・行コメント・通常コメントのいずれかを明示）：

- 修正すべきか否かの判断と理由 - 修正案（コード変更の具体的内容） - コメント返信案

あわせて「スレッドへの返信と解決」と同じ内容で threads_path を書き、ccx pr reply-threads --dry-run の出力を返信案と併せて提示する（どのスレッドに何が起きるかを、実行時と同じ検査を通した形で見せるため。この経路は何も投稿しない）。レビュー再依頼の予定も報告する（「レビュー再依頼」参照）

• 承認後の修正実行: ユーザーの承認後、修正を実行（コミット・プッシュまで）

- コメント返信・レビュー再依頼は行わない（案を再提示し、ユーザーが自分で投稿・実行） - ccx pr seen も実行しない（何も確定していないため）

PR 全体の読解

指摘を1件も読む前に、PR が何をしようとしていて何を変えたのかを組み立て直す。ここで判断するのは「見たことのない設計への異論」でありうるため（理由は pr-reading の冒頭）。

実行条件: 判断対象の有無の確認を通ったすべての実行。省略してよいのは判断対象が無いときだけで、それを決めるのはそのステップである（pr-reading の「ステートレス」が定める唯一の省略経路）。

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

会話を読む位置: 指摘の本文（reviews[] / review_threads[] / comments[]）を読むのは読解の後。先に読むと差分がその指摘の裏取りになり、指摘が触れていない決定を見落とす。唯一の例外は「行コメントスレッドの扱い」の theirs 報告。

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

/loop での定期実行

レビュー待ちの間、/loop 10m /review-response で本スキルを繰り返し実行できる（新しい指摘が付き次第対応する運用）。各イテレーションは通常モードと同じ手順でよい。判断対象の有無の確認がイテレーションを終わらせるかを決め、pending が空でないイテレーションでは毎回「PR 全体の読解」を行う。反応待ちスレッド（「行コメントスレッドの扱い」参照）の報告も、前イテレーションから顔ぶれが変わらなければ省略する — レビュアーの反応を待っている間ずっと同じ一覧が繰り返されるのを避けるため（単発実行での報告義務は変わらない）。

停止基準（いずれかに該当したら /loop を停止し、理由を報告する）:

• PR がマージまたはクローズされた
• 「ユーザーに最終判断を委ねる場合」に該当する指摘が出た（ユーザーの応答なしにイテレーションを重ねても進展しないため）
• 鮮度確認サブ手順の停止条件に該当した（ユーザー介入が必要な状態のため）

ソース別の扱い

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

行コメントスレッド（review_threads[]）は指摘の主経路。分類は ball に従う（誰が次に動くかは ccx pr context が起点・末尾・PR の所有者から確定させる）：

• ball: "mine": 対応対象。共通手順の修正要否の判断以降へ進める
• ball: "theirs": 「反応待ち」に分類し、共通手順の修正要否の判断へは進めない。人間レビュアーのスレッドは対応後も未解決のまま残す方針（下記）のため、is_resolved: false だけでは対応済みかを判別できないからである。レビュアーがその後に追記したスレッドは mine に戻るため、通常どおり対応対象になる
• ball: "none": skip（解決済み、または他人の PR 上の他人のスレッド）

補足:

• theirs に分類したスレッドは必ず報告する（silent に落とさない）: path:line と lastcomment の要旨を列挙する。通常モードは対応開始前、dry-run は指摘の報告と併せて、判断対象の有無の確認で終える実行はその終了報告と併せて（判断が後続しないこの経路に限り、reviewthreads[].last_comment を読んでよい — 「PR 全体の読解」より前に指摘の本文を読まないという順序の唯一の例外）。該当0件なら何も出さない。スレッドへの返信にはマーカーを付けないため、末尾の返信がこのスキルの完了報告なのか、議論を開いた返信（「ユーザーに最終判断を委ねる場合」）なのか、本人が手で書いたものなのかは機械判別できず、「対応済み」の推定が外れうる
• ユーザーが theirs / none のスレッドへの再対応を明示的に指示した場合、そのスレッドを報告に含めるところまでは行うが、返信・解決はできない（ccx pr reply-threads は mine 以外を受け付けない）。他人の PR 上で他人のスレッドを閉じる経路は意図的に無く、そちらは /deep-review の「コメントモードON時: 前回指摘スレッドへの返信・解決」（レビュアー側）が閉じる
• bot が起こしたスレッドで、既に自分が返信済みのもの（resolvablebyme: true かつ openedby が currentuser でない ＝ bot と自分しかいないスレッド、かつ lastcomment.author が currentuser）は、body を書かず resolve: true だけのエントリにする。bot は確認に戻ってこないので、返信済みのまま放置すると永久に open のまま積み上がる。自分が起こしたスレッド（openedby が currentuser）はこの規則の対象外で、他の指摘と同じように扱う

スレッドを閉じてよいか（resolvablebyme）

解決してよいかは reviewthreads[].resolvableby_me が持つ。真になるのは「自分が起こしたスレッド」か「自分の PR 上で bot と自分しかいないスレッド」で、特定のレビュアー名には依存しない（bot かどうかは GraphQL の型で決まる）。人間が1人でも参加したスレッドは偽になり、未解決のまま残る（レビュアーの再確認待ち）。

レビュアー側の受け取り手順は /deep-review の「コメントモードON時: 前回指摘スレッドへの返信・解決」が担う — 「作者は閉じない」だけを残すとスレッドが永久に open で積み上がるため、両側で1つのプロトコルとして読むこと。このプロトコルを変更する場合は同節と「レビュー再依頼」も合わせて見直す（同節は「人間レビュアーのスレッドは作者側では未解決のまま残る」ことを前提にレビュアー自身が閉じる手順として書かれており、「レビュー再依頼」はスレッドを閉じない代わりの再確認の契機として存在する）。

レビュー本文の扱い

レビュー本文（reviews[].body）は総評だけでなく、行コメントに存在しない独立した指摘が含まれることが多い（優先度付きリスト、「テストが不足」等のサマリー指摘）。以下の方針で扱う：

• 本文の指摘も個別対応対象: 行コメントと同じ粒度で修正・返信判断を行う
• 列挙するのは判断対象の有無の確認を通った実行だけ: pending.reviews[] が挙げないレビュー本文（APPROVED / DISMISSED、pending.since より古く以後未編集、等どの除外理由でも）も列挙の対象には入るが、それ自体が実行の理由にはならない。他の何かがゲートを通した実行でのみ読む（毎回すべてのレビュー本文を読み直す運用からの狭め）
• 重複チェック: 本文の指摘が行コメントと同じ内容を指していないか照合し、重複は1件として扱う
• 優先度付きリスト: 本文に「優先度1/2/3」「Must/Should/Nice」等の構造がある場合、各項目を独立した指摘として列挙
• 返信先: 本文由来の指摘は該当する行コメントスレッドが無いため、PR全体へのコメント（ccx pr comment）で対応完了を報告

通常コメントの扱い

通常コメント（comments[]、PR本体へのタイムラインコメント）はレビュー・行コメントとは GitHub 上で別管理のため、取得しないと議論経緯を取りこぼす。以下の方針で扱う：

• 主用途は議論経緯の参照: 「スレッドの指摘 → 通常コメントで回答 → レビュアーが合意」のような流れを把握し、既に解決済みの議題を重複して修正・返信しない
• 明示的な修正依頼は指摘として扱う: レビュアーが通常コメントに書いた修正依頼は、行コメントと同じ粒度で修正・返信判断の対象に含める。対応報告・CI通知・雑談は対象外
• スキル自身の投稿は非表示マーカーで除外: このスキルが ccx pr comment で投稿するコメント（対応完了報告・修正不要理由の返信）には、コマンドが本文の1行目として HTML コメント <!-- review-response --> を書く（GitHub のレンダリングでは非表示だが、API の body には残る）。再実行時、このマーカーで始まるコメント（ccx pr context が isskillcomment: true と判定済み）は修正判断の対象外とする（議論経緯の参照には使う）。先頭一致で判定するのは、引用返信で raw Markdown ごとマーカーがコピーされても > が付くため誤検知しないようにするため。login での除外はしない — PR作成者＝スキル実行者本人のことが多く、本人が手で書いた追加依頼まで落としてしまうため
• 返信先: スレッドが無いため resolve できない。本文由来の指摘と同様、ccx pr comment で対応完了を報告

判断基準

原則

• 技術的事実で判断する: 修正要否は好みではなく技術的事実・データに基づいて判断する
• レビュアーのラベルを尊重する: 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・リネーム等、修正コストがほぼゼロで内容に同意できるもの（再レビューのラウンドトリップ削減を優先）

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

確定前に Skill ツールで finding-triage を起動し、その規律で検証してから確定し、返信には検証で確認した参照先（ファイル・grep 可能な識別子）を含める（こちらは判断結果が人間レビュアーへの返信として公開記録に残るため、内部の見送りより検証の要求水準は高い）。非必須（「推奨」等）と記載されたルールを根拠にする見送りは、同スキルの「非必須ルールの一様準拠判定」で拘束力を判定してから確定する。

• 既存パターン踏襲: プロジェクト標準・既存規約に準拠している。踏襲元はその実行の中で checkout を grep して実在を確かめる。grep が何も見つけられなければこの根拠は使えない — 別の根拠で判断し直すか、「ユーザーに最終判断を委ねる場合」としてエスカレーションする（「よくあるパターンだから」で押し返すと、無いものを根拠に人間レビュアーの指摘を退けることになる）。grep する先が PR の head を映したツリーであることは鮮度確認が保証する（--worktree の有無に関わらず。停止条件の正は「共通サブ手順: PR head との鮮度確認」）
• 好みの問題: 技術的根拠のないスタイル選好で、修正コストに見合わないもの
• スコープ外の正当な指摘: 本PRでは対応しない場合、握りつぶさず Issue 化して返信にリンクする（「後で直す」だけの返信は実行されずに終わるため）

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

• 設計思想に関わる指摘: 意図的な設計判断への異論は、根拠を添えた返信で議論を開くまでを行い、スレッドは解決しない。修正するか押し返すかはユーザーに確認する（合意形成を飛ばして一方的に「修正不要」と確定させない）

- 議論を開く返信は、決定がどこに記録されているかを名指す。引用してよいのは linkedissues[].body / linkedissues[].comments[].body / parent.body / parent.comments[].body / pr.body / commits[].message / コードコメントのいずれかで、どこに書かれているかを返信に書く。記憶や推測を「意図的な設計です」と述べない - どれにも記録が無ければ、返信を投稿せずエスカレーションが先。何をどこで探したかを添えてユーザーに提示し、ユーザーが意図を確認したら先に書き下ろしてから返信する。書き下ろし先は 2 つ: - スコープ・方針に関する決定 → PR 本文。節だけを workdir 直下に Write し、ccx pr body-append <ドキュメント> --body-file <workdir 直下のファイル名> で追記する（既存の本文はコマンドが書き込み時点の GitHub から読んで保つ）。他人の PR では本文を編集せず、下のコードコメントかエスカレーションのまま留めるかにする（コマンド側も isownpr: false を拒否する） - コードの将来の読者が必要とする理由 → コードコメント（why を書く。グローバルのコメント規約）。コミットして push する - --dry-run では書き下ろし案を返信案と併記するだけで、PR 本文もコードも書き換えない

• 人間レビュアーの blocking 指摘に反対する場合: 同上。反論の根拠を整理して提示し、ユーザーの判断を仰ぐ

レビュー再依頼

対応が済んだ人間レビュアーに GitHub の review request を付け直し、「もう一度見られる状態になった」ことを通知する（通常モードの「レビュー再依頼」ステップ）。人間レビュアーのスレッドは対応後も未解決のまま残る（「スレッドを閉じてよいか（resolvablebyme）」）ため、これが無いとレビュアー側に再確認の契機が届かず、作者が GitHub の re-request ボタンを手で押すまで止まる。再依頼すると PR がレビュアーの review-requested 一覧に戻り、GitHub の通知も飛ぶ。

実行条件: isownpr: true のときのみ実行する（再依頼は作者側の signal であり、他人の PR を対象にスキルを動かしたときには行わない）。

対象レビュアー: 以下をすべて満たす login のみ。条件1・2は今回の実行でスキル自身が何をしたか、条件3〜5はその login に対応する reviewers[] の要素から判定する（突き合わせのキーは reviewers[].author。author が null の要素はどの login にも一致しないため対象にならない）。条件1・2の指摘は出所を問わず数える（レビュアーの login は、スレッド由来なら opened_by、レビュー本文由来なら reviews[].author、通常コメント由来なら comments[].author）:

1. 今回の実行で、そのレビュアーの指摘の1件以上に (a) 修正コミット + 完了報告、または (b) 修正不要の理由付き返信 のいずれかで応答した
2. 今回の実行で、そのレビュアーの指摘に議論を開く返信（「ユーザーに最終判断を委ねる場合」）をしていない。修正済みの指摘と議論中の指摘が混在するレビュアーはレビュアー単位で保留し、全指摘が決着した後続のイテレーションで対象に戻す
3. 人間である（reviewers[].author_type != "Bot"。bot に再依頼しても再確認は返ってこない）
4. reviewers[] に要素がある（タイムラインコメントだけを書いた人は要素を持たないので、レビュアーに追加しない）
5. 有効な approve を持っていない（reviewers[].state != "APPROVED"）

reviewstruncated: true（レビューが取得窓からあふれ、古い側が落ちている）のときは条件5を確定できないため、再依頼を行わずその旨を最終報告に載せる。窓外に落ちて reviewers[].state に現れない APPROVED を見落とすと、条件5がまさに避けようとしている「approve 済みレビュアーへの再依頼」が起きるため、判定不能側は保守的に倒す（MAXREVIEWS を引き上げて再実行すれば解消する）。

実行タイミングと失敗時: 返信の投稿とスレッドの解決の後・ユーザーへの最終報告の前に、対象 login をまとめて1回だけ呼ぶ（コマンドは「レビューの再依頼（REST）」）。API が失敗しても（レビュアーの離脱・権限不足等）リトライせず、失敗した旨を最終報告に載せて正常終了する（/loop の停止条件にはしない）。対象が0件なら呼び出さず、最終報告に対象なしと1行書く。ここでの「最終報告」はユーザーへの出力を指し、GitHub へ投稿する「修正完了報告フォーマット」とは別物。

--dry-run では実行せず、再依頼の予定（対象 login と実行するコマンド）を報告に含める（返信案と同じく、実行するかどうかはユーザーに委ねる）。

API 実装

指摘・議論経緯の取得

ccx pr context <scratchpadディレクトリ> [<pr-number>]

レビュー本文（reviews[]）・レビュースレッド（reviewthreads[]）・通常コメント（comments[]）の3種を一括取得し、正規化した JSON を scratchpad 配下の一意な名前のファイルに書く。stdout に返る path / workdir / threads_path はいずれも ccx pr context が所有する — 呼び出し側で保存先を組み立てず、返された値だけを使う。以後は返された path のファイルを jq で必要部分を段階的に参照する（CI bot が多い PR では数百 KB に達し、直接表示の部分読みは指摘・議論経緯の読み落としを誘発するため）。3つは GitHub 上で別管理のため、一部だけ取得すると本文の指摘（優先度付きリスト等）や通常コメント上の議論経緯・追加依頼を見落とす — 一括取得・全量取得（ページネーション）・マーカーの先頭一致判定は ccx pr context が保証する。<pr-number> 省略時はカレント branch の PR を推論し、失敗時は非ゼロ exit + stderr メッセージで停止する。

全量取得にはコストガードの上限がある。打ち切りが発生したら該当の環境変数で上限を引き上げて再実行する:

本スキルで使用するフィールド:

• pending: 判断対象の有無の確認が読む唯一の入力。3つのリストの空・非空だけを見る（「共通手順」）
• fetched_at: 判断の記録が測る基準。ccx pr seen に渡した文書のこの値が、次回の pending の起点になる
• linkedissues[] / commits[] / diff / warnings[]: 「PR 全体の読解」が読む材料。linkedissues[] と commits[] は押し返しの引用元にもなる（「ユーザーに最終判断を委ねる場合」）
• reviews[]: レビュー本文。body を必ず読み、本文内の指摘（総評・優先度付きリスト・サマリー）を行コメントと同じ粒度で列挙する
• reviewthreads[]: 行コメントスレッド。分類は ball、解決可否は resolvablebyme（「行コメントスレッドの扱い」参照）。path と line / originalline は返信先の指定に使う（「スレッドへの返信と解決」）。lastcomment は反応待ちの報告に載せる末尾コメント（comments[] の最終要素とは限らない — 打ち切り時は含まれない）。指摘とレビュアー login の対応付け（「レビュー再依頼」の条件1・2）には openedby を使う
• comments[]: 通常コメント。議論経緯の把握に用い、レビュアーによる明示的な修正依頼のみ指摘として列挙する（「通常コメントの扱い」参照）。isskillcomment: true は本スキルの過去の自動投稿（修正判断の対象外、議論経緯の参照には使う）
• pr.headoid / pr.headref / pr.baseref / isownpr: 鮮度確認の入力。isown_pr は「自分の PR のときだけ」を課す節（「レビュー再依頼」「ユーザーに最終判断を委ねる場合」）の実行条件も兼ねる
• pr / repo: レビュー再依頼のエンドポイント組み立てに使用（完了報告の投稿先と PR 本文への書き下ろし先はコマンドがドキュメントから読むので、こちらで組み立てない）

スレッドへの返信と解決

先に修正をコミットして push する（返信コマンドはローカル HEAD が GitHub の live head であることを求めるため、push が済んでいないと拒否される。ドキュメントは取り直さない — コマンドはドキュメントの pr.headoid がローカル HEAD の祖先であることを確認するので、push で先へ進んだ分は受理される）。push でコードが動き line が null になったスレッドも、同じ番号を originalline として保ち、コマンドはどちらにも一致するので、push 前のドキュメントから書いたセレクタはそのまま解決する。threads_path に対象スレッドを書き、投稿する:

ccx pr reply-threads <ドキュメント> <threads_path>

書式は ccx pr reply-threads --help にある。本スキルが決めるのは中身:

• スレッドは path と line で指す。id は書かなくてよい — 必要なときはコマンドが候補を挙げて要求してくる
• resolve は当該スレッドの resolvablebyme と同値にする
• body は「判断基準 > 原則」の言語（対象 PR の記述言語）で書く。1行を超える返信は素の Markdown を workdir 直下に Write して bodyfile で指す — JSON 文字列への手書きエスケープは1文字の欠落で JSON 全体が無効になるため
• body を省いて resolve だけにするのは2つの場合 — 前回の返信から言うことが変わっていないとき（bot スレッドの再実行）と、resolve だけが失敗して再試行するとき

--dry-run を足すと、同じ検査をすべて通した上で何も投稿せず計画だけを出す（dry-run モードの判断と案の報告で使う）。

実行後:

• 返信・解決したスレッド数をユーザーに報告する
• resolve_failed[] が空でない場合: 返信済みなので同じ本文で再実行しない。body を省いた resolve のみのエントリで再試行する。warning はユーザーへの報告に併記する
• 拒否された場合（セレクタの曖昧さ・古いコンテキスト等）は stderr の指示に従う。指摘を落として通すのではなく、指定か前提の方を直す

レビューの再依頼（REST）

対象・実行条件・失敗時の扱いは「レビュー再依頼」参照：

gh api repos/<owner>/<repo>/pulls/<PR番号>/requested_reviewers \
  -f 'reviewers[]=LOGIN1' -f 'reviewers[]=LOGIN2'

• <owner>/<repo> は repo、<PR番号> は pr.number を使う
• 本スキルの他の呼び出しは GraphQL だが、再依頼だけ REST を使う。このエンドポイントは契約として additive（既存のレビュアー集合に追加する）で、リポジトリがパスに明示されるため

重要な実装ポイント

修正完了報告フォーマット

構造の規定であり、文面は対象 PR の記述言語で書く（「判断基準 > 原則」参照。以下の例は日本語 PR の場合）:

<修正内容>を対応しました。
https://github.com/<owner>/<repo>/pull/<PR番号>/commits/<コミットハッシュ>

PR 本体へのコメントとして投稿する場合は、上記の本文を work_dir 直下に Write して投稿する:

ccx pr comment <ドキュメント> --mark review-response --body-file <work_dir 直下のファイル名>

識別マーカーはコマンドが本文の先頭に書くので、こちらでは書かない（「通常コメントの扱い」参照）。このコマンドも、ローカル HEAD が GitHub の live head であることと、ドキュメントの pr.head_oid がその祖先であることを確認するため、投稿前に push を済ませておく点は返信と同じ（「スレッドへの返信と解決」）。スレッドへの返信にはマーカーが付かない。

品質確認

修正後はプロジェクトのテスト・Lint コマンドを実行する（プロジェクト CLAUDE.md 依拠。明示がなければ推測実行せずスキップする — /deep-review「自動対応モードON時: レビュー指摘の反映」と同じ規則）。数分以上かかる見込みなら runinbackground: true で実行する。

注意事項

• レビュー本文・通常コメントを見落とさない: 行コメント（review_threads[]）だけを対象にすると、本文に書かれた優先度付きリスト・総評や、通常コメント上の議論経緯・追加依頼を取りこぼす。取得の網羅は ccx pr context が保証するが、指摘の列挙まで進んだ実行では必ず reviews[] と comments[] を読み、3種類を突き合わせること（判断対象の有無の確認で終わる実行はどれも読まない）
• 鮮度ガード: 開始時に「共通サブ手順: PR head との鮮度確認」を実行する（同期・停止条件の正はサブ手順側を参照）。--dry-run でも同期は実行される。返信直前にも ccx pr reply-threads 自身が確認する（「スレッドへの返信と解決」）
• --worktree 指定時の挙動: worktree-resolution の注意事項を参照