review-pr

/review-pr：GitHub PR の詳細レビュー

アンチスロップフィルタリングを適用して、リモートの GitHub PR をレビューします。PR の URL 以外は受け取りません。

目標は、正確で批判的かつ実行可能な PR レビューを作成し、ノイズ（スタイルに関する些細な指摘、根拠のない参照、重複、一般的なアドバイス）を取り除いて、結果を GitHub に送信することです。ほかの作者の PR のレビューには REQUEST_CHANGES または APPROVE を使用します。自分自身の PR のレビューには COMMENT を使用します。GitHub では作者が自分の PR を承認することは禁止されているためです。

カスケードとは、このレビューで防ごうとしている失敗です。ラウンド N の指摘に対して出した修正が、ラウンド N+1 の指摘になってしまうことです。これを引き起こす要因は 2 つあります。提案された修正自体に不具合があること、そして引用された箇所には修正が適用される一方、同一の兄弟箇所には適用されないことです。そのため、コード変更を提案するすべての指摘には、各要因について 1 つずつ、Inverse risk: と Class-sites: の件数を記載します。フェーズ 3 ではステップ 7.5 で結果を cascade_share として測定し、ステップ 8 の判定ではその値を読み取って PR が収束しているかどうかを示し、フェーズ 4 ではその値を出力します。

このスキルでは、リポジトリに .coderabbit.yaml を設定し、CodeRabbit を利用できることを前提としています。CodeRabbit がスタイルや規約に関する指摘を先に処理します。/review-pr は、これにしかできない、意味とコードベース全体に関する詳細なレビューを担当します。

ユーザー向けの判断がまだ必要な場合は AskUserQuestion を使用してください：中断して質問する場合と、失敗後の復旧です。投稿は判断のタイミングではありません。/review-pr の実行は、レビュー全体の送信を許可するものです。大規模な PR では、確認を求めず、常に分割してレビューを進めます。ユーザーに 2 つ以上の選択肢を提示する文は、すべて AskUserQuestion の呼び出しにしてください。選択肢はカーソルで選択でき、具体的で、十分に検討されたものにしてください。最も適切な選択肢を先頭に置き、「（推奨）」と明記してください。

参照ファイル

メインまたはサブエージェントは、各ファイルに到達する分岐でのみそのファイルを読み込みます。読み込み担当と実行条件：

• references/batch-mode.md：オーケストレーションのルール、「停止しない」セマンティクス、統合レポートのテンプレート、自動投稿の手順が記載されています。ユーザーが PR URL を 2 件以上指定した場合、またはすべてのオープン PR を確認するよう依頼した場合、Phase 1 で main が読み込みます。
• references/reviewer-prompt.md：Subagent 1 のプロンプト全文、その作業に適用されるアンチスロップルール、finding の形式をプロンプト内で繰り返さない理由についての注記が記載されています。すべての SIZE_MODE 分岐で、Phase 2 のディスパッチ時に main が読み込みます。
• references/cross-cutting-prompt.md：Subagent 3 のプロンプト全文が記載されています。SIZE_MODE が parallel-chunked の場合、Phase 2 のディスパッチ時に main が読み込みます。チャンク分割しないモードでは Subagent 3 をディスパッチしません。
• references/q5-type-coercion.md：Q5 の型強制スキャンについて、型強制のメソッド、フィールドが数値かどうかの判定方法、重大度が記載されています。差分に DB の insert/update、または API ペイロードの構築が含まれる場合、Q5 への回答時に Subagent 1 が読み込みます。
• references/class-sweep-and-inverse-risk.md：reviewer-prompt のステップ 5 と 6 について、影響範囲の検索順序、class_completeness: および Inverse risk: フィールドのルール、逆リスクの具体例が記載されています。いずれかの finding でコード変更が提案された時点で、Subagent 1 が読み込みます。
• references/repo-map.md：repo_map_files / repo_map_exports のシェル、ローカルモードとリポジトリ間モードが記載されています。これはリポジトリ内の唯一のコピーであり、/fix-pr-review もここから読み込みます。packages/ または apps/ が存在する場合、Phase 1 で main が読み込みます。
• references/q6-reusability-search.md：STEP A の列挙、STEP B の検索アルゴリズム、Q6 の制御フローのギャップが記載されています。差分に STEP A のいずれかの種類に該当する新しい定義が 1 つ以上含まれる場合（トップレベルのみではありません）、Subagent 1 が読み込みます。リポジトリ間検索のブロックは references/q6-cross-repo.md にあり、repo_map_exports がリポジトリ間の N/A マーカーの場合にのみ読み込まれます。
• references/finding-output-format.md：finding ごとのフィールドブロック、class_completeness: の監査形式、実行単位の締めくくりブロックが記載されています。finding の形式を定義する唯一のコピーです。Subagent 1、Subagent 3、V3 が finding を記述する前に読み込みます。
• references/schema-design-checks.md：Q7（重複）、Q8（1:1 の統合）、Q9（テーブル間 FK）のチェックが記載されています。INCLUDE_SCHEMA_CHECKS = true の場合は Subagent 1 が、ギャップチェックが Q7〜Q9 を対象とする場合は V3 が読み込みます。
• references/verification-subagents.md：V1/V2/V3 のディスパッチ条件と、それぞれに渡す正確なプロンプトが記載されています。ステップ 4.55 / 4.9 / 6 のうち最初に実行されるステップで、Phase 3 に main が読み込みます。
• references/false-positive-rules.md：各 finding が通過する 4 つのルールからなる YAML テーブル（wrapped-coercion、intent-alignment、library-behavior-citation、default-fallback）が記載されています。ステップ 4.5 を通過した finding がある場合、Phase 3 のステップ 4.6 で main が読み込みます。
• references/finding-state-schema.md：2 つの永続化ファイルについて、.claude/review-state/<pr>.yml（スキーマ、finding ID の方針、状態機械、Phase 1 の読み込みパス）と、実行間キャッシュ（スキーマと 3 つの再生分岐）が記載されています。Phase 1 の review-state 読み込みとキャッシュ確認の前に main が読み込み、Phase 3 まで保持します。Phase 4 の書き戻しとスイープは ${CLAUDE_SKILL_DIR}/references/finding-state-phase4.md にあり、Phase 4 では投稿後に、また状態ディレクトリが空でない場合は Phase 1 の開始時にも読み込まれます。
• references/github-posting.md：新規レビューの REST/GraphQL 投稿フローについて、要約本文、finding ごとのコメント、hunk の検証、Phase A から C、書き戻しが記載されています。レビューが完了するたびに、Phase 4 で main が読み込みます。以前のレビューまたはキャッシュエントリがある状態で再実行する場合は ${CLAUDE_SKILL_DIR}/references/github-posting-rerun.md（ステップ 0、0b、0c、4-rolling、8d）も読み込みます。投稿に失敗した場合は ${CLAUDE_SKILL_DIR}/references/github-posting-recovery.md（ステップ 7）も読み込みます。
• references/phase1-timeline-state.md：以前のレビューのスレッド検索とその整形、review-state の読み込みとラウンドの初期化、実行間キャッシュの各分岐が記載されています。Phase 1 のタイムライン、状態、キャッシュの各ステップで main が読み込みます。
• references/dispatch-prompts.md：<SKILL_DIR> の導出、<PROMPT_PREAMBLE> ブロックと <GROUND_TRUTH> ブロック、サイレントな失敗を検出するハンターのコンテキストパケットが記載されています。Phase 2 のディスパッチ時に main が読み込みます。
• references/critic-verify.md：ステップ 1 から 4.56 までのクリティック処理について、重複排除から逆リスクの検証までが記載されています。Phase 3 のステップ 1 で main が読み込み、ステップ 4.56 まで保持されます。ルーティングされた finding がある場合はステップ 6 で再読み込みします。
• references/critic-round2.md：ステップ 4.9、4.95、4.96 のクリティック処理、回帰スイープ、抑制、系譜が記載されています。ラウンド 2 以降のみ、Phase 3 のステップ 4.9 で main が読み込みます。 4つのクロージャーがあるため、参照ファイルの読み込みは一意に定まります。Main が finding-output-format.md を読み込むことはありません。Subagent 1、Subagent 3、V3 だけが、指摘を書き込む前にこれを読み込みます。V1 と V2 は参照ファイルを読み込まず、指摘のテキストから簡潔な判定を報告します。Main が schema-design-checks.md や q5-type-coercion.md を読み込むこともありません。それぞれ Subagent 1 が独自の条件に基づいて読み込み、V3 はギャップチェックの対象に Q7〜Q9 が含まれる場合に限り、スキーマチェックを読み込みます。スロップを避けるルールは reviewer-prompt.md のみに置きます。どのディスパッチでも、別のコピーをプロンプトに貼り付けることはありません。

