Fix Review Point

GitHub PR $0 の未解決レビューコメントに対応し、修正のコミット・push・Resolve・description更新までを完遂するスキル。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。

自律実行モード: ユーザーへの確認を求めず最後まで自律的に完遂する。判断が必要な場面では本ドキュメントの既定挙動に従って自動で意思決定し、処理を継続する。確認のために停止することは禁止（フェーズ0の安全ガード条件に該当する場合のみ中断可）。

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の cc-fix-onetime ラベルをトリガーに自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-fix-onetime の除去やコールバックコメント投稿を進める。処理未完のままターンを終えると、修正コミット未 push のまま Resolve だけ済まされたり、レビュー未対応のまま fix ラベルが外れて放置される状態壊れが起きる。

スコープと出力の規律

• 指摘された範囲だけを直す: レビュアーの指摘を解消する変更に限定し、周辺のリファクタ・命名整理・気づいた別の改善を足さない（レビュアーの意図から外れた差分はレビューをやり直させる）。気づいた点は修正せず最終報告に1行で挙げる
• Issueの要件を正とする: レビュー指摘（特に自動レビュー）はPRの差分しか見ておらず、Issueで確定した要件や確認事項への回答を知らない。create-review-fix-plan が「要件優先で対応しない指摘」に載せた指摘は実装せず、フェーズ6で該当スレッドへ要件・回答の該当箇所を引いて1-2行で返信する。プランの修正方針が要件と矛盾すると実装中に気づいた場合も同じ扱いにし、要件に無い挙動を足して指摘を解消しない。逆に、実装が要件を満たしていない点を突く指摘は、文面が軽くても対応する
• 指摘が誤りだと考えた場合: 1-2行で根拠を添えてPRコメントに残し、そのうえで指摘の意図に沿って対応する（黙って無視・縮小・別物への置き換えをしない）。例外はIssueの要件・回答と矛盾する指摘で、これは上記のとおり対応せず返信だけを残す
• 成果物の文章量は内容に見合わせる: PR description の更新・修正履歴・最終報告は必要な実質だけを書く。言い換え・埋め草セクションを足さない
• 最終報告は結論から: 1文目で「何件の指摘に対応したか / どこで止まったか」を述べ、詳細を後に置く

実装の委任（判断ロジック）

メインエージェント（本スキルを実行しているセッション本体）の役割は「指摘の分解・委譲・検証・統合」であり、規模の大きい指摘・並列化できる指摘の修正主体はサブエージェントである。ただし、レビュー指摘には1ファイル数行で済むものが相当数あり、数回のツール呼び出しで終わる修正まで委譲すると、ブリーフィング作成とサブエージェント側の再探索でコストと時間が倍になる。指摘ごとに下記の判定を行って委譲/直接編集を決める（プラン全体で一括判定しない）。

判定は着手前に行い、判定結果（どちらを選んだか・根拠となった条件）を記録して最終報告の自己監査に載せる。

ステップ1: 無条件で委譲するもの（1つでも該当したら即委譲。以降の判定はしない）

• UIデザインのマークアップ（見た目・スタイル・デザインとの一致に関する指摘） → frontend-implementer（マークアップ以外のフロントエンド指摘＝状態管理・データ取得・API連携・ロジックは同エージェントの担当外。general-purpose-assistant へ委譲する）
• .pen ファイルの編集・更新 → pencil-design-updater
• 2ファイル以上に触れる見込みがある
• 新規ファイルの作成を含む
• 着手前に探索が必要（編集対象のファイルパスと関数/シンボル名を、いま即答できない）
• 変更行数の見積もりが概ね20行を超える
• 依存追加・設定変更・スキーマ/マイグレーション変更を含む
• 指摘が設計・責務分割・安全性の再考を求めている（字面どおりの置換で済まないもの。要約して渡すと劣化するため、コメント全文を渡して委譲する）
• 独立して並列実行できる指摘が他に2件以上ある（メインが自分で直すと並列性を捨てることになる）

