review-change

変更のレビュー

品質ゲート：該当するレビューをすべて実行し、該当しないものはスキップしてから、1 つのレポートに統合して分類します。指摘事項のみとし、編集やリファクタリングは行いません。

ターン契約

各ターンを終了する前に、正規のターン契約（11 個のチェック項目）を読み込み、検証してください。レシートのクローズアウト、分離ルール、適用可能性に関するスキル固有の追加事項は、この文書およびREVIEW_PROCESS.mdに記載されています。参照先が見つからない場合は、停止してください。

最終 PR レビューでは、次の追加チェック項目に合格するまでターンは完了しません。

✓ Decision: REVIEW-PASS + PR exists →
  `bun scripts/review-receipt.mjs emit --pr <N> --head "$(git rev-parse HEAD)" …`
  RUN and exited 0 — the script posts the SHA-bound comment, re-reads the PR
  comments, and exits non-zero unless the newest exact-HEAD
  `review-change:pass` marker is confirmed, so its exit code IS this box

レシートエミッターの実行時には、影響パスのスコープマニフェスト（fix/286）も記録されます。これにより、レビュー後の無関係な変更のみのコミット（共有チェックアウトでのセッションログまたはツール状態のコミット）によって、マージゲートでレシートが無効にならなくなります。--scope-base main（ユニットのベース参照）を渡してください。ランタイムがマニフェストを自動的に導出するため、ダイジェストを手作業で組み立てないでください。スコープマニフェストのないレシートは、ヘッドに紐づいたままです（従来の動作）。

レシートのクローズアウトはレポートの前提条件であり、後続の作業ではありません。終了コードが 0 以外の場合は、所定のレポートブロックを出力しないでください。最新のレシートがない場合、問題のないレポートで /audit-pr を推奨してはいけません。

REVIEW-FAIL または NEEDS-DECISION の場合は、未解決の指摘 ID をすべて終了時の推奨事項に列挙し、+ でつないでください。レビューで最初の指摘のみを引き継いではいけません。

レビュー終了時のターン境界

REVIEW-FAIL または NEEDS-DECISION の場合、このスキルはレポートの出力をもって終了します。/fold-findings、/execute-phase、/unit-lane、/triage-issue は呼び出しません。これらはユーザーが個別に開始する呼び出しであり、新しいターンで実行します（プログラムによる外側のドライバーは、REVIEW_PROCESS.md に従って同じ順序を 1 ターン内で構成できます）。レビューで行う変更は、台帳コミット（永続化ステップ 11）と、PR がある場合の REVIEW-PASS 時のレシートコメント（永続化ステップ 12）のみです。指摘の取り込み、フェーズの実行、コードの編集は行いません。REVIEW-FAIL／NEEDS-DECISION のターンは、レポートブロックが出力された時点で終了します（レポートステップ 13）。

内部の検証契約を使用してください。レビュー担当者は、候補エビデンスをマッピングする前に、実行者と同じ凍結済み受け入れ成果物（レガシー形式（feature 61 より前）の ACCEPTANCE.md、または feature 61 以降のユニット文書にある ## Acceptance criteria）を確認します。

使用する場面

• マージ前に必ず実施してください。 変更を実装していないコンテキストでレビューします。実装したコンテキストの場合は停止し、新しいコンテキストに引き継いでください。execute-phase は、レイヤー境界、蓄積、または機微性（#77）における任意のチェックポイントを推奨する場合もあります。
• 該当するレビューを、無関係なレビューを実施せずに行う場合に使用してください。

スコープ

デフォルトの対象は現在の変更（デフォルトブランチとの差分）です。スコープを広げる、または狭めるには、パスやグロブを指定してください。レポートの冒頭にスコープを記載してください。

レビューチャーター — 主張を崩す

このワークフローの役割は、機能するものが確かに機能し、しかも優れた形で機能することを、プログラム面、エンジニアリング面、意思決定面、そしてユーザーの期待に照らして実証することです。このレビューは、その主張を崩そうとするために行います。試みを乗り越えられたなら、それ自体がレビューの結果です。したがって、次のとおりです。