計画ドキュメントによる根拠確認（レビュー前の任意コンテキスト）

docs/superpowers/specs/ または ~/.claude/plans/*.md がこの PR に言及している場合は、差分をそれらに記載された設計上の決定と照合し、ドキュメントにない相違点を Q1 Intent の下に指摘してください。そのようなファイルがない場合は、この確認をスキップしてください。

使用方法

/review-pr https://github.com/owner/repo/pull/123

URL が指定されていない場合は、ユーザーに URL を尋ねてください。単独の gh コマンドは、現在のブランチから PR を推定します。このスキルは、指定された URL のレビューを行います。

バッチモード（複数の PR）

ユーザーが 2 件以上の PR URL を指定するか、すべてのオープン PR のレビューを依頼した場合に実行します。単一 PR の実行では、この処理全体をスキップし、Phase 1 に進みます。バッチモードでは、ほかの作業を始める前に ${CLAUDE_SKILL_DIR}/references/batch-mode.md を読み込んでください。このファイルには、PR の列挙方法、オーケストレーションのルール（PR ごとにサブエージェントを 1 つ割り当てる、main はインラインでレビューしない、サブエージェントは投稿も質問もしない）、レビューのみのチェックポイントで「停止しない」動作、統合レポートのテンプレート、自動投稿の順序が記載されています。

---

Phase 1：コンテキストの収集（main）

これらを、1 つのアシスタントメッセージ内で、別々の Bash ツール呼び出しとして 2 回実行してください。真の並列処理には、&& で連結するのではなく、個別の tool_use ブロックが必要です。

gh pr view <url> --json number,title,body,author,baseRefName,headRefName,headRefOid,baseRefOid,additions,deletions,changedFiles,files,closingIssuesReferences,reviews,comments,state,isDraft
gh pr diff <url>

headRefOid から CURRENT_HEAD を、baseRefOid から PINNED_BASE_OID を、baseRefName から BASE_REF_NAME を記録してください。2 回の呼び出しの間に push が反映されると、異なるリビジョンが混在します。差分を取得した後、両方の OID を再読み込みし、記録した組み合わせと一致することを確認してください。いずれかが一致しない場合は、両方の結果を破棄し、Phase 1 を 1 回再開してください。2 回目も一致しない場合は、レビュー中に PR が更新された旨を注記して続行してください。

以下の独立した読み取りを、1 つのアシスタントメッセージ内で並列の Bash ツール呼び出しとして実行してください。閲覧者のログイン情報、関連する Issue の本文、レビューのスレッド、cwd のリポジトリ、CodeRabbit の設定、抑制設定を取得します。これらは PR URL と owner/repo 以外には依存しないため、順番に実行すると単に処理時間が増えるだけです。

Phase 1 では完全な差分を取得します。これを main のコンテキストに保存してください。エラーハンドリングの内容スキャンと Phase 3 の critic による参照確認の両方で必要です。

空の差分に対するショートサーキット

changedFiles == 0 または additions + deletions == 0 の場合：

レビュー対象がありません。 この PR にはレビュー可能なファイル変更が含まれていません。

直ちに停止してください。

プライベートリポジトリ／アクセスエラーの処理

gh pr view が GraphQL の解決エラーまたは HTTP 404 を返した場合：

PR にアクセスできませんでした。 リポジトリへのアクセス権を確認してください。gh auth refresh -s repo を試してから再試行してください。

それ以上の処理を行わずに失敗として終了してください。

自己レビュー投稿の検出

メタデータのリクエストが成功した後、認証済みの閲覧者と、そのレスポンスですでに記録されている PR 作成者を比較してください。

VIEWER=$(gh api user -q .login)
AUTHOR=<.author.login from the Phase 1 metadata>

GitHub のドキュメントには、プルリクエストの作成者は自分のプルリクエストを承認できないと記載されています。アカウントが一致する場合は IS_SELF_REVIEW=true に設定し、レビュー全体を続行してください。Phase 3 では引き続き、意味上の判定を approve または request-changes として決定します。Phase 4 ではレビューを COMMENT として送信し、GitHub が記録できない承認を主張することなく、要約と各指摘のスレッドを保持します。それ以外の場合は IS_SELF_REVIEW=false に設定してください。

リンクされたイシューを抽出する

1. closingIssuesReferences を優先します（各項目には独自の repository.nameWithOwner が含まれています。PR のリポジトリではなく、こちらを使用してください）。
2. 見つからない場合は、本文を正規表現で検索します：(?i)(?:close[sd]?|fix(?:e[sd])?|resolve[sd]?)\s+#(\d+)（同じリポジトリのみ）。
3. リンクされたイシューごとに、gh issue view <num> --repo <owner>/<repo> --json title,body,state を実行します。
4. リンクされたイシューが 2 件以上ある場合は、multiple linked issues, so intent may be ambiguous と記録します。目標が明らかに矛盾している場合は、停止して質問するフォールバックに進みます。

意図モデルを構築する

Goal: <one sentence from issue + PR description>
Expected touches: <what files/areas should be changed>
Out of scope: <anything the issue explicitly excludes, or "none">
Size: <additions>/<deletions> lines across <N> files
Draft: <yes|no>

過去のレビューのタイムラインを構築する

すべてのレビュー スレッドを取得し、${CLAUDE_SKILL_DIR}/references/phase1-timeline-state.md に従って保存済みの状態を読み込みます。今すぐ読み込んでください。このファイルには、スレッドのクエリ、過去の指摘の形式、状態ファイルの読み込みとラウンドの初期化、キャッシュ分岐が記載されています。ここで構築した内容は、Phase 3 の重複排除と第 2 ラウンドのリグレッション調査に使用されます。

レビュー状態の読み込み（複数ラウンドの重複排除）

上記で読み込んだリファレンスに記載されています。

停止して質問するフォールバック

リンクされたイシューがなく、かつ PR の説明に次の項目が1 つも含まれていない場合に実行します。

• ファイルパスまたはディレクトリへの言及
• 関数／クラス／シンボル名
• エラーメッセージまたはスタックトレース
• 再現コマンド
• 本文中のリンクされたイシューの URL（closingIssuesReferences 以外の場所も含む）

「X を更新」「バグを修正」「wip」のような説明では不十分です。一方、「auth/cache.ts の削除処理で発生する競合状態を修正。make stress-test-auth で再現」といった簡潔でも根拠のある説明は十分です。

トリガーされたら、AskUserQuestion を実行します。

header: "Intent"
text: "Intent is unclear. No linked issue and the description lacks grounding signals. How should I proceed?"
options:
  - "Proceed anyway": Review with just the diff; findings will be generic without grounding
  - "Skip this PR": Abort the review
  - "I'll provide intent": Wait for user to type intent text

「意図を提示する」と回答された場合は、追加のテキストが届くまで待ってから、その内容に基づいて意図モデルを構築します。

サイズに関する警告

additions + deletions > 2000 の場合：

この PR は Y 個のファイルにわたる X 行に影響します。レビューが煩雑になり、時間がかかる可能性があります。続行します。

所要時間の計測（開始）

Phase 1 の開始時に PHASE_START_TIME=$(date +%s) を記録し、以降の各 Phase でも同様に記録します。Phase 4 で合計経過時間を出力します。

作業ディレクトリと PR のリポジトリの不一致を検出する（クロスリポジトリモード）

CWD_REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner 2>/dev/null || echo "")
PR_REPO="<owner>/<repo>"
[ -z "$CWD_REPO" ] || [ "$CWD_REPO" != "$PR_REPO" ] && CROSS_REPO_MODE=true || CROSS_REPO_MODE=false

クロスリポジトリモードでの変更点：

1. リポジトリマップの計算では、リモートから gh api でツリーを取得するフォールバックを使用します。
2. Phase 3 の修正済みチェックでは、ローカルの git log ではなく gh api を使用します。

Phase 4 の出力ヘッダーにその旨を記載します。

CodeRabbit の設定チェック（1 回限りのヒント）

セッションごとに (owner, repo) の組み合わせにつき 1 回、PR のリポジトリに .coderabbit.yaml が存在するか確認します。

gh api "repos/<owner>/<repo>/contents/.coderabbit.yaml" >/dev/null 2>&1 \
  && CR_CONFIG_PRESENT=true \
  || CR_CONFIG_PRESENT=false

CR_CONFIG_PRESENT=false であり、かつ現在のセッションでこのリポジトリに対する /review-pr の初回実行である場合は、Phase 4 の出力後に 1 回だけヒントを表示します。

<owner>/<repo> に .coderabbit.yaml がありません。追加すると、CodeRabbit でスタイルと規約のチェックを行えるようになります。テンプレート https://raw.githubusercontent.com/bhagyamudgal/skills/main/coderabbit-config/coderabbit.yaml.template を <repo>/.coderabbit.yaml にコピーしてください（手順はそのリポジトリの coderabbit-config/README.md を参照）。今後このリポジトリで実行する /review-pr の精度が高まります。

このヒントは参考情報です。投稿を妨げることはありません。

サイズに基づく振り分け（SIZE_MODE を決定する）

SIZE = additions + deletions

if SIZE <= 500:     SIZE_MODE = "parallel-standard"     # Subagent 1 reviewer + conditional silent-failure hunter
else:               SIZE_MODE = "parallel-chunked"      # Per-chunk reviewers + hunter + cross-cutting reviewer, always proceed without asking

サブエージェント 1 は常にディスパッチします。小規模な PR でも、サブエージェントとの 1 往復が発生します。

実行間キャッシュのチェック

上記で読み込んだ ${CLAUDE_SKILL_DIR}/references/phase1-timeline-state.md に従って、実行間キャッシュを確認します。

PRIOR_STATE.convergence が存在する場合は、Phase 2 の前に、現在のリクエスト、base/head、diff ハッシュ、パス、予定されている担当者／観点を指定して converge-reviews を呼び出します。一致する結果があれば、ディスパッチせずに再利用します。closure_check: available が返された場合は、指定されたブロッカー ID と変更箇所のみを対象に、的を絞ったチェックを 1 回ディスパッチします。記録済みのラウンドは変更せず、このチェックからの新しい指摘や対象範囲の拡大は却下します。その証拠と更新後のブロッカーの判定を converge-reviews に渡し、closure_check: passed | failed とともに新しい結果を保存してから、その結果を適用します。チェックが成功した場合は converged となることがあります。失敗した場合は、現在のラウンドで blocked-at-cap のままとします。初回の結果が continue の場合は、指定された無効化済みの対象範囲のみをレビューします。それ以外の結果では、新たなラウンドを開始せずに適用します。

共有パッケージのリポジトリマップを計算する（Q6 用）

CROSS_REPO_MODE=true の場合は、${CLAUDE_SKILL_DIR}/references/repo-map.md を読み込み、クロスリポジトリ用ブロックを無条件に実行します。判断基準は対象リポジトリの構成であり、ローカルの cwd ではありません。それ以外の場合、packages/ または apps/ が存在すれば、${CLAUDE_SKILL_DIR}/references/repo-map.md を読み込み、現在のモードに対応するブロックを実行します。このファイルには、両方のシェルブロック（クロスリポジトリ用の gh api によるツリー取得と、ローカル用の bash -c による find/grep の組み合わせがあり、いずれも 500 行で切り詰めます）が含まれ、サブエージェントのプロンプトに使う repo_map_files と repo_map_exports をステージングされた repo-map.md に書き込みます。このシェルの唯一のコピーであり、/fix-pr-review と共有しています。

ローカルモードでどちらのディレクトリも存在しない場合は、シェルをスキップします。両方を N/A (not a monorepo) に設定し、IS_MONOREPO=false を設定します。サブエージェント 1 は、変更されたファイルのディレクトリ、またはそこから何も見つからない場合はリポジトリのルートに grep の対象を切り替えます。src/ があると決めつけてはいけません。

エラーハンドリングへの変更を確認する（Phase 2 用フラグ）

差分の内容から、追加または変更された行にあるエラーハンドリングのパターンを grep します。

try \{ | catch \( | catch \{ | throw new | throw \s | \.catch\( | Result< | rescue | err := | raise

いずれかのパターンが見つかった場合、またはユーザーがエラーハンドリングに言及した場合は、INCLUDE_SILENT_FAILURE_HUNTER = true に設定します。

新しいデータベーステーブルを確認する（Phase 2 用フラグ）

差分の内容から、追加された行を grep します。

pgTable\( | createTable\( | CREATE TABLE | knex\.schema\.createTable | Schema\.create\(

いずれかのパターンが見つかった場合は、INCLUDE_SCHEMA_CHECKS = true に設定します。また、SCHEMA_DIR も抽出します。一般的な値は db/schema/、drizzle/schema/、src/schema/、migrations/ です。特定できない場合は、SCHEMA_DIR = "." に設定し、Q7-Q9 の grep をテーブル定義パターンに一致するファイルに限定します。たとえば、Grep("pgTable", ".", glob: "**/*.ts") のようにします。

