fix-pr-review

/fix-pr-review：PR レビューコメントのトリアージ、修正、解決

CodeRabbit、/review-pr、または貼り付けられたテキストから PR レビューを受け取ります。各指摘をトリアージし、検証済みの修正を適用して、/done を実行した後、1 つのワークフローで GitHub の会話に返信し、解決します。

実行にユーザーの判断がまだ必要な場合に限り、AskUserQuestion を使用します：ブランチの安全性、stash の確認、意見が分かれた項目の確認、--interactive による修正ごとの確認、型チェック失敗のトリアージ、完了後の次のアクションです。/fix-pr-review の実行、またはレビュー指摘の修正を明示的に依頼することは、検証済み FIX プランの実行を許可します。プランの承認を別途求めないでください。必須の選択肢はすべて具体的な内容にし、検討したうえで、最も推奨するものを先頭に「（推奨）」を付けて示します。

クイックリファレンス

フェーズ概要

R-Rubric の概要（フェーズ 3 STEP 4。最初に一致したルールを適用）

R4/R5 が R3 より上位にあるのは意図的であり、偶然ではありません。また、R10 は R6 より上位にあるため、技術的に正しいという理由だけで指摘が修正ループに進むことはありません。ルーブリック全文とこの順序の理由は references/triage-rubric.md にあります。

主な相互参照

• R-rubric の定義：references/triage-rubric.md。フェーズ 3 STEP 4 でトリアージサブエージェントが読み込みます。メインエージェントは読み込みません
• プラン検証ルール：フェーズ 4（R-rubric で必須となるフィールドを検証）
• 修正実行の振り分け：フェーズ 5（R6 FIX 項目を実行）
• 収束：フェーズ 5.5（プランの class_completeness と inverse_risk を使用し、fix_status と修正ごとの convergence: レポート行に反映）
• 返信バリデーター：references/github-reply-resolve.md の Step 7b（GitHub 返信の形式ルール）
• レポートのグループ化：フェーズ 8（R 分類ごとにグループ化）
• 抑制設定：フェーズ 3「レビュー抑制設定の読み込み」（メインエージェントがサブエージェントの起動前に読み込み）＋ references/triage-prompt.md（サブエージェントが分類前に適用）＋フェーズ 8（書き込み）

参照ファイル

各ファイルの読み込み条件は、使用箇所のポインターに記載されています。事前に読み込まず、その箇所で読み込んでください。

• references/fetch-review-data.md：入力タイプごとの GraphQL／REST フェッチ、CodeRabbit のレビュー本文の構造、Comment スキーマ。メイン処理がフェーズ 2 の GitHub フェッチ手順で読み込みます。また、ローカルファイルの経路で未読の場合は、Comment スキーマの正規化手順でも読み込みます。
• references/triage-prompt.md：フェーズ 3 のサブエージェント用プロンプト全体（STEP 0 → STEP 6 ＋出力形式）。メイン処理がフェーズ 3 で読み込み、プレースホルダーを置き換えて、そのまま渡します。
• references/triage-rubric.md：R1～R10 の詳細、NEEDS-INPUT の判定基準、change_class の使用例、返信形式。トリアージのサブエージェントが STEP 4 で読み込みます。
• references/github-reply-resolve.md：投稿／解決の手順 7a～7d。メイン処理がフェーズ 7 で読み込みます。ローカルファイル入力では読み込みません。
• references/final-report.md：フェーズ 8 のレポートテンプレートと表示ルール。メイン処理がフェーズ 8 で出力前に読み込みます。
• references/branch-safety.md：リポジトリとブランチへの移動、および detached HEAD と異なるブランチに関する質問。メイン処理が GitHub 入力の場合にフェーズ 1 で読み込みます。ローカルファイルの場合はスキップします。
• references/per-fix-loop.md：修正ごとのループ、対話形式の確認、限定的な型チェックとベースライン比較、再試行／スキップ／中止。メイン処理がフェーズ 5 のループで読み込みます。
• references/needs-input-triage.md：NEEDS-INPUT の確定、項目ごとのトリアージ、フェーズ 8 の修正と検証、GitHub への返信前の事前確認。件数が 0 でない場合に限り、メイン処理がフェーズ 8 の手順 1 で読み込みます。