• 対象範囲内の欠陥は、このレビューで扱います。「対象外」にはしません。 現在の機能の対象範囲内にあるバグ、セキュリティ上の問題、またはガードのスキップは、review-change の指摘事項です。ひとつでもあれば、その機能は完成していません。目指すのはリリースではなく、受け入れ基準を満たすこと、過剰な設計を避けつつ適切なエンジニアリングを行うこと、他の機能の要件を満たすこと（認証が必要なページではセッションと権限の両方を確認すること、要件が依存する別のテーブルへの変更は、たとえ「対象外に見えても」対象範囲に含めること）、そして何よりユーザーの期待に応えることです。
• 推測せず、尋ねる — 期待の全範囲について。 計画、差分、または要件からユーザーの期待が明確でない場合は、技術的でない言葉で質問として提示します（技術に詳しいユーザーならアプリを求め、技術に詳しくないユーザーなら「心拍数を測るアプリ」を求めます）。意図を推測してはなりません。これは、受け入れ基準に対してだけでなく、変更の評価基準となるあらゆる期待に、「推測せず、尋ねる」という原則を適用するものです。
• リポジトリ全体を対象とした探索は、このレビューでは行いません。 リポジトリ全体にわたる範囲を定めないバグ探索、セキュリティ調査、壊れたバージョンの調査は、対象範囲と予算が定められた product-audit で行います。このレビューでは、目の前の変更に専念します。

ステップ 0 — プロジェクトと変更を把握する（必ず最初に行う）

ワークフローの規約とドキュメントマップに従って、次の点から対象軸を決めます。

1. プロジェクトの性質： UI（docs/frontend/）、Web／モバイル／CLI／ライブラリ／バックエンド、および任意で記録されたプラットフォームのスキル（追加要素のみ）。
2. 変更範囲： 差分が触れる領域（UI、API、インフラ、ドメイン）。軸が適用されるのは、プロジェクトと変更範囲の両方が該当する場合のみです。
3. 過去の指摘事項（任意の検索補助であり、正式な根拠ではありません）： インデックスのエントリーポイントがある場合、各パスの実行前に agentic-workflow doc --query "<change topic>" --json-only を使うと、同じ対象領域に関する過去の指摘事項、決定、セッションログのエントリーが見つかる場合があります。インデックスやエントリーポイントがない場合、または回答が空の場合でも、何も変わりません。網羅的なフォールバックとして grep を引き続き使用し、インデックスを判断の根拠にすることはありません。

適用マトリクス（デフォルト。プロジェクトのドキュメントにより詳細を定めます）

各軸は、ワークフロー独自の内部レビューパック（skills/review-* — ワークフローとともにインストールされるため、不足するものはありません）のスキルに対応します。

軸 — 内部パックのスキル	Web	モバイル	コンソール／CLI	Lib／SDK	バックエンド／インフラ
review-code（正確性、簡素化、デッドコード、重複、アーキテクチャ）	✓	✓	✓	✓	✓
review-security	✓	✓	✓	✓	✓
review-verify（実行し、実際の動作とテストを確認）	✓	✓	✓	✓	✓
review-design（UI／UX）	✓	✓	TUI のみ	✗	✗
review-a11y	✓	✓	まれ	✗	✗
review-brand（語調／コピー）	✓	✓	出力テキスト	✗	✗
review-perf	✓	✓	✓	✓	✓
review-seo	✓	✗	✗	✗	✗
API の使いやすさ／利用方法のドキュメント（インラインパス）	API がある場合	API がある場合	フラグ／ヘルプ	✓✓	✓

review-implementation（統合済みの表に対する単一の分類器 — プロセスのステップ 8）と review-debt（分類済みの表に対する負債の変換 — プロセスのステップ 9）は、対象軸を見つけるものではありません。軸ごとではなく、レビューごとに一度実行します。

隔離ルール（デフォルト — 敵対的レビューに限らず、毎回）

該当する各パス、検証パス（ステップ 6）、分類器（ステップ 8）、および負債変換（ステップ 9）は、 隔離された／コンテキストがクリーンな状態で実行し、固定形式の指摘テーブルと PASS | FAIL のみを返します。差分や文章は返しません。各パスにつき、新しいサブエージェントまたはヘッドレス実行を 1 つ起動してください。それらを使えない場合は、新しい会話を使用します。渡すのは対象範囲、チェックリスト、ステップ 0 のドキュメントのみです。差分を含まない全体読み込みは最大 10 回とし（対象を絞った 50 行以下の読み込み／grep は除外）、オーケストレーターが保持するのはソースではなくテーブルです。ステップ 7 でそれらを統合します。インラインのフォールバックでは、テーブルを順次まとめます。パスは、同等以上のティアで実行し、弱いティアでは実行しません。