クロスリポジトリモードでは、ファイル一覧の取得に gh api git/trees/<head-sha>?recursive=1 を使用します。Q7-Q9 の読み取りには gh api repos/<owner>/<repo>/contents/<path>?ref=<head-sha> を使用します。

プロジェクトレベルのレビュー抑制を読み込む

ベースリビジョンで読み込み、ワークツリーでは読み込まないでください。チェックアウトした PR が自身のレビューを抑制してはなりません。

SUPPRESSIONS_FILE=".claude/review-suppressions.yml"
SUPPRESSIONS=$(git show "$PINNED_BASE_OID:$SUPPRESSIONS_FILE" 2>/dev/null || { git fetch --no-tags origin "$BASE_REF_NAME" 2>/dev/null; git show "$PINNED_BASE_OID:$SUPPRESSIONS_FILE" 2>/dev/null; } || true)

ベースにそのようなファイルがない場合は、SUPPRESSIONS = "" に設定し、PR で追加された抑制ファイルを無視したことを記録します。PR では、マージ後のレビューに向けて抑制を提案できますが、自身のレビューを抑制することはできません。

スキーマ：

suppressions:
  - pattern: "factory pattern"
    category: Architecture
    reason: "YAGNI - single provider by design"
    added: 2026-04-13
  - pattern: "missing timeout"
    file: "claude-code.ts"
    reason: "Timeout handled at caller level"