参照ファイルのうち、ここに同梱されていないものが 1 つあります。${CLAUDE_SKILL_DIR}/../review-pr/references/repo-map.md には repo_map_files／repo_map_exports のシェルがあり、このスキルと /review-pr で共有している唯一のコピーです。メイン処理が packages/ または apps/ が存在する場合にフェーズ 1 で読み込みます。

使用方法

/fix-pr-review https://github.com/owner/repo/pull/123
/fix-pr-review https://github.com/owner/repo/pull/123#pullrequestreview-4089716169
/fix-pr-review https://github.com/owner/repo/pull/123#discussion_r3064352825
/fix-pr-review ./review.md            # local output from /review-pr
/fix-pr-review /tmp/review-pr-123-findings.md  # local review export
/fix-pr-review                         # no arg → ask user to paste

オプションのフラグ：

• --dry-run：計画を表示した後に停止し、実行しません
• --interactive：各 FIX 項目を適用する前に確認します
• --all-nitpicks：デフォルトの却下ではなく、Nitpick をすべてトリアージします

トリアージの対象

CodeRabbit、人間、その他のボットを問わず、すべてのレビュアーのコメントを同じ方法でトリアージします。ここで「CodeRabbit」を中心に説明しているのは、最も一般的なユースケースを反映したものです。

フェーズ 1：前提条件＋入力の検出＋ブランチの安全性（メイン処理）

前提条件の確認

command -v gh >/dev/null 2>&1 || { echo "Install gh CLI: https://cli.github.com"; exit 1; }
git rev-parse --is-inside-work-tree >/dev/null 2>&1 || { echo "Not inside a git repo. cd into your clone first."; exit 1; }
gh auth status 2>&1 | grep -q "Logged in" || { echo "Run 'gh auth login' first"; exit 1; }

引数から入力タイプを検出する

• #pullrequestreview-<id> を含む → レビュー URL
• #discussion_r<id> を含む → ディスカッション URL（単一のコメント＋スレッド）
• ./ で始まる／/ で始まる／.md で終わる → ローカルファイル
• フラグメントを含まず、https://github.com/<owner>/<repo>/pull/<num> に一致する → PR URL
• 空 → 内容を貼り付けるか、URL を指定するようユーザーに依頼

実行許可を記録する

元のリクエストで /fix-pr-review を明示的に呼び出している場合、またはレビューの指摘を修正、対処、適用、処理、解決するよう命令形で依頼している場合は、EXECUTION_AUTHORIZED=true に設定します。URL だけの場合、または確認、説明、レビュー、トリアージのみを求める読み取り専用のリクエストの場合は、false に設定します。一致するリクエスト文を execution_authorization_evidence として保持します。フェーズ 4 では明示的な実行の選択によってこの値を置き換えることができ、フェーズ 7 では最終的な証拠を preflight-mutations に渡します。

正しいリポジトリとブランチを確保する（GitHub 入力のみ）

URL から owner、repo、number を解析し、${CLAUDE_SKILL_DIR}/references/branch-safety.md に従って PR のブランチに移動します。今すぐ読み込んでください。作業ツリーがマージ、リベース、またはチェリーピックの途中にある場合は停止し、何かに触れる前に競合の解決を resolving-merge-conflicts に引き継ぎます。

未コミットの作業を自動でスタッシュする（ブランチの安全性）

このステップは、GitHub とローカルファイルのどちらの入力タイプでも実行されます。修正がスタッシュされていない作業中の変更に重ねられることはありません。

git status --porcelain

空でない場合は、AskUserQuestion を使用します。

質問： header: "スタッシュ" text: "未コミットの変更が検出されました。修正を適用する前に自動でスタッシュしますか？内容は最後に復元されます。" options: - label: "自動でスタッシュ" description: "今すぐ変更をスタッシュします。実行完了時に復元されます" - label: "中止" description: "停止します。まず自分で作業をコミットまたはスタッシュします"