段階的な読み込み — レビュールートを 1 つ選択

適用可能性と隔離を確立した後：

参照の許可リストは、以下にリンクされた 7 つのパスのみです。ほかの references/ パスを作成したり、読み込んだりしないでください。

呼び出しルート	この順序で読み込む	スキップ
デフォルトレビュー	レビュー手順 → 敵対的レビューの推奨事項 → 保存と判断 → 出力とガードレール	統合、移植性、敵対的レビューのセットアップ
--adversarial N	レビュー手順 → レビュアーの起動前に敵対的レビューのセットアップ → 統合前に敵対的レビューの統合 → 保存／判断 → 出力／ガードレール	移植性
--synthesize	レビュー手順 → 敵対的レビューの統合と提供されたレビュアーテーブル → 保存／判断 → 出力／ガードレール	敵対的レビューのセットアップ、移植性
従来の --merge	以下の固定された移行拒否メッセージを出力して停止 — git／forge の変更は一切行わない	すべて

従来の --merge は削除されており、エイリアスではありません。 /review-change --merge を呼び出すと、git または forge の変更コマンドが実行される前に、以下の固定された移行拒否メッセージを出力して停止します。

migration: --merge is removed. Table fusion is --synthesize: pass the fixed
reviewer tables the same way and the synthesis contract fuses them. No
repository merge is performed by this skill.

有効なレビューパスでは、--synthesize／統合に関する用語のみを使用します。コンテキスト、並列処理、スラッシュコマンド、またはティア制御が利用できない場合に限り、移植性を追加します。docs/workflow/REPOSITORY_STATE.md は出力／ガードレールの根拠資料であり、スキルの参照先ではありません。このルートでは NRS とアーキテクチャ不変条件のルールを扱います。

リソースはこのファイルから 1 階層先にあります。レビュアー／統合／出力の固定コントラクトはそのまま記載されています。必須リソースがない場合は停止し、レビューコントラクトを決して近似しないでください。

移植性

レビュアーのコンテキストは隔離してください。逐次／ヘッドレスのフォールバックには移植性を使用し、独立した敵対的レビューパスを決して統合しないでください。

他のスキルとの関係

内部の検出スキル（review-code、review-security、review-verify、review-design、review-a11y、review-brand、review-perf、review-seo）をオーケストレーションした後、1 つの review-implementation 分類器と review-debt 変換を実行します。デフォルトでは隔離されます。インストール済みのプラットフォームパックは任意です。triage-issue はユーザーが呼び出すもので、自動実行はされません（D3）。独立した提案、監査結果、および --prioritize-now の実行に使用します。これはステージ 4 です。チェックポイントレビューは任意ですが、最終レビューは必須であり、最新の状態で行います。fix-now はユニットのフォールドサイクルに回されます。別個の /fold-findings 呼び出しであり、このレビューでは実行しません。replan-in-unit はユーザーが確認したフェーズを追加し、独立した作業は提案になります。audit-pr が使用するのは検証済みの PR コメント受領記録のみであり、チャットレポートは使用しません。定期的な一括監査には product-audit を使用します。REVIEW-FAIL の場合、手動修正ルートは /fold-findings の後、変更された HEAD に対して /review-change を再実行することです（REVIEW_PROCESS.md に従い、最大 2 サイクルまで。ユーザーの明示的な指示がない限り、3 サイクル目は開始しません）。プログラムによる外部ドライバーで、同じレビュー→フォールドの順序を実行してもかまいません。

完了条件

• すべての該当する軸を網羅し、スキップした軸とその理由を記載し、手動確認も含めた、統合・分類済みの表が1つあること。すべての指摘に対応先があり、統合、確認済みの再計画フェーズ、提示された判断事項、またはユーザーへの提案のいずれかに割り当てられていること。何もひそかに失われず、レビューによってバックログが発生しないこと（D3）。締めくくりの→ Next:ブロックを出力すること（問題なし → /audit-pr、繰り返されるドリフト → /product-audit）。コードは変更しないこと。