ステップ2: 直接編集してよい条件（すべて満たす場合のみ）

1. 対象が単一ファイルで、変更が概ね10行以内
2. 対象箇所がすでにメインの文脈にある（create-review-fix-plan の返却が file:line を直接指している、自分で Read 済み、CodeGraph の出力に含まれる、または失敗ログが該当行を指している）
3. 追加の調査・仕様確認が不要で、修正内容が一意に定まる（typo、命名の統一、不要コメントの削除、import の追加、型注釈の修正、リテラルの定数化など）
4. 指摘が「何をどう直すか」まで具体的に書かれており、解釈の余地がない
5. 他のサブエージェントの完了待ちを遅らせない

フェーズ4の収束ループ（テスト/Lint/ビルド失敗の修正）にも同じ条件を適用する。

委譲の量の制御

• 1指摘に1エージェント。1体で完結する指摘に複数体を重ねて起動しない
• 検証目的でサブエージェントを起動しない。成果物の確認は git diff / テスト・Lintの実行でメインが自分で行う
• 並列起動は「対象ファイルが重ならない独立した指摘」に限る（判断基準は「並列 vs 逐次の判断」節）

ステップ3: 判定が割れたら委譲する

どちらとも言い切れない場合は委譲側に倒す。「たぶん小さい」「たぶん1ファイルで済む」は該当しない根拠にならない。軽量な指摘の受け皿として lightweight-assistant を使う。

滑り坂ガード

小修正の直接編集を積み上げてPR全体を自分で直してしまう事故を防ぐため、以下を守る。

• 直接編集は指摘1件ごとに独立して判定する。「さっき直したついでに」で連鎖させない
• 直接編集したらその指摘の範囲で完結させ、関連しそうな箇所へ手を広げない（範囲外の変更はレビュアーの意図から外れる）
• 1セッション内で直接編集が3件に達したら、以降の指摘はすべて委譲へ切り替える（それだけ小粒な指摘が続く場合でも、委譲すれば並列化できるため）

ツールの使い分け（直接編集する場合も適用）

• ファイル編集は必ず Edit / Write を使う。sed -i / ファイルへの > >> リダイレクト / patch / cp / mv / rm などシェル経由の書き換えは、差分が検証できずレビューにも残らないため使わない
• gh ... --body-file - へのヒアドキュメントのように、リポジトリのファイルを変更しない標準入力の利用は可
• git stash / gh pr checkout / git commit など、スキル本文が指示する git 操作は可
• 依存追加（npm install <pkg> など）はステップ1で委譲対象のため、メインからは実行しない

E2Eテストの取り扱い（共通ルール）

対象プロジェクトにE2Eテストが存在し、かつ修正がユーザー操作フローに影響する場合、E2Eテストの実装・更新も本スキルの完遂条件に含める。フェーズ1の完了後（サブエージェント起動前）に以下のいずれかに該当するかを一度だけ確認し、判定結果（存在有無・テストの所在・実行コマンド）を後続フェーズで使い回す：

• E2Eフレームワークの設定ファイルが存在する（playwright.config.* / cypress.config.* / wdio.conf.* / nightwatch.conf.* など）
• e2e/ / tests/e2e/ / cypress/ などのE2Eテスト用ディレクトリが存在する
• package.json の scripts に test:e2e / e2e 等のE2Eテスト実行コマンドがある

存在すると判定した場合、ユーザー操作フロー（画面遷移・フォーム入力・API連携・CLIの入出力など、既存E2Eテストが検証している境界）に影響する修正タスクの完了条件に「該当フローのE2Eテストの追加・更新」を含め、フェーズ3のブリーフィングにE2Eテストの所在・実行コマンド・既存テストの記述パターンの参照先を含め、フェーズ4の収束ループでE2Eテストも実行する。

存在しない場合は、レビュー指摘が明示的に要求しない限りE2Eテスト基盤を新規導入しない（スコープ外の変更となるため）。

フェーズ0: 事前チェックとPRチェックアウト

並列で以下を確認する。1つでも失敗したら、その場で原因を解消してから先に進むこと。

• GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。 gh pr view $0 --json number,state,headRefName,isDraft,labels でPRが存在し OPEN であることを確認する。CLOSED/MERGEDなら処理を中断。取得したラベル一覧は「修正点がない場合」の Epic PR 判定で使う（再取得しない）
• gh pr checkout $0 >/dev/null 2>&1 でPRブランチをチェックアウト（ローカル作業ツリーへの checkout はリモート API では代替できないため gh のまま残す）。クラウド実行時は実行しない — セッションはワーカーが --on-branch で指定した PR の head ブランチ上で開始しており、gh pr checkout はクラウドでは GraphQL ゲートにより 403 で失敗する。git rev-parse --abbrev-ref HEAD が既に対象PRの head ブランチなら省略してよい
• チェックアウトを省略した場合のfail-safe: git rev-parse --abbrev-ref HEAD の値が、直前で取得済みの headRefName と一致することを確認する。一致しない場合は --on-branch が反映されていない想定外の状態のため、以降のフェーズ（修正コミット・force-push・Resolve）に進まずその場で中断する
• pwd で .claude/worktrees/ 配下にいることを確認する。worktree外なら安全のため処理を中断する（デフォルトブランチで作業してはならない）。ただし起動プロンプトに「このセッションはクラウド実行のため worktree を持たず、cwd はリポジトリルートである」旨の指示がある場合はこの確認をスキップする — クラウド実行ではワーカーが worktree を作らないため常に worktree 外になる。ガードの目的である「デフォルトブランチで作業しない」は次の確認で担保する。指示が無く worktree 外でもある場合は従来どおり中断する（クラウドかもしれないという推測で続行しない）
• bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch でデフォルトブランチ名を取得し、git rev-parse --abbrev-ref HEAD の現在ブランチと一致する場合は中断する。デフォルトブランチ名の取得失敗も中断する（fail-safe）
• git status --short で未コミット変更があれば git stash push -u -m "fix-review-point auto-stash $0" で自動退避してから先に進む（ユーザーへの確認は行わない）

完了条件: worktree内（クラウド実行では上記のとおり免除）、PRブランチ（デフォルトブランチ以外）にチェックアウト済み、PR OPEN が確認できていること。

フェーズ1: 修正プランの取得

create-review-fix-plan skill を $0 で呼び出し、以下を取得する：

• 関連Issueの要件（## Issueの要件（正））と、要件優先で対応しない指摘の一覧（コメントURL・根拠となる要件・回答の箇所）
• 未解決レビューコメントの一覧（コメント本文・対象ファイル・行番号）
• CIステータス（失敗ジョブと原因の要約）
• 修正タスクの一覧（目的・対象範囲・完了条件付き）
• タスク間の依存関係

修正点がない場合（要件優先で対応しない指摘だけが残った場合も含む。その場合はフェーズ6の返信を先に済ませる）: GitHub MCP が使える場合は pull_request_read（method: get_status / get_check_runs）を使う。以下は MCP 利用不可時のフォールバック。 gh pr checks $0 でCIの全チェックが Pass していることを確認する。チェックが失敗中の場合はマージせず、CI失敗状況をレビュアーに報告して終了する。Pass している場合は、ステップ0で取得したラベル一覧で Epic PR（cc-epic-issue ラベル付き）かどうかを確認して分岐する:

• Epic PR の場合: マージするとデフォルトブランチへの集約反映（＝リリース）になるため、マージしない。triage-pr の Epic PR 判定と同じリリースゲートとして cc-release-ready ラベルのみを付与して終了する（関連Issueの連動Closeにも進まない）。

  gh pr edit $0 --add-label "cc-release-ready"
  

• 通常のPRの場合: PRをマージする。GitHub MCP の pull_request_write（method: merge）を優先し、利用不可なら gh pr merge $0 --merge --delete-branch へフォールバックする（フォールバックした場合はその旨を最終報告に1行残す）。マージ後、下記「マージ後の関連Issue連動Close」を実行して終了する。