pattern は必須です。検出結果の Issue テキストに対して、大文字と小文字を区別せずに一致します。category と file は任意で、抑制の適用範囲を指定します。reason は必須で、監査可能性のため「Filtered Out」に表示されます。

ファイルが存在する場合は、「レビュー抑制：このプロジェクトがすでに受け入れたパターン。スキップする」としてサブエージェント 1 のプロンプトに渡します。Phase 3 のステップ 5.5 でもセーフティネットとして適用します。

クロスリポジトリモードでは、gh api repos/<owner>/<repo>/contents/.claude/review-suppressions.yml?ref=$PINNED_BASE_OID を使って取得します。404 の場合はスキップします。ピン留めされたベース OID は信頼できますが、PR のヘッドは信頼できません。そのため、PR が自身のレビューを抑制することはできません。

引き継ぎファイルをステージングする

サブエージェントは差分を取得せず、貼り付けられたコンテキストも受け取りません。Phase 1 の最後に、$STATE_FILE の隣にある PR ごとのサブディレクトリに、以下のファイルを書き込みます。ディレクトリ名は .yml を除いた状態ファイル名とし、バッチモードでは同時に実行される各フローでディレクトリを共有します。diff.full.patch（ハンター、横断的レビュアー、V3 用の完全な差分）、diff.chunk-N.patch（ファイルごとに分割したチャンク単位の差分。チャンクモードのみ）、repo-map.md（上記ステップで作成したリポジトリマップ）、timeline.md（意図モデルと、それまでのタイムラインおよびクローズ済みの指摘）です。サブエージェントに gh pr diff の実行を指示するプロンプトはありません。プロンプトにはファイルパスと、短いインラインの意図が含まれます。

---

Phase 2：レビュアーのサブエージェント

SIZE_MODE に応じて、複数の Agent ツール呼び出しを1 つのメッセージで起動します。レビュアーのサブエージェントはここで一度だけ起動し、Phase 3 の検証担当はそこで一度だけ起動します。これでレビューは完了です。PR をもう一度確認する必要がある場合は、新たに /review-pr を実行してください。この実行中に再度ディスパッチしてはいけません。

ディスパッチ戦略

SIZE_MODE == "parallel-standard"（500 行以下、デフォルト）：