「自動でスタッシュ」を選択した場合は、git stash push -u -m "fix-pr-review auto-stash $(date +%s)" を実行します。成功した場合に限り、STASH_OID=$(git rev-parse -q --verify refs/stash) を記録して STASH_PUSHED=true に設定し、その後 git status --porcelain が空であることを確認します。プッシュに失敗した場合は何も記録せず、作成されていないスタッシュを作成済みとして扱うのではなく、実行を中止します。実行が中止された場合、作業は git stash list で fix-pr-review auto-stash <timestamp> として確認できます。 「中止」を選択した場合は、「未コミットの作業を先にコミットまたはスタッシュしてください。」と出力して終了します。

スタッシュ復元ガード。 この実行中のすべての復元処理（ここ、およびすべての早期終了時）は、STASH_PUSHED=true の場合に限り実行します。記録された OID を適用するのは、スタックの先頭がその OID と一致する場合のみです（git stash apply "$STASH_OID" を使い、単独の pop は決して使いません）。適用が正常に完了し、スタックの先頭も引き続き一致する場合に限り、スタッシュを削除します。不一致があれば、すべてのエントリに手を加えず、stash_restored: foreign-top を記録して stash_restored: foreign-top, stash left untouched と出力し、適用も削除もせずに続行します。

マージベースを計算する（後で修正済みかどうかを検出するため）

BASE_SHA=$(git merge-base "origin/$(gh pr view <url> --json baseRefName -q .baseRefName)" HEAD)

Phase 3 の修正済みチェックで使うため、BASE_SHA として保存します。

修正前の型チェックのベースライン（絞り込み型チェックの比較対象）

Phase 5 の前にベースラインの型チェックを 1 回実行し、すでに失敗しているファイルの集合を取得します。

bun turbo run check-types 2>&1 | tee /tmp/fix-pr-review-baseline-$$.log

実行全体で使うパーサーを 1 つ定義します。各診断について、そのファイルをキーとして、ファイル位置、行、列の情報を取り除いた後の <診断コード> + <正規化されたメッセージ> を識別子とします。同一の識別子はマルチセットとして保持します。このパーサーで Phase 1 の出力を解析し、baseline_errors[path] に格納します。Phase 5 と Phase 8 のすべてのベースラインパスでは、同じパーサーと識別子の正規化を使用します。型チェックのツールが見つからない場合（turbo も tsc もない場合）は、ベースラインをスキップし、すべての修正について絞り込み型チェックを skipped として記録します。

共有パッケージのリポジトリマップを計算する（再利用を考慮した分類のため）

共有パッケージとアプリを調査し、Phase 3 の分類処理が、再利用や切り出しに関するコメントを既存の構成と照合できるようにします。packages/ と apps/ の両方をスキャンします。たとえば、apps/backend/src/modules/v1/feature-a/helpers.ts と feature-b/helpers.ts のような、アプリ内でのヘルパーの重複は、NestJS スタイルのモノレポではよくあり、packages/ のみのスキャンでは検出できません。

${CLAUDE_SKILL_DIR}/../review-pr/references/repo-map.md を読み込み、/review-pr と共有されているこのシェルの 1 つだけである Local mode ブロックを実行します。これは、グロブが zsh でも正しく機能するように bash -c でラップし、それぞれの出力を最大 500 行に制限して、切り詰めたことを明示します。packages/ または apps/ が存在する場合はこれを読み込みます。どちらも存在しない場合は実行するものがないため、以下のフォールバックを使用します。

両方の出力を repo_map_files と repo_map_exports として Phase 3 のサブエージェントプロンプト用に保存します。packages/ と apps/ のどちらも存在しない場合（モノレポではない場合）は、両方を N/A (not a monorepo) に設定し、IS_MONOREPO=false とします。分類プロンプトはこれを使って、grep の対象を src/ とリポジトリのルートに切り替えます。