マージ後の関連Issue連動Close

GitHubの Closes #<issue番号> 記法による自動クローズはデフォルトブランチへのマージ時にのみ発動する。cc-epic-<N> のような非デフォルトブランチへ向いたPRをマージしてもIssueは閉じず、Epic のサブIssueが未完のまま残って create-epic-pr の起動条件（全サブIssueのクローズ）が満たされなくなる。そのため、マージ前にベースブランチを控えておき、デフォルトブランチと一致しない場合のみ明示的にクローズする。

GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

BASE_BRANCH=$(gh pr view $0 --json baseRefName -q .baseRefName)
DEFAULT_BRANCH=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch)

マージ成功後、BASE_BRANCH が DEFAULT_BRANCH と一致する場合はGitHubが自動でクローズするためスキップする。一致しない場合はPR本文から関連Issue番号を抽出し、抽出できたすべての番号を completed（実装がEpicブランチへ取り込まれた完了クローズ。マージせずクローズする場合の not_planned とは異なる）でクローズする。クローズは gh issue close（GraphQL 経由でクラウドセッションのゲートに掛かる）ではなく gh-compat.sh close-issue を使う。

GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

gh pr view $0 --json body --jq '.body' | grep -ioE '(close[sd]?|fix(e[sd])?|resolve[sd]?)[[:space:]]+#[0-9]+' | grep -oE '[0-9]+'
bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh close-issue <issue番号> completed

関連Issueが抽出できない場合は、その旨を最終報告に含めること。

返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。

完了条件: 修正タスクが「並列実行可能なグループ」と「逐次グループ」に分類できていること。

フェーズ2: タスク実行戦略の決定

サブエージェント選定

修正タスク（指摘）ごとに、まず「実装の委任（判断ロジック）」のステップ1〜3で委譲するか直接編集するかを判定する。委譲すると決めたタスクは、以下の判断軸でサブエージェントを選定し、実行を委任する：

• frontend-implementer: UIデザインのマークアップ専任。デザインとの視覚的な差異・スタイル・マークアップ構造・a11yマークアップに関する指摘にのみ使う。.pen を参照元としてUIに変換する指摘は必ずこのエージェントを使う。逆に、状態管理・データ取得・API連携・バリデーション/ビジネスロジックへの指摘はフロントエンドのファイルが対象でもこのエージェントに渡さない
• pencil-design-updater: Pencilファイル（.pen）自体の編集・更新（要素追加、レイアウト変更、スタイル修正、テキスト差し替えなど）は必ずこのエージェントに任せる
• lightweight-assistant: 内容が具体的で探索不要・単一ファイル編集レベルの軽量タスク（型定義追加、定数追加、設定ファイル更新など）
• general-purpose-assistant: 上記以外（複数ファイルにまたがる実装、調査を伴うタスク、テスト/Lint修正、フロントエンドのマークアップ以外の指摘）

lightweight-assistant / general-purpose-assistant を起動するときは、Agent ツールの effort を毎回指定する（両エージェントとも定義に effort を持たない）。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md の表で、本スキルでは次のとおり選ぶ: lightweight-assistant は変更を伴うので medium、general-purpose-assistant は失敗ログ付きのテスト/Lint修正や指示が一意な単一の指摘なら medium、複数ファイルにまたがる・原因調査を伴う・設計の再考を求めるものなら high。判定が割れたら上の段を選ぶ

デザインマークアップの指摘の分離

1つの指摘にマークアップの修正とロジックの修正が混ざっている場合（例: 「この一覧の余白がデザインとずれているうえ、取得件数の上限も違う」）は、create-review-fix-plan の返却の分離に従って別タスクとして扱う。返却が分離されていない場合は本フェーズで分割し、マークアップ部分だけを frontend-implementer に、残りを general-purpose-assistant に委譲する。同一ファイルを触るため、この2タスクは逐次で実行し、両方が同じ指摘に紐づくことをブリーフィングに明記する（Resolve時に取りこぼさないため）。