• Subagent 1（Claude レビュアー）と、条件に応じて Subagent 2（サイレント失敗ハンター）を並行してディスパッチします。Subagent 1 は diff.full.patch を読み、両方が repo-map.md と timeline.md を読みます。

SIZE_MODE == "parallel-chunked"（500 行超）：

• 小さなインラインの意図説明と、そのチャンクファイル、repo-map.md、timeline.md を渡して、チャンクごとに Subagent 1 を 1 つディスパッチします。プロンプト：「あなたの対象範囲は上記のファイルです。 のみを読んでください。他のファイルに関する指摘は報告しないでください。」
• PR 全体を対象に、サイレント失敗ハンターを 1 つ、横断レビュー担当を 1 つディスパッチします。どちらも diff.full.patch を読みます。チャンクレビュアーはそれぞれのチャンク内のみを報告するため、2 つのチャンクにまたがる不具合の種類を確認できるレビュアーは Subagent 3 だけです。これがなければ、その種類の不具合は直接カスケードに流れ込みます。
• 必ずチャンク分割した並行レビューを実施してください。規模にかかわらず、確認を求めてはいけません。

劣化モードのルール

サブエージェントのいずれかがエラーになったり、空の結果を返したりした場合は、残りのサブエージェントで続行し、Phase 4 の出力ヘッダーに <reviewer> unavailable と記載します。すべて失敗した場合にのみ中止します。

CodeRabbit に関する注記。 CodeRabbit の指摘は、リポジトリに .coderabbit.yaml がある場合、Phase 1 で PR の既存コメントから取得される前回レビューのタイムラインを通じて届きます。上記の一度限りのヒントを参照してください。CodeRabbit のサブエージェントはディスパッチしません。PR の最新コミットに CodeRabbit のコメントがまだない場合は、Subagent 1 が対応し、次のラウンドで CodeRabbit の情報を取り込みます。

Subagent 1：Claude レビュアー（general-purpose）

${CLAUDE_SKILL_DIR}/references/dispatch-prompts.md に従って <SKILL_DIR>、共有の前置き、グラウンドトゥルースのブロックを置き換え、このディスパッチ時に ${CLAUDE_SKILL_DIR}/references/reviewer-prompt.md を読み込みます。各ディスパッチでは、Phase 1 の最後に示されたステージ済みファイルパスを指定します。

Subagent 2（条件付き）：サイレント失敗ハンター

INCLUDE_SILENT_FAILURE_HUNTER = true の場合にのみディスパッチします。

• subagent_type：pr-review-toolkit:silent-failure-hunter

コンテキストパケットはコメントとして添えるものではなく、プロンプトの一部です。${CLAUDE_SKILL_DIR}/references/dispatch-prompts.md の ### Subagent 2 (conditional) パケットを、<GROUND_TRUTH> を置き換えたうえで、そのままディスパッチします。URL だけを渡された場合、このサブエージェントは PR の目的も、以前のラウンドで解決済みの問題も把握できず、解決済みの問題を再発見する一方で、残りを見落とします。

Subagent 3（条件付き）：横断レビュー担当

SIZE_MODE が parallel-chunked の場合にディスパッチします。それ以外ではスキップします。 チャンク分割しないモードでは、Subagent 1 がすでにすべてのファイルを確認します。

• subagent_type：general-purpose
• 対象範囲：PR 全体。ファイル間をまたいだ報告が許可されているレビュアーはこれだけです。

プロンプトは ${CLAUDE_SKILL_DIR}/references/cross-cutting-prompt.md にあります。このディスパッチ時に読み込みます。

フェーズ 3：批評パス（メインコンテキスト）

批評パスは常に実行されます。レビュアーのプロンプトが見落とす粗を検出します。これを経ていない指摘を出力、投稿、永続化するブランチはありません。

すべてのサブエージェントが戻った後、メインの Claude が批評パスを実行し、作業を次のように分けます。

• 判断はメインで行います。 重複排除、3 要素テスト、誤検出ルール、抑制、ランク付け、判定です。これらには意図モデルと過去のレビューの履歴が必要で、メインはすでにそれらを保持しています。サブエージェントに任せると、そのすべてを再送することになります。
• 証拠の収集はサブエージェントに任せます。 リポジトリの grep、呼び出し元の列挙、または HEAD 時点でのファイルの再読込を伴う作業です。これらはコードベースに比例してコンテキストを消費し、判定の数行を返します。メインが保持すべきなのは検索ではなく、判定です。

手順 4.55、4.9、6 では、${CLAUDE_SKILL_DIR}/references/verification-subagents.md に従ってサブエージェントをディスパッチします。これらの手順のうち最初に条件を満たした時点でファイルを読み込み、残りの手順でも使用します。3 つのディスパッチは 1 つのメッセージで行います。いずれも条件を満たさない場合、このファイルは不要です。 それ以外はすべてインラインで実行します。検証サブエージェントは、簡潔で構造化された判定として証拠を報告します。重大度、却下、状態ファイルについて判断するのはメインです。

次の順序で実行します。 手順 1 から 4.56 は ${CLAUDE_SKILL_DIR}/references/critic-verify.md に従って実行します。手順 1 で読み込み、手順 4.56 まで使用します。その後、手順 6 で、4.55 と 4.56 を通じて戻された指摘を処理するために再度読み込みます。手順 4.9、4.95、4.96 は ${CLAUDE_SKILL_DIR}/references/critic-round2.md に従って実行します。これはラウンド 2 以降でのみ読み込みます。

1. 重複排除

参照ドキュメントに従い、レビュー担当者間および 1 つの出力内で、同じ問題を説明する指摘を統合します。同じファイル、行、シンボルを指している場合は、カテゴリにかかわらず重複とみなします。

1.5. 低コストの行数チェック

判定に労力をかける前に、参照ドキュメントに従い、存在し得ない引用行を除外します。

2. file:line を検証

参照ドキュメントに従い、すべての参照を保存済みの diff と照合します。変更後の側のみが対象です。

3. 既知の指摘を除外

Category: Prior-finding-correction が付いている場合を除き、フェーズ 1 ですでに報告されたものをすべて除外します（参照ドキュメントに従います）。作成者がスレッドに回答済みの指摘は、新しいコミットでそのコードが変更されていなくても除外したままにします。

4. 3 要素テストで検証