Phase 2: レビューデータを取得する（メイン）

/review-pr の指摘に対する二経路の入力

/review-pr は、各指摘を特定のコード行に対する個別のインラインコメントとして投稿するようになりました。これらは、CodeRabbit のスレッドと同じ標準の GitHub PullRequestReviewThread を作成します。以下の既存の GraphQL 取得処理で、特別な解析を一切行わずに処理できます。

手動でエクスポートしたファイルや、以前の形式の /review-pr の指摘ファイルには、既存のローカルファイル経路を使用します。Phase 7 では、これらの入力に対する GitHub 操作をスキップします。

GitHub から取得する場合（PR URL／レビュー URL／ディスカッション URL）

Phase 1 では、これら3種類の入力のうち、ちょうど1つを検出しました。${CLAUDE_SKILL_DIR}/references/fetch-review-data.md を今すぐ読み込み、該当する種類のセクションだけを実行します。このファイルには、ページネーションに対応した GraphQL の reviewThreads クエリとその isResolved フィルター、/pulls/<num>/reviews/<review_id> および /pulls/comments/<comment_id> の REST エンドポイント、CodeRabbit のレビュー本文の構成、そして、インラインスレッドが作成されないためニットピックが現れる唯一の場所である 🤖 Prompt for all review comments with AI agents ブロックの解析方法が記載されています。

取得に失敗した場合は、エラーを表示して終了するため、不完全なコメント一覧に対してトリアージが実行されることはありません。これにより、GraphQL のレート制限、404、プライベートリポジトリ、ページネーションループ内の各ページでの失敗に対応します。404 の場合は、Couldn't access PR. Check repo access and run 'gh auth refresh -s repo'. と表示します。

ローカルファイルの場合（./review.md、/tmp/review-pr-*-findings.md など）

/review-pr の出力形式を解析します。## Findings セクションから指摘を抽出し、該当する場合は Severity / File / Category / Issue / Why it matters / Suggested fix に加えて Rule-class / Enclosing-symbol / Inverse risk / Class-sites も保持します。/review-pr はこれらを指摘ごとに出力します。これらを削除すると、レビュー担当者がすでに行った作業をこのスキルで再度導出することになります。

再導出せず、値を初期値として使う：Inverse risk: がある場合は、STEP 5 の inverse_risk の初期値として使い、ゼロから新たな値を導出するのではなく、コードに照らして検証します（名前が示す失敗モードが実在し、現在も当てはまることを確認します）。Class-sites: <A>/<N> がある場合は、STEP 1.5 の class_completeness をその N 件のサイトで初期化し、自分で検索して件数を検証します。検索は、レビュー担当者が見落としたサイトを見つけるために再実行するものであり、一覧を作り直すためではありません。Rule-class と Enclosing-symbol は、クラス全体の調査における signature の初期値になります。初期値がコードを読んだ結果と矛盾する場合は、コードを優先します。その差異を該当フィールドに記録します。

重大度の対応付け：/review-pr では Critical | Serious | Moderate | Minor を使用し、CodeRabbit では Critical | Major | Minor | Refactor | Nitpick を使用します。どちらも有効です。どちらの形式も受け入れる内部の Comment スキーマに正規化します。トリアージの優先度は次のように対応付けます：Critical = 最高、Serious／Major = 高、Moderate = 中、Minor／Refactor = 低、Nitpick = デフォルトで却下。

内部の Comment リストに正規化する

すべての入力経路はここに到達します。Phase 3〜8 が読み取る正確なフィールド名を含む Comment スキーマは、references/fetch-review-data.md で定義されています。ローカルファイル経路を使用し、まだ読んでいない場合は、今すぐそのファイルを読み込みます。

早期終了するケース

• リストが空（すべてのスレッドが解決済み、またはローカルファイルに指摘がない）：Nothing to triage. No unresolved comments found. と表示 → ガードの条件に従って stash を復元 → 終了コード 0。
• ニットピックのみが残り、かつ --all-nitpicks が設定されていない：Only nitpicks found (N). Pass --all-nitpicks to triage them, or ignore. と表示 → ガードの条件に従って stash を復元 → 終了コード 0。