マークアップ修正が数行で完結し、分割コストが上回る場合は分割せず1タスクにまとめてよい。その場合の担当は general-purpose-assistant にする。

並列 vs 逐次の判断

以下のいずれかに該当するタスク同士は 逐次 で実行する：

• 同じファイルを編集する可能性がある
• 一方の出力（型・関数・スキーマ）に他方が依存する
• マイグレーションやスキーマ変更を含む

それ以外は 並列 で実行する。並列実行する場合は、1メッセージ内で複数のAgent tool callを発行すること（順次呼び出しでは並列にならない）。

フェーズ3: サブエージェントへのブリーフィング

サブエージェントは現在の会話履歴を持たないため、起動時は以下を すべて プロンプトに含めること。自己完結したブリーフィングが品質を決める。

【背景】PR #$0 のレビュー指摘対応: <PRタイトル要約>

【あなたが担当する指摘】
<レビューコメント本文を引用>
- 対象ファイル: <path:line>
- 指摘者の意図: <create-review-fix-plan が抽出した要約>

【Issueの要件（正）】
<関連Issue番号と、担当する指摘に関わる要件・確認事項の回答の引用。無ければ「関連Issueなし」>
指摘の解消がこれと矛盾する場合は実装せず、矛盾する箇所を報告して終える。要件に無い挙動を足して指摘を解消しない。

【対象範囲（編集可ファイル/ディレクトリ）】
<具体パスを列挙。範囲外を触らないこと>

【触れてはいけないファイル】
<並列実行中の他タスクが触る予定のファイル>

【完了条件】
- レビュアーの指摘内容が解消されていること
- 該当箇所のユニットテストが追加・更新され、すべてpassすること
- プロジェクトにE2Eテストが存在し、担当する修正がユーザー操作フローに影響する場合: 該当フローのE2Eテストが追加・更新され、passすること（E2Eテストの所在・実行コマンド: <パスとコマンド。存在しない場合はこの行ごと削除>）
- `npm run lint`（またはプロジェクト指定のlint）に該当ファイルでエラーがないこと
- 既存の挙動を意図せず変更していないこと

【スコープ】
上記の指摘を解消する変更だけを行う。範囲外のリファクタ・命名整理・周辺の改善を足さない。気づいた別の問題は修正せず、報告に1行で挙げるだけにする。

【参考情報】
- レビューコメントへの直リンク
- 既存の類似実装の参照先（あれば）

【作業ディレクトリ】
<worktreeの絶対パス>。すべてのコマンドはここを基準に実行すること。

【報告】
指摘をどう解消したか（対象ファイルと要点）・完了条件の充足状況・残課題を簡潔に。埋め草の要約セクションは不要。

サブエージェントが完了報告を返したら、本体側で git diff --stat を実行して変更範囲が宣言通りか検証する。範囲外の変更や指摘と無関係な変更があれば、当該サブエージェントを再起動して修正させる。

フェーズ4: テストとLintの収束ループ

すべてのサブエージェントが完了したら、本体で以下を順に実行：

1. プロジェクトのユニットテストコマンドを実行（package.json の scripts.test を確認）
2. E2Eテストが存在する場合（「E2Eテストの取り扱い（共通ルール）」の判定結果に従う）、E2Eテストコマンドも実行する（scripts の test:e2e / e2e 等）
3. プロジェクトのLintコマンドを実行（scripts.lint）
4. 失敗した場合、「実装の委任（判断ロジック）」のステップ1・2で委譲/直接編集を判定する
   • 委譲する場合: general-purpose-assistant（単一ファイルの自明な修正なら lightweight-assistant）に 失敗ログ全文と該当ファイルパス を渡して修正させる
   • 直接編集する場合: ステップ2の条件をすべて満たすことを確認したうえで Edit で修正する。滑り坂ガード（1件ごとに独立判定・範囲を広げない・3件で以降は委譲へ切替）を必ず守る
5. 修正後、再度テスト（ユニット・E2E）とLintを実行