次の 3 つすべてに該当する場合に限り、指摘を除外します。表面的な変更である、動作に影響しない、リファクタリングが不要である、の 3 つです。どれか 1 つでも該当しなければ、指摘を残します。除外した指摘は noise / 3-prong test として記録します。

4.5. 再利用性監査の検証

新しい定義の数を数え、reusability_searches: 監査（欠落、センチネル、またはエントリ）を解析し、参照ドキュメントに従ってすべての除外を記録します。

4.55. クラス完全性の検証

参照ドキュメントに従って、コード変更に関するすべての指摘について、V1 を通じて同種の箇所を網羅的に調べます。この手順に入った指摘はすべて、対象範囲を広げて出力し、空でない Class-sites を付けます。

4.56. 逆リスクの検証

すべての Suggested fix: について、Inverse risk: を導出するか、妥当性を確認します。/fix-pr-review はこれらをそのまま実装するため、検証されていない修正案が本番コードになります。

4.6. 誤検出ルール表を適用

ルール表に対して統一イテレーターを実行します。各ルールには、id、trigger（Issue または Why に対して正規表現で照合）、evidence_check（evidence_present | evidence_absent | inapplicable を返す呼び出し可能な関数）、action（drop / downgrade-1 / downgrade-1-and-note）があります。

各ルールを順番に適用します。該当するたびに、ルールの id と理由を「除外」に記録します。

ルール本体と、すべての trigger 正規表現および evidence_check の本体を含む 4 つのルールからなる YAML 表は、references/false-positive-rules.md にあります。手順 4.5 を通過した指摘が 1 つ以上ある場合はここで読み込み、指摘リストが空の場合は読み込みません。この表は誤検出のフィルタリングにおける唯一の信頼できる情報源です。新しい誤検出クラスの追加は、ここに YAML の行を 1 行追加するだけで済み、この説明に新しい文章セクションを追加する必要はありません。

4.9. 先回状態の抑制より前に実行する、回帰の先回りチェック（4.95）

CURRENT_ROUND == 1 の場合は完全にスキップします。2 回目以降のラウンドでは、${CLAUDE_SKILL_DIR}/references/critic-round2.md に従い、先回状態のすべてのエントリーをチェックします。ここで読み込んでください。判定がない場合はインラインで再チェックし、引き続きクローズ状態とは見なしません。

4.95. 先回状態の抑制を適用する（複数ラウンドの重複排除）

2 回目以降のラウンドでは、ステップ 4.9 で読み込んだリファレンスに従い、すでに対処済みの指摘を抑制します。すべての指摘には、必ず active、resolved、dismissed、wontfix、regression のいずれか 1 つだけを割り当てます。

4.96. 今回のラウンドの指摘に系譜を付与する

CURRENT_ROUND == 1 の場合は完全にスキップします。帰属させる先の以前の修正がないため、すべての指摘に caused_by: null を設定します。2 回目以降のラウンドでは、ステップ 4.9 で読み込んだリファレンスに従い、新規指摘の系譜を 1 ホップで付与します。上限はステップ 4.9 と同じです。ステップ 7.5 では解決可能なリンクのみを数えます。ぶら下がり ID は references/finding-state-schema.md（caused_by のカーディナリティ）に従って除外します。

5. 信頼度に基づく除外

信頼度が「低」の指摘は、「中」または「軽微」の場合すべて除外します。low-confidence filler として記録します。信頼度が低くても、「重大」または「深刻」の指摘は残してください。人間は、リスクが高く不確実なフラグを求めています。

5.5. プロジェクトレベルの抑制を適用する

Phase 1 で SUPPRESSIONS を読み込んでいる場合、残りの各指摘を照合します。

1. Issue のテキストに pattern が含まれているか確認します（大文字と小文字を区別しない部分文字列）。
2. category が設定されている場合、指摘の Category が完全一致するかも確認します。
3. file が設定されている場合、指摘の File パスにその文字列が含まれているかも確認します。

指定された条件がすべて一致する場合は、除外し、suppressed by .claude/review-suppressions.yml: "<reason>" (pattern: "<pattern>") として記録します。

重大／深刻の指摘への上書き：抑制は、どの深刻度の指摘も除外します。パターンを許容するとチームが明示的に判断した場合、その判断はレビューより優先されます。また、reason によって除外を監査可能に保ちます。

6. 抜け漏れチェック（Q1-Q6。スキーマ PR の場合は Q7-Q9）

サブエージェント 1 が何も指摘しなかった質問カテゴリについて、差分にそのカテゴリに該当するものがないか簡潔に検討します。見落としに気づいた場合は、指摘を追加します。INCLUDE_SCHEMA_CHECKS = true の場合に限り、Q7-Q9 も含めます。

大規模 PR の振り分け。 additions + deletions >= 500 で、メインが差分全体を把握できない場合、 このチェックを V3: Deep gap check に振り分け、その指摘をここに統合します。V3 には、メインがファイル一覧から推測するのとは異なり、差分自体に基づいて回答できるコンテキスト予算があります。V3 に INCLUDE_SCHEMA_CHECKS と SCHEMA_DIR を渡します。スキーマ変更が含まれる可能性が最も高い大規模 PR で、これを正確に実行します。そのため、このフラグを渡さないと、Q7-Q9 が最も該当しやすい状況で除外されてしまいます。

このステップで追加するすべての指摘に、カスケードゲートを再適用してください。 この振り分けには ${CLAUDE_SKILL_DIR}/references/critic-verify.md を再読み込みします。ここで作成した指摘は、メインによるものも V3 によるものも、ステップ 4.55、4.56、4.96 の実行後に追加されるため、Class-sites は空、Inverse risk も空で、振り分け直さない限り caused_by もありません。このステップで追加するすべての指摘を、次の手順に戻して処理します。

1. 3：回答済みのスレッドを含め、既知のものを除外します。
2. 4.55：クラス完全性チェックを実施し、Class-sites: <A>/<N> が空にならないようにします。V1 がすでに結果を返している場合は、2 回目の V1 を振り分けるのではなく、メインでインライン実行します。サブエージェント数の上限 4 は引き続き適用されます。
3. 4.56：逆リスクを導出し、すべての Suggested fix: に Inverse risk: が付くようにします。
4. 4.96：系譜を付与し、caused_by が設定されるか、明示的に null になるようにします。

どのステップで追加されたかにかかわらず、コード変更を提案する指摘にはすべて Inverse risk と Class-sites が必須です。これらを設定しない抜け漏れチェックの指摘は、状態ファイルに null を直接書き込み、次のラウンドの回帰チェックを機能不全にします。