Phase 3：トリアージ用サブエージェント（general-purpose）

レビュー抑制設定の読み込み（メインエージェント、ディスパッチ前）

サブエージェントをディスパッチする前に、作業ツリーではなくベースリビジョンの .claude/review-suppressions.yml を読み込みます。チェックアウト済みの PR が自身のトリアージを抑制してはなりません。GitHub からの入力では、ピン留めされたベース OID の時点で読み込みます。ローカルでは git show "$PINNED_BASE_OID:.claude/review-suppressions.yml" を実行し（オブジェクトがない場合は一度だけ origin をフェッチします）、クロスリポジトリモードでは gh api repos/<owner>/<repo>/contents/.claude/review-suppressions.yml?ref=$PINNED_BASE_OID を実行します。PR のないローカルファイル入力では、HEAD 自体がトリアージ対象の変更である場合があります。信頼できるベースは、他の候補すべてを含む唯一の候補マージベースとして解決します。各メインラインにつきベースを 1 つ収集し、ローカルのメインライン自体がトリアージ対象の変更である可能性があるため、ローカルの相当物よりリモートエイリアスを優先します。そのうえで、残りすべてを含むベースが 1 つだけの場合に限り、それを採用します。同順位、比較不能な候補の組み合わせ、または候補が空の場合は、抑制を無効にします。