ユニットテスト/E2Eテスト/Lintコマンドがプロジェクトに存在しない場合はスキップしてよい（その旨を最終報告に含めること）。

フェーズ5: コミットとpush

1. commit-push skill を呼び出し、変更をコミット・push。git status --short が空（要件優先で見送った指摘だけでコード変更が無い）の場合は、コミット・pushを行わずにフェーズ5を完了扱いとしてフェーズ6へ進む（見送りの返信と Resolve に修正 push は不要なため）
2. Push後のCI結果は 待たずに 次のフェーズへ進む（CIの収束は別ループで扱う）

フェーズ6: Resolve と description 更新

フェーズ5の push が完了してから（差分が無くフェーズ5を完了扱いにした場合はその時点から）このフェーズに入ること。 本フェーズの Resolve は未解決スレッドを全件対象にするため、修正が push されていない段階で実行すると、対応していない指摘まで Resolve されてレビュー未対応のままマージされうる。フェーズ2〜5のいずれかで中断した場合は、Resolve を行わずに中断理由を報告して終了する。

1. 「要件優先で対応しない指摘」（フェーズ1の一覧と、実装中に矛盾と判定したもの）があれば、Resolve より先に各スレッドへ返信する。本文は「Issue #<N> の要件（または確認事項への回答）『<該当箇所の引用>』に従い、この指摘は反映しません」の1-2行。インラインスレッドは GitHub MCP の add_reply_to_pull_request_comment を優先し、利用不可なら gh api repos/{owner}/{repo}/pulls/$0/comments/<comment_id>/replies -f body=... へフォールバックする。会話コメント由来なら gh pr comment $0（MCP は add_issue_comment）で返す。返信せずに Resolve すると、要件を理由に見送った事実がGitHub上に残らず、後から「指摘を無視した」ようにしか見えない。MCP・フォールバックの両方で返信に失敗したインラインスレッドは thread ID（PRRT_...）を記録し、次の Resolve の対象から外す。失敗件数と thread ID は最終報告に含める
2. resolve-pr-comments skill を PR 番号 $0（返信に失敗したスレッドがあれば、続けてその thread ID を除外対象として列挙）を渡して呼び出し、対応済みのレビューコメントをすべてResolveする。同スキルは GitHub MCP（pull_request_review_write の resolve_thread）を優先し、利用不可なら gh の GraphQL へフォールバックする。Resolve に失敗したスレッドが報告された場合は、件数と thread ID を本スキルの最終報告にも引き継ぐ
3. 今回の修正内容を反映してPRのdescriptionを最新化する
   • gh pr edit $0 --body "<更新後の本文>" を使用
   • 変更点の要約・テスト観点の追記・既存セクションの整合性を保つ
   • ## 修正履歴 セクションを必ず設ける。既存のdescriptionに無ければ末尾に新規追加し、既にあれば追記する形で残す。各エントリは以下のフォーマットに従う:

     ## 修正履歴
     
     ### YYYY-MM-DD: レビュー指摘対応（<件数>件）
     - <対応した指摘の要約1>（対応コミット: <commit hash 短縮>）
     - <対応した指摘の要約2>（対応コミット: <commit hash 短縮>）
     - 要件優先で見送り: <指摘の要約>（根拠: Issue #<N> の<要件・回答の箇所>）
     

     • 日付は date +%Y-%m-%d で取得した実行日を使用する
     • 過去のエントリは削除・改変せず、新しいエントリを上に追記する（新しいものが上）
     • 1件ごとに「何を指摘され、どう直したか」が読み手に伝わる粒度で書く
4. 最終報告として、対応した指摘の件数と要件優先で見送った指摘の件数、PRのURLを出力する。あわせて以下のフォーマットで自己監査結果を必ず含める（「実装の委任（判断ロジック）」の適用状況をセッション自身で振り返るためのもので、判定の正当化より事実の記録を優先する）

   ## 実装委任の自己監査
   - 起動したサブエージェント: <エージェント名 × 件数。例: general-purpose-assistant × 2, lightweight-assistant × 1>
   - メインエージェントによる直接編集: なし / あり（<件数>件）
     - <対象ファイル>: <変更行数> / <判定根拠。ステップ2の1〜5をどう満たしたか>
   

   直接編集が「あり」の場合は、ステップ2のどの条件で許容されたのかを件ごとに1行で書く。ステップ1に該当していたのに直接編集した場合は、その事実をそのまま記録する（隠さない）