7. 深刻度順に並べる

重大 > 深刻 > 中 > 軽微

7.5. cascade_share の計算

この比率を計算する箇所はここだけです。ランキングが完了し、指摘事項の集合が確定し、すべての指摘事項にステップ 4.9 または 4.96 の caused_by が付いているため、ここが数値を計算でき、かつ安定している最初の時点です。

CURRENT_ROUND == 1 の場合、割り当てる対象となる前のラウンドはありません。cascade_share = 0 に設定し、傾向を示す文をスキップして先に進みます。

ラウンド 2 以降：

cascade_share: <count of active findings with a resolvable caused_by> / <count of active findings>

caused_by は、対象の指摘事項がまだ存在する場合にのみカウントされます。ルールを定めている references/finding-state-schema.md（caused_by のカーディナリティ）に従い、参照先のない ID は除外します。

有効な指摘事項が 0 件の場合、ゼロ除算ではなく cascade_share = 0 とします。

下記のステップ 8 では、この値を判定理由の接頭辞に使用し、Phase 4 の Cascade check で出力します。どちらも再計算はしません。1 つの数値、1 つの定義、1 つのラウンドです。

8. 判定を決める

• 1 件以上の指摘事項が残っている → request-changes
• 残っている指摘事項がなく、未解決のブロッカーもない → approve
• 残っている指摘事項はないが、未解決のブロッカーが 1 件以上ある（Phase 1 の OPEN_BLOCKERS）→ ブロッカーとなっている未解決スレッドの経路で request-changes。重複排除によって再報告された指摘事項を除外したのは正しく、新しいスレッドは追加されません。レビューではイベントとともに本文のみを投稿し、本文にはすべてのブロッカーについて path:line（行番号のないファイル単位のスレッドでは path のみ）、投稿者、1 行の問題説明を記載します。セルフレビューでは、本文とターミナル出力に意味上の request-changes 判定を維持しつつ、同じ本文を COMMENT として投稿します。スレッドの網羅状況には 0/0 を表示し、その理由としてブロッカーとなっているスレッドの一覧を示します。

どのラウンドでも、cascade_share > 0.5 の場合は、判定理由の先頭に次の文を追加します。

このラウンドの指摘事項の半数以上は、前のラウンドで行われた修正によって生じました。 箇所ごとのパッチでは収束していません。このモジュールには設計の見直しが必要です。

9. シニアエンジニアの承認を決める

二択で評価します。

• いいえ：批評パス後に指摘事項が 1 件以上残っている、または未解決のブロッカーが 1 件以上ある、または Q1 で意図の不足が特定された
• はい：それ以外

最も重要な指摘事項、または指摘事項がないことに基づき、承認理由を 1 文で記述します。作成した文章には em ダッシュも en ダッシュも含めません。Issue または diff から引用したテキストは、見つけたままの状態にします。

---

Phase 4：出力

Phase 4 のすべての経路は、main が GitHub レビューを送信し、ローカルの状態を書き戻した後、Convergence handoff に進みます。

必ずこのブロックをターミナルに出力する

# PR Review: <title> (#<number>)

**Senior engineer approval**: <emoji> <Yes | No>, <one-sentence reason>
**Verdict**: <emoji> <approve | request-changes>
**GitHub event**: <APPROVE | REQUEST_CHANGES | COMMENT; use COMMENT when IS_SELF_REVIEW=true>
**Goal**: <intent goal>
**Size**: <additions>/<deletions> across <N> files
**Reviewers**: <list, with "(unavailable)" marker for any failed subagent>
**Round**: <CURRENT_ROUND> (<active>/<resolved>/<dismissed> findings carried across rounds)
**Convergence**: <N> new · <C> caused by earlier fixes · <R> regressions reopened · <F> carried
**Thread coverage**: <threaded>/<surviving> findings as review threads<; reason when below full>
<trend line, omit at round 1>
**Review URL**: <https://github.com/<owner>/<repo>/pull/<number>#pullrequestreview-<REVIEW_DB_ID> | <same URL> (pending draft) | not posted (<reason>)>

## Summary
<2-3 sentence summary>

## Findings (<count>)

### Critical
<entries>

### Serious
<entries>

### Moderate
<entries>

### Minor
<entries>

## Filtered out (<count>)
<dropped findings with reasons, for auditability>

## Multi-round status
<for each finding in PRIOR_STATE: id, file, status, round_resolved/dismissed, dismissal_reason. Useful for "did I really ship M3 in round 5?" scanning.>

判定と承認の絵文字マッピング

シニアエンジニアの承認：はい → ✅ · いいえ → ❌ 判定：approve → ✅ · request-changes → ❌ 重大度ヘッダー：Critical → 🔴 · Serious → 🟠 · Moderate → 🟡 · Minor → 🔵

ターミナル出力には「Filtered out」を含める必要があります。批評で過剰にフィルタリングされた場合に表示します。PRIOR_STATE.findings が空でない場合は、複数ラウンドの状態も含めてください。

レビュー URL

投稿または復旧の処理が完了した後、ヘッダーブロックの最後に必ず Review URL の行を出力し、ユーザーがワンクリックで送信済みのレビューを開けるようにします。照合済みのレビューのデータベース ID から URL を作成します。

REVIEW_URL="https://github.com/<owner>/<repo>/pull/<number>#pullrequestreview-<REVIEW_DB_ID>"

Phase C の新しいレビューの REVIEW_DB_ID、ローリング経路で再利用したレビューの PRIOR_REVIEW_DB_ID、またはモノリシック復旧の書き戻しで照合した ID を使用します。ユーザーが保留中のドラフトを維持する場合（「Show payload & keep draft」）、保留中のレビューの URL を (pending draft) の接尾辞付きで出力します。投稿が行われなかった場合（中止、ブロック、ローカル状態を維持）、URL の代わりに not posted (<reason>) を出力します。投稿前にブロックまたは中止された実行でも、理由を含めてブロックを出力します。

スレッドのカバレッジ