BASES=$(for remote in origin/main origin/master origin/develop; do
  bare=${remote#origin/}
  if git rev-parse --verify -q "$remote" >/dev/null 2>&1; then ref=$remote
  elif git rev-parse --verify -q "$bare" >/dev/null 2>&1; then ref=$bare
  else continue
  fi
  git merge-base HEAD "$ref" 2>/dev/null || continue
done | sort -u)
RESULT=""
if [ -n "$BASES" ]; then RESULT=$(printf '%s\n' "$BASES" | while IFS= read -r b; do
  [ -n "$b" ] || continue
  BAD=$(printf '%s\n' "$BASES" | grep -vx "$b" | while IFS= read -r o; do
    git merge-base --is-ancestor "$o" "$b" 2>/dev/null || printf 'bad\n'
  done)
  [ -z "$BAD" ] && printf 'WINNER %s\n' "$b"
done); fi

採用されたコミットのファイルを読み込み、読み込み元をログに記録します。入力が空でも成功する方法で採用数を数えてください。grep -c は 0 件の場合に終了コード 1 を返します。

WINNERS=$(printf '%s\n' "$RESULT" | grep -c WINNER || true)

WINNERS が 1 で、採用されたコミットが HEAD 自体ではない場合に限り、それを使用します。HEAD と同じ採用結果は、信頼できる古いベースがないことを意味します。それ以外の場合は SUPPRESSIONS = "" に設定します。ポリシーなしでトリアージするとノイズが増え、レビュー対象の変更を信頼すると検出結果が隠れてしまいます。候補セットが空の場合、採用結果の行は出力されません。ベースに該当ファイルがない場合は SUPPRESSIONS = "" に設定し、PR で追加されたファイルを無視したことをログに記録します。

読み込んだ抑制設定を ## Review suppressions セクションとしてサブエージェントのプロンプトに渡します（CLAUDE.md の内容、PR の差分、リポジトリマップと同じ方法です。メインエージェントが取得し、サブエージェントはコンテキストとして受け取ります）。

ディスパッチ

Read、Grep、Bash ツールを備えた general-purpose サブエージェントを1 つディスパッチします。トリアージ計画は、このサブエージェント単独で作成します。サブエージェントが完全に失敗した場合は実行を中止し、その旨を伝えます。インラインで分類すると、計画全体の基盤となるグラウンディングとクラススイープの工程が省略されます。

重要：Bash の許可リスト（git log/diff/blame/show/merge-base/rev-parse、grep、rg）はプロンプトレベルの指示です。Claude Code の Agent ツールは Bash のコマンドごとにサンドボックス化しません。サブエージェントが他のコマンドを実行しないことは信頼されていますが、機械的に禁止されているわけではありません。

プロンプトテンプレート

プロンプト全体は references/triage-prompt.md にあります。今すぐ読み込み、<...> プレースホルダー（<SKILL_DIR> = このスキルの絶対パス、および Phase 1 のコンテキスト値、git diff <BASE_SHA>...HEAD の出力、リポジトリマップ、SUPPRESSIONS、Phase 2 の Comment[] 配列）を置き換えて、結果を一字一句そのままサブエージェントに渡します。これはサブエージェントが実行する文字列であり、あなたが従う指示でも、要約やインラインで言い換える内容でもありません。

STEP 4 では、サブエージェント自身が references/triage-rubric.md を参照します。このファイルは読みません。R-Rubric の概要表がメインエージェント向けの情報です。返された内容は Phase 4 で検証します。各 FIX について、プロンプトは fix_plan、change_class、test_scenario、inverse_risk:、class_completeness: を出力します。reusability_context: は FIX だけでなく、すべての項目に含まれます。

Phase 4：計画実行ゲート（メイン）

R-rubric に照らして検証します。概要表は上記、詳細は references/triage-rubric.md にあります。分類ごとの必須フィールドは、同ファイルで定義されています。

計画の検証（表示前）

ユーザーに何かを表示する前に、分類器の出力を機械的に検証します。

• rubric: R5 の DISMISS には、空でない claude_md_quote が必須です。
• rubric: R4 の DISMISS には、空でない prior_commit_sha が必須です。
• すべての DISAGREE には、空でない disagree_rationale が必須です（また、純粋なスタイル上の好みであってはなりません。「prefer」「cleaner」「nicer」などの語があり、具体的な反論がない場合は確認してください）。
• すべての FIX には、30 文字以上の fix_plan が必須です。
• すべての FIX では、change_class が hardening または logic-change のいずれかと完全に一致している必要があります（分類器が適用した判断基準は references/triage-rubric.md にあります。このチェックでは文字列の値のみを確認します）。
• すべての FIX には、空でない test_scenario が必須です。change_class: hardening の場合、値は smoke test, happy path unchanged と完全に一致している必要があります。change_class: logic-change の場合、具体的な再現手順を1文で記述する必要があります（「動作を確認する」だけでは不十分です）。
• すべての FIX には、具体的な障害モードを示すか、none, pure addition と完全に一致する、空でない inverse_risk が必須です。曖昧な表現は検証に失敗します。値が空の場合や、「could have issues」「minor risk」「some risk」「possible regression」のような形式、または単独の「none」は不可です。障害モードを示す場合は、何が、どこで壊れるのかを記述します。フェーズ 5.5 ではこのフィールドを使用するため、名前のないリスクは検証できません。
• すべての FIX には、空でない verdict があり、COMPLETE または INCOMPLETE のいずれかで始まる class_completeness ブロックが必須です。INCOMPLETE の場合、除外した箇所を示し、それぞれの理由を記載する必要があります。箇所ごとの理由がない INCOMPLETE 判定は検証に失敗します。
• rubric: R10 の NEEDS-INPUT には、current:、proposed:、intent evidence: の3つの部分をすべて含み、それぞれが空でない why_unclear が必須です。形式は references/triage-rubric.md に記載されています。証拠の値として found nothing は有効ですが、空欄は不可です。
• すべての項目には、空でない grounding_a と grounding_b が必須です。
• すべての項目には、{ flagged: false } だけの場合も含め、reusability_context フィールドが必須です。NEEDS-INPUT を含むすべての分類が対象です。フェーズ 7 の返信バリデーターはこのフィールドに基づいて分岐するため、フィールドがないと、その返信の再利用性チェックが暗黙に無効になります。

検証に失敗した場合：不足しているフィールドを具体的に列挙して、分類器に再度処理を指示します。再試行は最大1回です。2回目も失敗した場合は、検証エラーを出力して中止します。

計画の表示

次のヘッダーを付けて計画を出力します。

# Fix Plan, PR #<num>: <title>
# <N> findings triaged: <F> fix, <D> dismiss, <E> defer, <G> disagree, <I> needs-input, <n> nitpicks

CLAUDE.md による DISMISS を目立つように強調する

rubric: R5 の DISMISS がある場合は、メインの計画の前に、独立した強調セクションを出力します。

## ⚠ Dismissed because they contradict CLAUDE.md: review and override if any are exceptions

[D<n>] <file:line>: <comment ask>
       CLAUDE.md rule: "<verbatim quote>"
       Reply will be: "<reply>"
       If this rule has a legitimate exception in this case, select D<n>
       in the contested-item confirmation to change it to FIX or NEEDS-INPUT.

異議のある項目の確認（multiSelect）

異議のある項目とは、コード変更を行わずに返信を投稿してスレッドを解決する項目です。つまり、すべての DISMISS、DEFER、DISAGREE が該当します。ここで分類を誤ると、レビュアーとのやり取りが気づかれないまま終了します。Phase 5/7 で実行する前に、トリアージを確認してください。

異議のある項目が 0 件の場合は、この手順をスキップしてください。該当する項目がある場合は、AskUserQuestion を使用します。

Question: header: "Triage" text: " 件の項目について、コード変更なしで返信し、スレッドを解決します。再分類する項目を選択してください。選択されなかった項目は、予定どおりに進めます。" options: [DISMISS/DEFER/DISAGREE の項目ごとに 1 つのオプション：「[] file:line: ()、<reason の先頭約 60 文字>」] multiSelect: true

異議のある項目がオプション数の上限を超える場合は、複数の multiSelect 質問に分割してください。誤りのコストが最も大きい DISMISS を最初にします。

選択された項目ごとに、AskUserQuestion で追加質問します。

Question: header: "Item " text: "file:line。現在の分類は です。理由：。再分類先は？" options: - label: "FIX (Recommended)" description: "実際の問題として扱い、修正計画とともに FIX リストに追加します" - label: "NEEDS-INPUT" description: "保留にして何も投稿せず、最終レポートに記載します" - label: "Keep as-is" description: "誤って選択されたため、元の分類を維持します"

「FIX」の場合は、この項目だけを対象として分類器を再実行し、FIX に必要なすべてのフィールドを生成します。fix_plan、change_class、test_scenario、inverse_risk、class_completeness（クラス全体の調査を含む。再分類された項目はまだ調査されていません）、および reusability_context（調査によって変更されない限り、異議のある項目独自の値を引き継ぎます）。その後、変更された項目についてプランの検証を再実行します。ここで一部のフィールドしか生成しないと、検証に失敗し、1 回限りの再試行が消費されます。「NEEDS-INPUT」の場合は、why_unclear: "user contested the <classification> classification" を設定して NEEDS-INPUT に移し、項目の reusability_context を変更せずに引き継ぎます。「Keep as-is」の場合は変更しません。「Other」の場合は、自由記述のテキストを再分類の指示として扱います。

この手順では何も投稿せず、スレッドも解決しません。GitHub に触れるのは引き続き Phase 7 だけであり、この確認を通過した項目のみを処理します。スレッドの解決はレビュアーとのやり取りに取り消せないノイズを生じさせます。この確認を経ていない DISMISS、DEFER、DISAGREE は、この手順を通過するまで未回答のまま開かれています。

実行

--dry-run の場合：プランを出力し、dry run, not executing を出力して、ガードの下で stash を復元し、0 で終了します。

EXECUTION_AUTHORIZED=true の場合は、直接 Phase 5 に進みます。この呼び出しによって、検証済みのすべての FIX 項目の実行がすでに許可されています。--interactive が設定されている場合は、Phase 5 で項目ごとに確認を求めます。これはプラン全体の確認を追加するものではありません。

それ以外の場合は、AskUserQuestion を使用します。

Question: header: "Execute" text: "リクエストでは編集が明示的に許可されていません。検証済みのプランを実行しますか？ FIX 件、DISMISS 件、DEFER 件、DISAGREE 件、NEEDS-INPUT 件。" options: - label: "Execute plan (Recommended)" description: "すべての FIX 項目を依存関係の順序に従って適用します" - label: "Cancel" description: "作業ツリーを変更せず、stash があれば復元します"

preedit_snapshot[path] = <full file content from Read>

fix_status[idx] = ok | retried_ok | inconclusive | skipped | aborted | type_check_skipped
                | reverted_inverse_risk | inverse_risk_applied | partial | restored_failed
landed_fix_statuses = {ok, retried_ok, inconclusive, type_check_skipped}

For each fix below, verify against the working tree, not against the fix plan's claims.

1. CLASS COMPLETENESS: every site the class sweep marked `affected` in
   `class_completeness.sites` must actually be changed. A fix that landed on 3 of 4
   sites is INCOMPLETE, not done.
   (Sites the plan's `verdict` deliberately excluded are not counted as unfixed.)
2. INVERSE RISK: the named failure mode must NOT be present in the applied code.
3. NEW SIBLINGS: did the fix itself introduce a new instance of the pattern it fixes,
   or a new branch (error state, empty state, early return) that its siblings have but
   this one lacks?

Report per fix, nothing else:
  fix: <idx>
  class_complete: yes | no, <unfixed site if no>
  inverse_risk_present: no | yes, <file:line + one sentence>
  new_siblings: none | <file:line + one sentence>

Evidence rules differ per check. "I lack evidence" is not an answer for check 1:
  - Check 1 is decided MECHANICALLY by `git diff HEAD`. Each affected site either
    appears in the diff or it does not; there is no undecidable state. Report `no`
    with the unfixed site whenever a site is absent from the diff.
  - Checks 2 and 3 default to `no` / `none` unless you can cite a concrete file:line
    in the applied code. Do not speculate, do not re-review the PR, do not report
  style issues.

self_heal_iter = 0
done_remaining = []
while self_heal_iter < 2:
    findings = run_parallel_review(diff="git diff HEAD")
    blockers = [f for f in findings if f.severity in ("Critical", "Serious")]
    if not blockers:
        break
    # Dispatch fresh subagent per blocker with the finding + the diff
    for f in blockers:
        apply_subagent_corrective_edits(f)
    run_fix_ts_errors()
    self_heal_iter += 1

# After loop: record whatever blockers remain (if any)
done_remaining = blockers

gh_status[idx] = {
  reply_state: landed | verified-existing | confirmed-absent | reconcile-required | skipped | not-applicable,
  reply_err:   <error message if any>,
  resolve_state: resolved | already-resolved | confirmed-open | reconcile-required | skipped | not-applicable,
  resolve_err: <error message if any>
}

if [ "$(git rev-parse -q --verify refs/stash)" = "$STASH_OID" ]; then
  if git stash apply "$STASH_OID"; then
    [ "$(git rev-parse -q --verify refs/stash)" = "$STASH_OID" ] && git stash drop || echo "STASH_CHANGED_MID_RESTORE"
  elif [ -n "$(git diff --name-only --diff-filter=U)" ]; then
    echo "STASH_CONFLICT"
  else
    echo "STASH_APPLY_FAILED"
  fi
else
  echo "STASH_TOP_MISMATCH"
fi

  - pattern: "<normalized pattern from finding: key phrase, not full text>"
    category: "<finding category if available>"
    file: "<finding's file path. Include only if the rationale is specific to one file, omit for generic patterns>"
    reason: "<dismiss/disagree rationale from triage>"
    added: <today's date YYYY-MM-DD>

suppressions:
  - pattern: ...

git push --force-with-lease="<exact-ref>:<expected-sha-or-empty>" "<preflighted-remote>" "<frozen-local-sha>:<exact-ref>"
git ls-remote --heads "<preflighted-remote>" "<exact-ref>"