PRクローズ時の連動処理（共通ルール）

実行中に何らかの理由でPRをクローズする判断に至った場合（例: 指摘が別アプローチでの再実装を求めている、要件の陳腐化、別PRで対応済み、コンフリクト解消不能など）は、PRと 関連Issueを必ず連動してクローズする。PRだけ閉じてIssueをOPENのまま残すと他の作業者が同じスコープに重複着手するため、片側だけのクローズは禁止する。クローズ判断はフェーズ0の安全ガードとは独立に発生し得るため、判断時点でこのルールを適用すること。

手順:

1. クローズ理由を1-3行で言語化する
2. PRに理由を含むコメントを投稿し、PRをクローズする

   gh pr close $0 --comment "<クローズ理由。代替PR/Issueがあればそのリンクを含める>"
   

3. 関連Issueを特定する。GitHub MCP が使える場合は pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。優先順位:
   • gh pr view $0 --json closingIssuesReferences -q '.closingIssuesReferences[].number'（GitHubが自動認識したリンク）
   • 上記が空の場合は gh pr view $0 --json body -q '.body' の本文から Closes #<n> / Fixes #<n> / Resolves #<n> を正規表現で抽出する
4. 取得した各Issue番号について状態を確認し、OPEN の場合のみ以下を実行する。GitHub MCP が使える場合は issue_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。 gh issue view <n> --json state -q '.state'

   gh issue comment <n> --body-file - <<EOF
   ## 関連PRクローズに伴うクローズ
   PR #$0 を以下の理由でクローズしました。本Issueの作業はこのPR内では行いません。
   
   ### クローズ理由
   <理由>
   
   ### 今後の扱い
   <代替PR/Issueがあればリンク。再着手が必要な場合はその旨と新規Issue番号>
   EOF
   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh close-issue <n> not_planned
   

5. 最終報告に「PR #$0 とリンクされたIssue #<n> をクローズした理由・代替手段」を必ず明記する

注意事項

• 修正の委譲判定を指摘ごとに行う: 「実装の委任（判断ロジック）」に従う（ステップ1該当で委譲、ステップ2の全条件充足のみ直接編集、割れたら委譲。滑り坂ガード付き）
• デフォルトブランチで作業しない: フェーズ0で必ず確認。ファイル編集前の pwd 再確認を推奨
• サブエージェントの結果を鵜呑みにしない: 完了報告は「やったつもり」を示すだけ。git diff で実際の差分を必ず検証する
• 指摘の本質に応える: 字面だけ拾って小手先で済ませず、レビュアーの懸念の根本（設計・安全性・可読性）に向き合う
• Issueの要件に反する指摘に従わない: 「スコープと出力の規律」のとおり、要件・確認事項の回答と矛盾する指摘は実装せず、該当箇所を引いてスレッドへ返信する
• コメントは残さない: 生成コードに「なぜ」を説明する以外のコメントを入れないよう、サブエージェントへのブリーフィングにも明記する
• エラーの根本原因に向き合う: テスト失敗を --no-verify やテストのスキップで誤魔化さず、原因を特定してから修正する
• E2Eテストを置き去りにしない: 「E2Eテストの取り扱い（共通ルール）」に従い、ユニットテストのpassだけで完了扱いにしない
• ユーザーへの確認を求めない: 安全ガード（フェーズ0のworktree外/デフォルトブランチ検出、PRがCLOSED/MERGED）に該当する場合のみ中断し、それ以外は既定挙動に従って自律的に完遂する
• PRクローズと関連Issueクローズは必ずセット: 「PRクローズ時の連動処理」を必ず適用し、関連Issueも理由付きコメントを残してクローズする