生き残った指摘に対するスレッド付き指摘を、投稿／復旧の結果が判明した後に出力します。この行には、予定していたペイロードではなく、その結果を記載します。行レベルとファイルレベルのスレッドはどちらもカウントします。本文フォールバックの指摘は、生き残った指摘としてカウントし、スレッド付きにはカウントしません。スレッド付きの数が生き残った数を下回る場合は、その理由を必ず記載してください。理由は、本文フォールバック、復旧フォールバック、フェーズのブロックまたは中断、あるいはスレッド付き投稿がまったくないこと（バッチサブエージェントの場合はオーケストレーターが投稿します）です。投稿前に実行がブロックまたは中断された場合も、その理由を添えてこの行を出力します。生き残った指摘がゼロの場合は 0/0 と出力します。

カスケードの確認

ラウンド 2 から必須です。ステップ 7.5 の値を出力してください。ここで再計算してはいけません。ステップ 8 では判定の接頭辞に同じ数値をすでに使用しており、異なる指摘セットで 2 回目の計算をすると両者が食い違うためです。

数値に基づいて、傾向を示す文を次から 1 つだけ出力してください。

• cascade_share > 0.5 → Not converging, because the fixes are generating the findings.
• 新しい指摘がラウンドごとに減少し、cascade_share == 0 → Converging, with the tail shrinking.
• 3 ラウンド以上にわたって新しい指摘数が横ばい → Stalled at the same volume each round; scope may be growing.

Convergence: 4 new · 3 caused by earlier fixes · 1 regression reopened · 2 carried
Trend: cascade_share 0.75. Not converging, because the fixes are generating the findings.

判定が以前の approve 評価を覆す場合は、その理由と 2 つの SHA を Summary に明記してください。他の作者の PR では、"I approved this at dd142e0. I'm reversing that, because e4f7432 made one thing worse than it was." と記載してください。セルフレビューでは、"I assessed this as approve at dd142e0. I'm reversing that, because e4f7432 made one thing worse than it was." と記載してください。

実行時間の計測（終了時）

PHASE_START_* のタイムスタンプから、合計経過時間とフェーズごとの経過時間を計算します。Filtered Out の前に追加してください。

## Timing
Phase 1: <s> (metadata + diff + intent + repo map + state load)
Phase 2: <s> wall / <sum> CPU (parallel: <N> subagents)
Phase 3: <s> (dedupe + verify + 3-prong + reusability audit + FP rules + prior-state + suppressions + gap + verdict)
Phase 4: <s>
Total:   <s>

GitHub への投稿

明示的な /review-pr <PR URL> の実行は、その PR に完全なレビューを送信するための新たな許可です。この許可が有効なのは、対象 PR、head SHA、意味上の判定、GitHub イベント、凍結済みペイロードが、後続の変更カードと一致している間に限られます。preflight-mutations を通常どおり適用し、ready 以外の判定ではブロックしてください。これを回避したり、指摘の選択、投稿の確認、レビューのローカル保存、本文の編集、次のアクションの選択をユーザーに求めたりしてはいけません。

• IS_SELF_REVIEW=false の場合、生き残った指摘をすべて個別のレビューコメントとして REQUEST_CHANGES とともに送信します。未解決のブロッカーがないクリーンなレビューは、レビューコメントなしで APPROVE とともに送信します。未解決のブロッカーがあるクリーンなレビューは、ブロック中の未解決スレッドの経路（フェーズ 3 のステップ 8）で送信します。
• IS_SELF_REVIEW=true の場合、同じ指摘一式、またはクリーンサマリーを COMMENT とともに送信します。本文とターミナル出力には、意味上の判定を記載してください。
• Filtered out のすべての項目は、ターミナル専用の監査出力として保持してください。フィルターで除外された項目は、GitHub ペイロードに含めてはいけません。
• 生き残った指摘はすべてレビュー用スレッドとして送信するか、Thread coverage の行で、送信されなかったこととその理由を明確に記載してください。ターミナルレポートを issue コメントとして貼り付けてはいけません。

${CLAUDE_SKILL_DIR}/references/github-posting.md を今すぐ読み込んでください。内容は、サマリー本文、指摘ごとのコメント、差分ハンクの検証、フェーズ A から C、書き戻しです。この PR に以前の /review-pr レビューまたはキャッシュエントリーがある場合は、${CLAUDE_SKILL_DIR}/references/github-posting-rerun.md も読み込んでください。投稿フェーズが失敗した場合は、${CLAUDE_SKILL_DIR}/references/github-posting-recovery.md も読み込んでください。

参照ファイルには、<owner>、<repo>、<pr-num>、<head_sha>、CURRENT_ROUND、IS_SELF_REVIEW、サマリー本文の内容、生き残った指摘の完全な一覧（行レベル＋ファイルレベル）、PRIOR_STATE（再実行ファイルのステップ 0c で照合します）、$CACHE_FILE のパス、$STATE_FILE のパス、および投稿許可の根拠となる /review-pr の実行を渡してください。

コンバージェンスへの引き継ぎ

権威ある投稿と書き戻しの後、PR リクエスト、ベース／現在のヘッドと差分ハッシュ、レビュー対象パス、レビュアー一覧と観点、現在の指摘事項と対応状況、および $STATE_FILE を指定して converge-reviews を呼び出します。結果の convergence ブロックを、review-pr の指摘事項の状態を置き換えずに、既存の状態ファイルへ保存します。次のレビューラウンドを推奨する前、またはレビューが収束したと宣言する前に、その結果の契約を適用します。

---

エラー処理

• gh がインストールされていない／認証されていない → 直ちに失敗します：Run 'gh auth login' and retry.
• PR URL が無効 → Couldn't parse PR URL. Expected: https://github.com/owner/repo/pull/NUMBER
• PR にアクセスできない（404／GraphQL エラー） → Couldn't access PR. Check repo access; try 'gh auth refresh -s repo'.
• PR がクローズ済み／マージ済み → 警告を表示しますが、続行します（事後レビュー）。
• PR がドラフト → 出力ヘッダーに記載して続行します。
• PR に変更がない → 早期終了します（フェーズ 1）。
• フェーズ 2 のサブエージェントが失敗 → 残りの処理を続行します。すべて失敗した場合に限り中止します。
• gh のネットワークエラー → 表面化させ、暗黙のフォールバックは行いません。
• レビューイベントの権限が拒否された → GitHub のエラーを表示して停止します。COMMENT を使用するのは、フェーズ 1 で IS_SELF_REVIEW=true と判定された場合のみです。権限エラーの後、別の作成者のレビューを格下げすることはありません。
• 状態ファイルへの書き込みに失敗 → 警告を記録しますが、投稿はブロックしません。状態ファイルへの永続化はベストエフォートです。