why-review

Codex 互換性に関する注意：

• Codex でリポジトリのスキルを呼び出すには、$skill-name を使用します。このミラー版では、従来の Claude の /skill-name 参照を置き換えています。
• タスクトラッカーの必須事項：ワークフローまたはスキルの手順を実行する前に、すべての手順についてタスクの追跡情報を作成または更新し、進捗の変化に合わせて同期してください。
• ユーザーへの質問を促すプロンプトは、Codex でユーザーに直接質問することを意味します。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳格な実行規約：ユーザーがスキルを明示的に呼び出した場合は、記載どおりにそのスキルのプロトコルを実行してください。
• サブエージェントの承認：スキルがユーザーによって呼び出された場合、または AI によって検出された場合に、そのプロトコルでサブエージェントが必要とされるなら、そのスキルの有効化により、そのタスクで必要な spawn_agent サブエージェントを使用することが承認されます。
• ユーザーが事前に逸脱を明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
• ワークフロースキルでは、列挙された子スキルの各手順を明示的に実行し、手順ごとに根拠を示してください。
• 必須の手順またはツールをこの環境で実行できない場合は、対応方法を変更する前に停止し、ユーザーに確認してください。

Codex のプロジェクト参照の読み込み（フックなし）

Codex では、実行時にプロジェクト文書を注入する代わりに、静的なプロジェクト参照を読み込みます。 コーディング、計画、デバッグ、テスト、レビューを行う際は、以下の経路に従ってプロジェクト文書を明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフローとテストの設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体への案内）
• docs/project-reference/lessons.md（常時適用されるガードレールとアンチパターン）

コンテキストがない、または古い場合の経路： docs/project-config.json、ドキュメントのインデックス、lessons.md、CLAUDE.md、AGENTS.md、またはタスクに必要な参照文書が存在しないか古い場合は、プロジェクト固有の通常作業を始める前に、$project-init または限定的なセットアップ経路（$project-config、$docs-init、$scan-all、$scan --target=<key>、$claude-md-init）を自動的に実行してください。Codex のミラーまたは AGENTS.md が存在しないか古い場合は、ユーザーに $sync-codex の実行を依頼してください。自動実行はしないでください。

状況に応じて読む文書：

• プロジェクトの構造／アーキテクチャ／技術スタック／デプロイ／セットアップ（バックエンド、フロントエンド、インフラのいずれの層でも）：project-structure-reference.md
• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様書の作成、docs/specs/ のパス指定、または TC 形式：feature-spec-reference.md、spec-system-reference.md、spec-principles.md
• 振る舞い／公開契約の変更、または仕様書・テスト・コード間の同期：workflow-spec-test-code-cycle-reference.md と上記の仕様書関連文書
• 派生仕様インデックス／ERD／再実装ガイド：spec-system-reference.md および docs/specs/ 内の元となる Feature Specs
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査：code-review-rules.md と、変更対象のファイルに応じたドメイン文書

すべての文書を無差別に読まないでください。まず docs-index-reference.md を確認し、そこからタスクに関連するファイルだけを開いてください。

[目標の再確認 — 必ず注意すること]

すべてのレビュー対象について、妥当性、正確性、根拠の裏付け、ベストプラクティスとの整合性を確保してください。 すべての決定と推奨について、必ず3つのトレードオフに関する質問をしてください。：(1) トレードオフはありますか？ — 何を犠牲にするのかを明示してください。「なし」は未完了の分析であり、答えではありません。(2) それだけの価値がありますか？ — 利益とコスト、誰が負担するのか、いつ負担するのかを比べてください → WORTH IT / NOT WORTH IT / UNCLEAR。(3) ユーザーに確認する必要があるほど重大なトレードオフですか？ — 元に戻せない、コストを他者に転嫁する、ある品質特性を別の品質特性と引き換えにする、境界を越える、重大な結果につながる経路、または UNCLEAR のいずれかに該当する場合 → STOP し、結論を出す前にユーザーへ直接確認してください。重大なトレードオフを決して黙って決着させないでください。理由：代償を示さずに利点を挙げるのはレビューではなく推奨です。一度きりの決断を下すかどうかはユーザーが決めることであり、あなたが決めることではありません。 必須の第2パス（フルモード）： 第1ラウンドで何らかの指摘事項が1つでも見つかった場合、引き継ぐ前に、その指摘事項がそれぞれ正確かつ妥当であることを確認するため、$why-review --validate-findings を2回目として必ず実行してください。決して省略せず、これを避けるために指摘事項を隠したり、格下げしたり、過少報告したりしないでください。フルモードで最初に実行するアクションとして設定される自己再帰的なレビューループ — 主にプロトコルループ（ホストに依存しない）と、利用可能な場合の /goal Stop-hook ゲート — により、指摘事項が検証されるまで終了できません。理由：検証されていない指摘事項は、裏付けのない主張です。また、2回目の自己レビューにより、第1ラウンドで合理化された誤読や誇張を見つけられます。

[ブロッキング] 宣言された順序どおりにスキルの手順を実行してください。ユーザーの明示的な承認なしに、手順を省略、並べ替え、統合してはなりません。 [ブロッキング] 各手順またはサブスキルを呼び出す前に、タスクの追跡情報を更新してください。手順の開始時に in_progress、終了時に completed を設定してください。 [ブロッキング] 完了またはスキップした手順には、必ず簡潔な根拠または明示的なスキップ理由を含めてください。 [ブロッキング] Task ツールを使用できない場合は、同じステータス遷移を持つ同等の手順別プラン追跡情報を作成し、維持してください。

クイックサマリー

目標： 要求されたレビュー対象を解決し、該当する敵対的レビューの経路（プラン／PBI の根拠、コード変更、ドキュメント／仕様／レポート、指摘事項、または明示的な成果物）を適用します。これにより、後続の作業に進む前に、決定、指摘事項、プランが敵対的な根拠レビューに耐えられるようにします。

概要：（ほかを読む時間がない場合の要約 — このスキルの目的とすべての主要手順）

• 目的 — 敵対的な根拠レビュー担当として、あらゆる計画／PBI／差分／ドキュメント／仕様／レポート／指摘事項が、後続作業に進む前に懐疑的な観点で検証されるようにします。成功指標は変更容易性（将来の変更コストを下げるか、却下すること）です。すべての指摘事項に file:line ＋重大度＋確信度を必須とします。
• ステップ 1 — まずモードを検出する（再帰制御）：--validate-findings は終端モードです。$why-review を再呼び出しせず、ゲートを実行せず、サブエージェントを起動しません。フルモードでは、検証指摘事項モードで自分自身を 1 回だけ呼び出せます。これは譲れないガードです。理由：終端モードでこれらのいずれかを実行すると、無限ループになります。
• ステップ 2 — フルモードで最初に行うこと → 自己再帰レビューのループを確立します。プロトコルループは、ホストに依存しない主要な確立方法です（レビュー → 検証 → 調整 → 新たな指摘事項なしで CLEAN になるまでフルレビューを再実施します。やり直しは最大 2 回で、その後はエスカレーションします）。/goal ゲートは利用可能な場合に呼び出す任意の高速化手段です（利用できなくてもループが弱まることはありません）。終端モードでは決して確立しません。「自己修正」とは、このレビュー自身の指摘事項セットを調整することであり、コードを修正することではありません。次にタスクを初期化します。フェーズタスクと、必須の「指摘事項検証ゲート」完了タスクを作成します。
• ステップ 3 — レビュー前に対象の種類を解決する（コミット／PR／差分 → コード変更、PBI／仕様／ドキュメント → 成果物。「有効な計画なし」は、未解決の計画根拠に関する依頼に限ります。黙って別の種類に変換してはいけません）。有効な目標契約を読み、懸念事項に応じて振り分けます（コードレビュアー／セキュリティ監査者／パフォーマンス最適化担当／汎用）。対象に統合テストが含まれる場合は、統合テストレビュアーとの連携を適用します（$integration-test-review の 8 つのゲートを読むか、単独のフルモードでは委任します）。その 4 行の再帰ガードに該当する場合はスキップします。
• ステップ 4 — 懐疑的な立場でレビューする → 反バイアスゲートの 7 項目すべてに対応します（却下した代替案を最善の形で捉える · 見落とした代替案 · 反対意見 · 前提への負荷検証 · 事前検死 · 長所と短所の対称性 · トレードオフの精査ゲート）。さらに検証チェックリスト（項目の有無と品質・深度）と第 2 ラウンドの再レビューを実施し、仕様↔テスト↔コードを照合します。いずれかの間に不一致があれば指摘事項とします。存在することだけでは、決して合格になりません。
• トレードオフゲート — あなたが行うすべての判断と推奨事項について、必ず確認すること： (1) トレードオフはあるか？ 犠牲になるものを明示します。「ない」は分析未完了を意味するため、確認した観点を記載します。(2) そのトレードオフに見合う価値はあるか？ 得られるものとコスト、誰が負担するか、いつ発生するかを比較し、価値あり／価値なし／不明確のいずれかを示します。(3) ユーザーに確認するほど重要か？ 不可逆 · 他の場所へのコスト転嫁 · 品質特性の犠牲 · 境界の超過 · 重大な影響を及ぼす経路 · 不明確に該当する場合は、停止して判定を下す前に、ユーザーに直接質問し確認します。Trade-Off Assessment 表を出力します。重要なトレードオフが未確認の場合、決して合格にしてはいけません。
• ステップ 5 — 自分自身の指摘事項に対する指摘事項検証ゲート（重大度を問わず）：終端の --validate-findings を再呼び出して調整し、新たな指摘事項なしで CLEAN になるまでフルレビューをやり直します（最大 2 回）。その後、次のステップをユーザーに直接尋ねます（条件に応じて $llm-council を利用）。二重フィードバック：動作を変える指摘事項には、仕様との乖離に関する判定（CODE-WRONG／SPEC-STALE／AMBIGUOUS／SPEC-SILENT／in-sync）とテストフィードバックの対応の両方が必要です。SPEC-SILENT の場合は §4 BR／§3 AC ＋ §8 TC の充実も必須です。いずれかの軸が欠けていれば HAS-ISSUES であり、決してクリーンではありません。

ワークフロー： モード／対象を検出 → （フルモードのみ）自己再帰レビューのループを確立（プロトコルを主要手段とし、利用可能な場合は /goal による高速化も使用） → パス／ドキュメント／グラフ／サブエージェントの焦点を振り分け → レビューの観点／敵対的ゲート／変更容易性を確認 → 終端の --validate-findings で指摘事項を検証 → CLEAN で新たな指摘事項がなくなるまで調整して全体的なフルレビューを再実施（やり直しは最大 2 回） → フルモードでは次のステップを尋ねる。 重要なルール： レビューの前に、必ず対象の種類を特定してください。すべての指摘には、必ず file:line、重大度、確信度、ベストプラクティスに基づく根拠を記載してください。あらゆる決定と推奨事項について、必ず3つのトレードオフに関する質問をしてください（トレードオフはあるか？ その価値はあるか？ 重要か → ユーザーに確認する）。検討せずに「トレードオフはない」と判断してはいけません。重要なトレードオフを黙って決めてはいけません。未解決の計画根拠に関する要求を除き、「アクティブな計画はありません」と言ってはいけません。validate-findings から $why-review を呼び出してはいけません。必ず変更容易性を基準に判断してください。将来の変更コストが下がらない場合は、却下してください。

ミッション

$ARGUMENTS

レビューモード（最初に検出 — 再帰制御）

レビュー作業に入る前に、$ARGUMENTS からモードを検出してください。

モード	$ARGUMENTS 内のトリガー	実行内容	再帰
full（デフォルト）	validate-findings トークンがない	完全な設計根拠レビュー（以下の検証チェックリストと敵対的ラウンド）を実施し、その後、指摘検証ゲートとして終了タスクを実行します。このゲートでは、独自の指摘に対して validate-findings モードでこのスキルを再度呼び出します。	同じセッション内で、validate-findings モードに1回だけ自分自身を呼び出せます。
validate-findings	$ARGUMENTS に --validate-findings / mode=validate-findings / validate findings in が含まれる	提供された指摘／レポートに対して指摘検証ルーチンのみを実行します。各指摘が正確で、証拠に裏付けられ、妥当で、ベストプラクティスに沿っているかを検証し、見落とされた改善点を明らかにして、CLEAN / HAS-ISSUES の判定を出します。	**終端 — $why-review を呼び出さず、ゲートも実行せず、サブエージェントも起動しません。**再帰を停止します。

再帰ガード（絶対遵守）： validate-findings は終端モードです。無限再帰を防ぐため、$why-review または検証ゲートを呼び出してはいけません。やり直しループは呼び出し元にあり、同じメインエージェントのセッション内で最大2回まで実行します。サブエージェントは起動しません。

validate-findings モードでは： 完全な検証チェックリスト、敵対的ラウンド、タスクの初期化、次のステップの協議ゲートをスキップします。指摘検証ルーチンに直接進み、判定を出して呼び出し元に戻ります。

自己再帰型レビュー ループの設定（フルモード — モード検出後の最初のアクション。プロトコル優先、「/goal」は任意）

必ず注意してください： フルモードのみ、モード検出後の最初のアクションとして、タスクの初期化やレビュー作業を行う前に、このスキルの自己再帰型レビュー ループを設定してください。これにより、このレビューで見つかったすべての指摘事項が検証され、全体を再レビューして新たな指摘事項が見つからなくなるか、上限付きのエスカレーションが発生するまで、作業を停止できなくなります。このループは2つの層で設定されます。プロトコル ループ（主要、ホストに依存しない）と、任意の「/goal」アクセラレーターです。正しさはプロトコル ループによって担保されます。フックやコマンドはアクセラレーターにすぎないというのがプロジェクトのルールであるため、「/goal」がなくてもループの強制力は決して弱まりません。

開始条件：

• フルモードで実行します（「validate-findings」トークンがないこと）。
• 終端モードの「validate-findings」ではスキップします。このモードは呼び出し元に判定結果を返すだけのため、ループの設定、ゴールの設定、終了タスクの作成、ループを行ってはいけません（再帰防止）。何も記録しません。

1. プロトコル ループ — 常に設定します（フック／コマンドに依存しません）。 実行中のエージェントであるあなたには、ループが収束するか、上限付きでエスカレーションされるまで停止しない責任があります。「/goal」が利用可能かどうかにかかわらず、Claude、Codex、Copilotのすべてに適用されます。

対象全体に対して完全な敵対的レビュー（検証チェックリストと2回の敵対的ラウンド）を実施する → 指摘事項に対して「$why-review --validate-findings」を実行する → 整合性を取る（証明されていない／誇張された指摘を削除し、証明の不足を補い、新たに見つかった指摘事項／改善点を追加する） → 整合性を取った指摘事項と組み合わせ、対象全体に対して完全なレビューを再実行する（変更された指摘事項の再確認だけではありません） → 完全なレビューで新たな指摘事項がゼロとなり、検証結果がCLEANになるまで、または上限付きの阻害要因がエスカレーションされるまで繰り返します。やり直しは最大2ラウンドまでとし、その後はユーザーに直接尋ねてエスカレーションします。未検証の指摘事項が残っている場合や、再レビューで新たな指摘事項が見つかる可能性がある場合は、停止してはいけません。

これは、指摘事項の検証ゲートで読み返す継続的な責務として扱ってください。最初のレビュー後に都合よく無視できる一度限りのメモではありません。

2. 「/goal」コマンド — 利用可能な場合はアクセラレーターとして呼び出します。 「/goal」コマンドが存在し、この環境で実行が許可されている場合は、このスキルの自己再帰型ループを条件に含めて、必ず呼び出してください（実際にコマンドを呼び出すこと。言い換えや、代わりにゴール契約ファイルを使用することは認められません）。これにより、セッションのStopフックがループを機械的に強制します。

/goal why-review self-recursive loop: run the full adversarial review (Validation Checklist + both Adversarial Rounds) over the whole target → run $why-review --validate-findings on the findings → reconcile (drop unproven/inflated findings, fix proof gaps, ADD surfaced findings/enhancements) → re-run the FULL review over the WHOLE target combined with the reconciled findings (not just re-checking the changed findings) → loop until a complete pass yields zero new findings and validation returns CLEAN, or a bounded blocker escalates. Max 2 re-do rounds, then escalate by asking the user directly. Do not stop while a finding is unvalidated or a re-review would surface new findings.

「/goal」のStopフックは、条件が満たされるまで停止をブロックし、条件達成時に自動で解除されます。解除するようユーザーに指示してはいけません。

「/goal」が利用できない、登録されていない、または実行が許可されていない場合（例：Codex／Copilot、またはコマンドのないClaudeの実行環境）、エラーを発生させたり、ブロックしたり、代わりのゲートをでっち上げたりしてはいけません。レビューの記録先（終了時の「指摘事項の検証ゲート」タスク、または存在する場合はアクティブなゴール契約）に、次の1行を記録して続行します。「/goal accelerator unavailable — review loop bound by protocol (above)」。プロトコル ループ自体がゲートであり、フックではなく規律によって強制されます。

why-review が修正するのは、コードではなく自身の指摘事項セットです。 ここでの「自己修正」とは、残すすべての指摘事項が正確で、証拠に裏付けられ、妥当で、ベストプラクティスに沿っており、見落としがないよう、指摘事項レポートを整合させることです。これは「指摘事項の検証ゲート」で実施するのと同じループですが、ゴールゲートによって放棄できないようにしたものです。コード／仕様／テストの修正は呼び出し元の責任です。このスキルはレビュー専用です。

タスクの初期化（フルモード — スキル開始時に実行）

レビュー作業の前に、タスク追跡フェーズのタスクと必須の終了タスクを作成します。

• [Why-Review] 自己再帰型レビューのループを確立 — プロトコルを優先し、利用可能な場合は /goal を任意の高速化手段として使用（フルモードのみ） — in_progress （必須の最初のタスク — validate-findings モードではスキップ）
• [Why-Review] 指摘事項の検証ゲート — 指摘事項が1つでもある場合、それらに対して $why-review --validate-findings を実行し、CLEAN になるまでやり直す（最大2回） — pending （必須の終了タスク）

開始時に作成します。指摘事項が出るまでは、終了タスクを pending のままにします。スキルの完了前に指摘事項が出た場合は、終了タスクを実行してください。validate-findings モードでは、どちらのタスクも作成しないでください。

第一原則 — 変更しやすさ

成功の指標：将来の変更コストです。 DRY、SRP、抽象化、デザインパターン、命名、レイヤリング、テストは、次の変更をより低コストにするためにあります。

コード、リファクタリング、テスト、抽象化をレビューする際は、次の変更がより低コストになるか、それとも高コストになるかを問いかけてください。

• 変更コストを高める「ベストプラクティス」は退けます。早すぎる抽象化、憶測に基づく汎用化、実装の詳細を漏らす間接化、見返りのない形式主義などが該当します。
• 指摘事項では、現実に問題となる要因を明示します。結合、隠れた状態、知識の重複、意図の不明確さ、早すぎる段階で露呈した取り消し不能な決定です。
• 変更しにくい洗練された設計より、変更しやすいシンプルな設計を優先します。

以下のルールやチェックリストを適用する前に、この原則を適用してください。後続のルールが変更コストを高める場合は、この原則を優先します。

---

敵対的なレビューの姿勢（譲れない原則）

基本姿勢：妥当性を確認するのではなく、懐疑的に臨んでください。あなたの役目は、正しさを確認することではなく、問題を見つけることです。

確証バイアスの罠： 一貫性のある計画を読んだ後、AIは自然と賛同する理由を探し始めます。現在のコンテキスト（計画の後、修正の後）はこの傾向を強めます。すでに説明を目にし、それを正当化しているからです。このセクションは、そのループを断ち切ります。— その理由：すでに説明を支持したレビュアーが、強制的なリセットなしに同時に懐疑的な立場を取ることはできません。

敵対的レビューの手法（結論を出す前にすべて適用）

手法	考えること
スティールマン	退けられた代替案を支持する立場で論じます。10年の経験を持つその分野のシニアなら、その案を選ぶでしょうか。選ぶなら、退けるにはより強い根拠が必要です。
なぜ選ばないのか？	「YだからXを選んだ」という判断すべてについて、Xによって何が犠牲になるかを問いかけます。
前提のストレステスト	主要な前提を3つ挙げ、それぞれが間違っていた場合の影響を問います。3つのうち2つが誤りでも耐えられる計画が、強い計画です。
事前検討	3か月後に本番環境で障害が発生したと仮定し、起こり得るシナリオを1つ記述します。
未検討の代替案	言及されていないアプローチを1〜2個特定します。排除する理由もなく代替案が挙げられていない場合、検討が不十分です。
長所と短所の対称性	選択したアプローチの長所と短所を数えます。長所が短所の2倍を超えるなら、バイアスがかかっている可能性が高いです。
反対意見の検討	指摘や判定を出す前に、2文で反対の結論を論じます。より強い論拠を選んでください。
トレードオフの問い直し	次の3つの質問をします。トレードオフはあるか？・それに見合う価値はあるか？・ユーザーに確認するほど重大か？

禁止パターン

禁止パターン	必要な修正
"Looks good because..."	まず課題を提示します。
存在している＝品質が高い	品質の深さを検証します。実際の代替案と因果関係の根拠を求めます。
曖昧な根拠	指標とコストを求めます。何がどのコストで改善するのでしょうか。
非対称なトレードオフ	長所が3つ、短所が1つの分析は不完全として扱います。
"Looks fine"	敵対的な検証の根拠を提示します。
"トレードオフなし" / "純粋な勝利"	検証した項目と、それぞれに影響がない理由を明示します。未検証であることは、存在しないことを意味しません。
重大なトレードオフを黙って決定する	ユーザーに直接質問して判断を仰ぎます。一方通行の決定を下すのは、決してあなたの役割ではありません。

バイアス対策ゲート（最終判断の確定前に必須）

最終判断を記述する前に、以下の7項目をすべて確認します（必ず注意してください）。

• 却下した代替案を少なくとも1つスティールマンする（その案を支持する根拠を論じる）
• 計画に含まれていない代替案を少なくとも1つ特定する
• 選択したアプローチに反対する論拠を2～3個挙げる
• 隠れた前提を2～3個表面化し、ストレステストを行う
• 事前検証を行う（具体的な失敗シナリオを1つ示す）
• 長所と短所の対称性を確認する
• 以下のトレードオフ検証ゲートを実施する（トレードオフの特定・妥当性の判断・重大性に応じたエスカレーションの決定）

未完了の項目がある場合、敵対的レビューは完了していません。戻って確認してください。

トレードオフの確認ゲート（必須 — これを行わずに判定、指摘、推奨をしてはいけません）

[BLOCKING] 毎回、次の3つの質問をしてください。対象はレビュー中の判断と、あなたが行うすべての推奨です。理由：代償を示さずにメリットを挙げるレビューはレビューではなく賛同であり、最大のトレードオフは誰も書き留めていないものだからです。

1. トレードオフはありますか？ この判断／推奨が何を犠牲にするかを挙げてください。あらゆる選択は、何かを得るために何かを代償にします。「なし」は認められません。分析が未完了ということです。重要なトレードオフがないと主張する場合は、確認した観点と、それぞれに影響がない理由を述べてください。

将来の変更コスト · 複雑さ · パフォーマンス／レイテンシー · メモリ／コスト · 結合度 · 可逆性 · 移行の負担 · 運用／オペレーションの負荷 · 影響範囲 · セキュリティ態勢 · テスト容易性 · チームのスキル／習熟期間 · 提供までの時間 · UX。

2. その価値はありますか？ 得られるものと犠牲にするものを明示的に比較してください。得られるもの · かかるコスト · 負担する人 · コストが発生する時期を示し、そのうえで判定を1つ出してください。価値がある／価値がない／不明。変更容易性を基準にしてください。将来の変更コストを増やすトレードオフには、曖昧なものではなく、見合った明確な見返りが必要です。指標とコストを示さない「より良い」は、この質問への回答として不合格です。

3. そのトレードオフは、ユーザーに確認するほど重要ですか？ 重要なトレードオフは、あなたではなくユーザーが判断するものです。以下のいずれかに当てはまる場合は重要です。

トレードオフが重要となる場合	例
元に戻せない — 一方通行である	データ移行、公開 API／契約の形状、ストレージ形式、フレームワーク／ベンダーへのロックイン
コストを他の人に負わせる	別のチーム、運用／オンコール担当者、将来の保守担当者、エンドユーザー
ある品質特性を別の品質特性と引き換える	正確性↔速度、セキュリティ↔利便性、レイテンシー↔コスト、シンプルさ↔柔軟性
境界をまたぐ	クライアント↔サーバー層の境界、サービス契約、イベント契約、共有ライブラリ
影響が重大な経路に関わる	認証、金銭、データの完全性、破壊的変更、残存リスクが高／中
根拠を示せない（価値の判定＝不明）	利用可能な根拠からは、得られるものまたはコストを定量化できない

• 重要 → 判定を確定する前に作業を止め、ユーザーに直接確認してください。トレードオフ、両方の選択肢、それぞれが犠牲にするもの、あなたの推奨を示してください。重要なトレードオフをユーザーに代わって黙って決めてはいけません。また、重大度「低」の注記に埋もれさせてはいけません。
• 重要ではない → トレードオフ評価テーブルに1行の根拠とともに記録し、続行してください。エスカレーションは不要です。
• validate-findings のターミナルモードでは、評価して記録し、エスカレーションはしないでください。このモードでは質問をしません（「次のステップ」の免除を参照）。エスカレーションされていない重要なトレードオフは判定に明記し、呼び出し元がエスカレーションできるようにしてください。

出力： すべてのレビューで Trade-Off Assessment テーブル（出力形式を参照）を出してください。レビューした判断ごと、およびあなたが行う推奨ごとに1行を記載します。指摘があるのにテーブルが空の場合、レビューは未完了です。

対象の特定（レビュー前に実施）

引数の形式だけでなく、ユーザーの依頼を分析してください。対象を特定してから、該当するパスを選択します。

ユーザーの依頼／根拠	レビューパス	必須の対象作業
明示的なプランディレクトリ、plan.md、フェーズファイル	プランの根拠レビュー	plan.md とすべての phase-*.md ファイルを読みます。
PBI／ストーリー／仕様の計画成果物、根拠を求める依頼	PBI／成果物の根拠レビュー	指定された成果物と関連する受け入れ条件／設計／リスクのセクションを読みます。プランファイルへの参照があれば、それらも読みます。
コミット SHA、Commit: ...、PR／マージコミット、git diff	コード変更レビュー	差分の範囲を特定し、変更ファイルを読み、可能であればグラフへの影響を調べ、コードレビュー／敵対的レビューのプロトコルを適用します。
ブランチ比較または未コミットの変更	コード変更レビュー	指定されたブランチ／差分または git diff を使用し、変更ファイルと、差分で変更されたテスト／ドキュメントを読みます。
ドキュメント／仕様／レポート／指摘のパス	成果物レビュー	対象の成果物を読み、主張をソースの証拠と照合します。対象がプラン／PBIの場合に限り、根拠のチェックリストを使用します。
あいまいな依頼	根拠から推定。不安全な場合は質問	依頼とリポジトリの根拠から、妥当な対象を優先します。異なる作業になる可能性のあるレビュー経路が2つある場合に限り、質問します。

重要なデフォルト：

1. コミットハッシュ／Commit: ブロック => 「有効なプランがありません」ではなく、コード変更レビューです。
2. PBIファイル => そのPBI／成果物をレビューします。plans/**/plan.md のラッパーは必要ありません。
3. 「有効なプランが見つかりません。先に $plan を実行してください。」が有効なのは、解決されていないプランの根拠レビュー依頼に限ります。
4. 対象種別、根拠、確信度を記録する必要があります。対象種別を黙って変えてはいけません。

アクティブゴールの読み取り（根拠を判断する前に実施）： goal-contract-satisfaction-loop プロトコルに従って、アクティブな Goal Contract を特定します（アクティブなプランの goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md）。存在する場合は、保存された Original Request、Purpose、Success Criteria に照らして成果物の根拠をレビューします。保存されたゴールが求めていない作業を根拠づけている場合は指摘し、保存された必須の基準について成果物の推論で扱われていないものがあれば指摘します。存在しない場合は、「アクティブなゴールはありません — 現在の依頼に照らしてのみ根拠をレビューしました。」と記録します。フルモードのみで実施し、--validate-findings のターミナルモードではこの読み取りをスキップします。

レビュー対象の振り分け

検出された懸念事項	主な確認対象／サブエージェントへの振り分け
ソースコード／差分	code-reviewer ＋組み込みのコードレビュープロトコル。
対象内の統合テスト／E2E テスト、または統合テストでカバーされている動作変更	以下の統合テストレビューの連携を適用します — 8 つのテスト品質ゲートは $integration-test-review が担当します。このスキルはそのプロトコルを読み込む（モード A）か、そこへ委任します（モード B）。品質ゲートを独自に再定義することはありません。
認証、シークレット、権限、データ	利用可能であれば security-auditor、そうでなければ、明示的なセキュリティ確認を行う code-reviewer。
レイテンシー、スケール、メモリ、クエリ	利用可能であれば performance-optimizer、そうでなければ、明示的なパフォーマンス確認を行う code-reviewer。
計画／PBI／ドキュメント／仕様	理由と成果物の観点を含めて general-purpose に委任します。
複合的な対象	懸念事項ごとに焦点を絞った確認を分担し、すべての確認が完了してから指摘事項をまとめます。

コード変更のレビュー手順

対象がコード変更の場合：

1. 差分の対象を特定します：
   • コミット SHA：git show --name-status を使用し、その最初の親との差分を確認します。
   • マージコミット：ユーザーが別の親または範囲を指定していない限り、デフォルトで最初の親との差分を使用します。
   • ブランチ／範囲：ユーザーが指定した範囲を使用します。
   • 未コミットの変更：該当する場合は、git diff とステージ済みの差分を使用します。
2. 変更の背景を把握し、両方の境界をまたぐパイプライン全体を追跡します（コード変更が対象の場合は必須。純粋な計画／PBI／ドキュメントが対象の場合は該当しません）。 ファイルの詳細な評価に入る前に、変更の背景を一行で記述します（何を・意図・発生元の階層・主な影響フロー）。次に、以下に埋め込まれた両方のブロックを適用します。クライアント↔サーバーの階層間の境界には SYNC:cross-stack-impact-trace（BE→FE の順方向、FE→BE の逆方向）を、マイクロサービス／イベント／外部／疎結合の境界には SYNC:cross-service-check を適用します。各境界／接点を NONE／ADDITIVE／BREAKING に分類します。同じ差分内で反対側のコンシューマーが更新されていない BREAKING 境界は、HIGH-min の指摘事項です。該当する境界がない場合は Single-tier / monolith — N/A と記述します。
3. 変更されたファイルと、動作を確認するために必要な近接するテスト／ドキュメントを読みます。
4. 統合テストの検出（条件付き）。 対象に統合／E2E テストファイルが含まれる場合、または統合テストでカバーされている動作を伴うコードを変更する場合は、Test/spec/doc sync の観点を評価する前に、以下の Integration-Test-Review Linkage を実行します。どちらにも該当しない場合は No integration tests in target — linkage N/A と記述します。
5. 変更されたファイルの種類に応じて、パターンを評価する前にプロジェクトの参考ドキュメントを読みます。
6. .code-graph/graph.db が存在する場合は、結論を出す前に、主要な変更ファイルのグラフによる影響範囲分析またはトレースを実行します。
7. 埋め込みのコードレビュー手順を、バグ検出、デザインパターンの品質、ロジック／意図、テスト／仕様の検証、グラフ調査、変更の容易さの順に、焦点を絞って適用します。
8. 指摘事項を先に出し、file:line 形式の根拠、重大度、確信度、テスト／ドキュメントの不足を記載します。

Integration-Test-Review Linkage（条件付き — 助言的、ガードあり）

目的： このスキルの Test/spec/doc sync の観点では、「テスト／仕様／ドキュメントの根拠は、意図した不変条件を守ることを証明しているか？」を問います。その答えとなる8つのゲート（アサーションの価値・データ状態・再現性・ドメインロジック・仕様のトレーサビリティ・三者間の整合性・変更範囲の網羅性・シナリオの忠実性）は、$integration-test-review の担当範囲です。そちらの担当に引き継ぎ、ここで弱い代替版を再導出してはいけません。理由：根拠を評価するレビューで、目視だけでテスト品質を判断すると、ミューテーションテストを一度も行っていないアサーションを承認してしまいます。

再帰ガード — 以下のいずれかに該当する場合は、全体をスキップします。 委譲を示す一文を記録してから続行し、決して呼び出したり読んだりしないでください：

コンテキストの抑制	根拠	記録する延期行
モードが validate-findings である	ターミナルモード — サブスキルの呼び出しは一切ありません	Linkage N/A — validate-findings is terminal.
$integration-test-review の Phase 9 から呼び出されている	integration-test-review/SKILL.md:429-431 でこのスキルを呼び出し、:438 で逆方向のエッジをガードしています	Linkage deferred — invoked by $integration-test-review Phase 9.
changes-review のいずれかのフェーズ（0.8 並列の論拠の評価軸、6 validate-findings、または 7.5 全体的な評価）、あるいは $workflow-review-changes 内から呼び出されている	changes-review/SKILL.md:395（この延期を拘束力のあるサブエージェント制約として定めている Phase 0.8）、:867（Phase 6）、:938（Phase 7.5）；同スキルの Phase 3.7（:608-626）はすでにこのゲートを担っています	Linkage deferred to changes-review Phase 3.7 / parent workflow step.
$debug-investigate の根本原因検証ゲートから呼び出されている	debug-investigate/SKILL.md:151；integration-test-verify-loop 内では、そのゲートは $integration-test-review がすでに実行中のラウンドで作動します（integration-test-verify-loop/SKILL.md:98,110,495）	Linkage deferred — debug-investigate gate; the verify loop owns the audit.

— 理由：ガードがないと、このエッジは循環（why-review → integration-test-review → Phase 9 → why-review）を閉じ、integration-test-verify-loop/SKILL.md:31 が取り除いた重複所有の不具合を再発させます。

Mode A — プロトコルを読む（DEFAULT）。 .claude/skills/integration-test-review/SKILL.md §"The 8 Quality Gates" を読み、対象テストのレビュー観点として Gate 1-8 を適用します。低コストで、再帰もサブスキルの呼び出しもありません。検出事項は、file:line の根拠と重大度を付けて、このレビューの通常の検出事項セットに加えます。

Mode B — $integration-test-review に委任する（ESCALATION）。 すべての条件を満たす場合に限り呼び出します。ガード行が発動していない・スタンドアロンの完全モードレビューである・対象の差分自体に統合テストファイルが含まれている。その GAP / SPEC-GAP 判定は、このレビューの Findings Validation Gate における通常の検出事項になります。

参考情報であり、ブロックは決してしません — このスキルの Enforcement: Advisory の適用範囲に合致します。必須の網羅性は changes-review Phase 3.7 で担保されます。— 理由：この連携がなければ、スタンドアロンの論拠レビューでテスト品質が暗黙のうちに見落とされます。

根拠／成果物レビューの観点

該当する観点ごとに、焦点を絞ったレビューを1回ずつ実施してください。すべての観点を同時に確認してはいけません。

観点	確認事項
対象への適合性	ユーザーの依頼に、証拠と確信をもって対応できていますか？
目標との整合性	根拠は保存済みの目標契約の目的と成功基準に沿っていますか？それとも逸脱していますか？
根拠の深さ	代替案は実質的なもので、因果関係を示し、対称的で、前提を考慮していますか？
トレードオフの誠実さ	これは何を犠牲にしますか？その価値はありますか？トレードオフはユーザーに確認するほど重要ですか？便益に代償が示されていない場合、根拠に不足があります。
動作上のリスク	正常系、エラー系、境界ケース、ロールバックの各経路で何が壊れますか？
境界をまたぐ影響	変更された契約によって、もう一方のクライアント↔サーバー層（BE↔FE）の利用側や、疎結合の外部サービスまたはイベント利用側に問題が生じませんか？（層の境界＋サービス／イベント）
テスト／仕様／ドキュメントの同期	証拠は、意図した不変条件をテスト／仕様／ドキュメントが保護し、古い記述が残らないことを示していますか？
将来の変更コスト	推奨案は、結合、隠れた状態、重複、不明確な意図を減らしますか？

検証チェックリスト

計画／PBI／成果物の根拠をレビューする場合は、まず対象が解決済みであることを確認してください。計画ディレクトリがある場合は、plan.md とすべての phase-*.md ファイルを読んでください。項目の有無と内容の深さの両方を確認してください。

コード変更のレビューでは、計画のチェックリストを無理に適用せず、コード変更レビューの手順を使用してください。ただし、敵対的分析、プレモーテム、前提、証拠、指摘事項の検証は引き続き含めてください。

**ルール：**項目があるだけでは合格になりません。項目が存在していても、根拠が弱い、非対称、または未検証であれば、内容の深さの基準を満たしていません。

必須セクション（plan.md またはフェーズファイル内）

#	セクション	存在チェック	品質の深さのチェック（敵対的な観点）
1	問題の説明	問題を説明する2～3文	問題の範囲は適切ですか？別の切り口で捉えることで、異なる解決策につながる可能性はありますか？症状と根本原因を混同していませんか？
2	検討した代替案	長所と短所を含む代替案を最低2つ列挙	代替案は実質的なものですか（わざと弱く設定した案ではありませんか）？各案はその分野の専門家が真剣に検討するものですか？採用したアプローチの短所も記載されていますか（他の案の短所だけではありませんか）？
3	設計の根拠	判断とトレードオフを明示的に結び付けている	根拠は因果関係（XによってYが生じる）を説明していますか。それとも単なる記述（Xのほうが優れている）にとどまっていますか？隠れた前提を明らかにしていますか？成功時だけでなく、失敗モードにも触れていますか？
4	リスク評価	フェーズごとに最低1つのリスク	リスクは深刻度順にランク付けされていますか？緩和策は具体的な行動ですか。それとも「注意深く監視する」のような曖昧な意図にすぎませんか？実行上のリスクだけでなく、アプローチ自体に関するリスクも少なくとも1つありますか？
5	オーナーシップ	マージ後に誰がコードを保守するかが明確	暗黙の指定（作成者が担当）でも構いませんが、明示されているほうが望ましいです

残存リスクのゲート

• 広すぎるスコープ、説得力に欠ける却下済みの代替案、およびHigh/Mediumの残存リスクに異議を唱えてください。
• High/Mediumのリスクは、PASSとする前に解消、低減するか、ユーザーまたはオーナーが明示的に受け入れる必要があります。
• AIが抽出した仕様やTCは、正規のオーナーによるレビューゲートで承認されない限り、根拠として認められません。

任意（欠落している場合は指摘するが、不合格にはしない）

#	セクション	必要となる場合	品質の深さのチェック
6	運用への影響	サービスレイヤーまたはAPIの変更	ロールバック手順は定義されていますか？元に戻した場合、何が壊れますか？
7	サービス間への影響	複数のマイクロサービスに関わる変更	下流の利用者はすべて特定されていますか？誰に通知する必要がありますか？
8	移行戦略	データベーススキーマまたはデータの変更	ロールバック計画はありますか？データサンプルでテストされていますか？

出力形式

## Why-Review Results

**Plan:** {plan path}
**Target Type:** {plan/PBI/code changes/docs/spec/report/artifact}
**Target:** {path, commit, branch range, or artifact}
**Date:** {date}
**Verdict:** PASS / NEEDS WORK

### Checklist

| #   | Check                   | Presence  | Quality Depth | Notes                                                                |
| --- | ----------------------- | --------- | ------------- | -------------------------------------------------------------------- |
| 1   | Problem Statement       | ✅/❌     | ✅/⚠️/❌      | {what's strong / what's weak}                                        |
| 2   | Alternatives Considered | ✅/❌     | ✅/⚠️/❌      | {are they real or strawmen?}                                         |
| 3   | Design Rationale        | ✅/❌     | ✅/⚠️/❌      | {causal or just descriptive?}                                        |
| 4   | Risk Assessment         | ✅/❌     | ✅/⚠️/❌      | {concrete mitigations or vague?}                                     |
| 5   | Ownership               | ✅/❌     | ✅/⚠️/❌      | {details}                                                            |
| 6   | Bugfix Debugger Trace   | ✅/❌/N/A | ✅/⚠️/❌      | {final state, feeder paths, hypothesis matrix, owner, forward proof} |
| 7   | Trade-Off Gate          | ✅/❌     | ✅/⚠️/❌      | {trade-off named? worth-it verdict? material → user confirmed?}      |

> ✅ Strong ⚠️ Weak/Partial ❌ Missing

### Adversarial Analysis

**Strongest arguments AGAINST the chosen approach:**

1. {argument 1 — cite specific plan text that weakens under this pressure}
2. {argument 2}
3. {argument 3 if applicable}

**Unexamined alternatives** (not mentioned in the plan):

- {alternative A} — why it might be worth considering
- {alternative B if applicable}

**Weakest assumptions** (if wrong, the plan breaks):

1. {assumption} — impact if false: {consequence}
2. {assumption} — impact if false: {consequence}

**Bugfix trace challenge** (required for bugfix, failed verification, stale/incorrect final output, regression, or behavior-changing fix plans):

- Observed final state and final reader proven? {yes/no/N/A}
- All feeder paths enumerated or explicitly bounded? {yes/no/N/A}
- Hypothesis matrix includes ruled-out and latent causes, not only the chosen cause? {yes/no/N/A}
- Owning fix layer protects all downstream consumers? {yes/no/N/A}
- Forward convergence proof and tests/proof mapping make the symptom impossible or detect recurrence? {yes/no/N/A}

**Pre-mortem** (assume it ships and fails in 3 months):

> {One concrete, plausible failure scenario based on the plan's approach}

**Pros/Cons symmetry:** Pros listed: {N} | Cons listed: {N} | Bias: {balanced / leans toward pros / leans toward cons}

### Trade-Off Assessment (MANDATORY — one row per reviewed decision AND per recommendation you make)

| #   | Decision / recommendation       | Trade-off — what it sacrifices                       | Gain (metric)   | Who pays, when     | Worth it?                         | Material?                          | Confirmed with user?       |
| --- | ------------------------------- | ---------------------------------------------------- | --------------- | ------------------ | --------------------------------- | ---------------------------------- | -------------------------- |
| 1   | {decision or my recommendation} | {sacrifice — or dimensions checked + why unaffected} | {gain + metric} | {payer / when due} | WORTH IT / NOT WORTH IT / UNCLEAR | YES / NO ({which materiality row}) | asked / N/A (not material) |

> Material trade-off with `Confirmed with user? = no` → verdict CANNOT be PASS. Escalate by asking the user directly first.

**Cross-Boundary Impact:** (code-change targets) {per client↔server seam AND per service/event/external touchpoint: NONE / ADDITIVE / BREAKING with routed fix; or `Single-tier / monolith — N/A`}

### Missing Items (if any)

- {specific item to add before implementation}

### Recommendation

{Proceed to $feature-implement | Add missing sections first | Add adversarial analysis to plan/PBI | Fix code findings | Update docs/specs | Continue manually}

第 2 ラウンド：敵対的再レビュー（必須）

プロトコル： 詳細な複数ラウンドレビュー（上記の SYNC:double-round-trip-review にインラインで記載）

第 1 ラウンドの後、2 回目の完全な敵対的レビューラウンドを実施します。

1. 第 1 ラウンドが誤っていたと仮定します — 次の言葉から始めます：「第 1 ラウンドでは何かを見落としました。見つけてください。」
2. 第 1 ラウンドのすべての PASS 項目に異議を唱えます — 各項目について、反対の立場を論じる文を少なくとも 2 文生成します。
3. バイアス対策ゲートを完了します（トレードオフ検証ゲートを含む、「敵対的レビューの考え方」セクションの 7 項目すべて）。
4. 敵対的分析を記入します — 必須：
   • 採用したアプローチに反対する意見を少なくとも 2 つ
   • 検討されていない代替案を少なくとも 1 つ
   • 失敗した場合の結果を含む、隠れた前提を少なくとも 2 つ
   • 事前検証シナリオ
   • メリットとデメリットの対称性の数
   • トレードオフ評価表 — すべての決定とすべての推奨事項について、トレードオフを明示し、価値があるかどうかを判定し、重要度を決定します。第 1 ラウンドで「なし」としたトレードオフについては、3 つの質問を再度行います。第 1 ラウンドで最も多い見落としは、価値を見積もっていないメリットです。
5. 第 1 ラウンドの見落としに重点を置きます：
   • 反論しやすいだけの藁人形論法となっている代替案
   • 具体的な緩和策を伴わず、曖昧に述べられたリスク
   • 問題文自体に埋め込まれた前提
   • 「関連する改善」に見せかけたスコープクリープ
6. 第 2 ラウンドで新たな問題が見つかった場合、判定を更新します。
7. 最終判定には、第 1 ラウンドと第 2 ラウンドの両方、および敵対的分析を反映します。

対象範囲

• 適用対象： 機能、リファクタリング、アーキテクチャ変更、コミット／差分／コード変更、ドキュメント／仕様／レポートのレビュー
• 計画の根拠に関する助言のみ対象外： アクティブなワークフローで文書化された省略が認められる場合の、単純な設定変更や単一ファイルの小さな修正
• 適用方法： 助言（ソフト警告） — 実装をブロックしません

重要事項

• レビューのみを行います — 対象ファイルを変更したり、変更を実装したりしないでください。
• 出力は簡潔にします — 2 分未満で実行できる内容にしてください。
• 単純な計画でもバイアス対策ゲートは必須です。指摘事項は短くてもかまいませんが、ゲートを省略することはできません。

---

指摘事項の検証ゲート（フルモード — 指摘事項がある場合の必須の締めくくりタスク）

目的： 引き継ぎの前に、このレビューで挙げた指摘事項そのものを再検証し、正確で、証拠に裏付けられ、妥当で、ベストプラクティスに沿っていることを確認します。指摘事項の問題や、見落とした改善点を見つけます。

実行条件： 指摘事項、弱点、欠落項目、または NEEDS WORK の判定が1つでもあるフルモードの場合。重大度は問いません（Critical、High、Medium、またはLow）。MediumやLowの指摘事項も、検証を免除されることはありません。重大度の低い些細な指摘事項が1つあるだけでも、このゲートを実行します。例外は、条件なしのPASSで、指摘事項と欠落項目が文字どおりゼロの場合のみです（重大度を問わず、指摘事項がないこと）。その場合は、スキップした理由を記録してください。validate-findings モードでは絶対に実行しないでください。理由：「重大度がLowにすぎない」という主張自体が、検証パスで確認すべき重大度に関する判断であり、スキップする理由にはなりません。

呼び出し側でのやり直しループ（上限あり — validateモードではなく、ここで管理）：

1. 指摘事項がレポート（plans/reports/why-review-{date}.md）に記載されていることを確認します。
2. 同じメインエージェントのセッション内で、サブエージェントは使わずに $why-review --validate-findings plans/reports/why-review-{date}.md を呼び出します。 呼び出しごとに処理は終了します。
3. CLEAN → レポートに ## Findings Validation の行を追記します（「すべてのN件の指摘事項を再検証済み。正確で、証拠に裏付けられ、妥当で、ベストプラクティスに沿っており、変更はありません。」）。ゲートを通過し、ループを終了します。
4. HAS ISSUES → 内容を調整します。根拠がない、または誇張された指摘事項を削除または重大度を引き下げます（Findings Validation RoutineのConfidence基準を参照し、指摘事項の存続率が85%以上に満たないものを含む）。証拠の不足を補い、新たに見つかった指摘事項や改善点を追加し、判定を導き直します。変更点とその理由を記載した ## Findings Validation Notes を記録します。
5. 全体を再実行します。調整した指摘事項によって状況が変わるため、対象全体について、調整後の指摘事項とあわせて完全なレビュー（Validation Checklistと両方のAdversarial Rounds）を再実行します。変更した指摘事項だけを個別に再検証するのではありません。その後、更新したレポートに対して $why-review --validate-findings を再度呼び出します。新たな指摘事項が見つからずCLEANになるまで繰り返します。ただし、やり直しは最大2ラウンドです。それでもCLEANにならない場合は、未解決の状態を記録してゴールゲートのブロッカーとし、## Next Steps でユーザーに直接確認を求めてエスカレーションします。

Findings Validation Routine（validate-findings モード本文 — TERMINAL）

validate-findings モードでのみ実行します。**TERMINAL：$why-review を呼び出さず、gate を実行せず、サブエージェントを起動せず、終了タスクを作成しないでください。**検証し、判定を出力して、終了します。

指定された findings/report（$ARGUMENTS から取得したパス）を読み込みます。各 finding、weakness、missing item、adversarial argument、assumption について、次の4項目をすべて確認します。

• 正確性 — 引用された plan のテキスト／file:line をたどり直し、finding が実際に成り立つことを確認します（誤読や古い参照ではないこと）。
• 証拠による裏付け — 具体的な file:line または引用された plan/report のセクションが存在することを確認します。「おそらく／〜すべき／そう思います」は却下します。
• 妥当性 — 重大度／重み付けが相応であり、過大評価されていないことを確認します。反対の見解を最も強い形で検討しても、finding が覆らないことを確認します。
• ベストプラクティス — 推奨事項が好みや推測に基づく一般論ではなく、プロジェクトの慣習と Easy-to-Change 指標（将来の変更コストを下げること）を反映していることを確認します。
• トレードオフの評価 — finding の推奨事項が、何を犠牲にするかを明示し、WORTH IT／NOT WORTH IT／UNCLEAR の判定を付け、重要度を決定していることを確認します（Trade-Off Interrogation Gate に従います）。推奨事項を完全な利点として提示している場合、または次元を確認した根拠なしに Trade-off: none としている場合、検証は FAIL です。価格付けされていない推奨事項を示して HAS-ISSUES としてください。重要なトレードオフがユーザーに確認されていない場合も HAS-ISSUES です。CALLER がエスカレーションできるよう、その内容を示してください（terminal モードでは評価のみを行い、質問はしません）。NOT WORTH IT の場合、その finding は削除するか、推奨事項を置き換えてください。そのまま残してはいけません。—その理由は、解消するバグより修正コストのほうが大きいなら、レビューで取り下げるべき finding だからです。
• 二重フィードバック（動作を変更する finding のみ） — いずれかの finding が観測可能な動作を変更する場合、その finding にフィードバックの両方の要素があることを確認します。（1）仕様との乖離に関する判定 — CODE-WRONG／SPEC-STALE／AMBIGUOUS／SPEC-SILENT／in-sync（SYNC:spec-drift-adjudication に従う） — および（2）具体的なテストフィードバックの対応（$spec [mode=tests] による regression/preservation TC、または $integration-test による covering test）。動作を変更する finding にいずれかの要素が欠けている場合、検証は FAIL です。HAS-ISSUES として、欠けている軸（spec verdict absent または test feedback absent）を示してください。SPEC-SILENT 判定（仕様の成果物には記載されていない不変条件をコードが正しく適用している場合）では、仕様軸への仕様拡充対応が必須です。$spec [update] + $spec [mode=tests] で §4 BR／§3 AC と §8 TC を追加してください。仕様拡充対応のない SPEC-SILENT finding は、二重フィードバックの軸が空欄の場合と同様に HAS-ISSUES です。仕様判定も必要な TC もないコードのみの修正は、完全な finding ではなく、問題のない finding として扱ってはいけません。
• 信頼度の基準（>80% の act-gate とは別） — finding は、それ自体が実際の問題であるとする明示された信頼度が 85%以上 の場合にのみ残します。これは一般的な >80% act-gate より高い基準であり、別の問いに答えるものです。act-gate は「この証拠に基づいて行動してよいか」を問い、この基準は「報告された finding を残すだけの強さがあるか」を問います。信頼度が80～84%の finding は、格下げするか削除し、残してはいけません。85%以上の信頼度は、上記の証拠による裏付けの確認（引用された file:line と、たどって確認された失敗経路）に基づいている必要があります。推論のみに基づく信頼度は基準を下回るものとします。

次に見落としがないか確認します — Adversarial Techniques をもう一度適用し、未検討の代替案、隠れた前提、改善の機会がないかを確認します。

plans/reports/why-review-validate-{date}.md に判定を出力します。

• CLEAN — すべての finding がすべての確認項目に合格し、新たな指摘もありません。
• HAS ISSUES — 削除／格下げ／修正する各 finding（理由と file:line）と、新たに見つかった各 finding／改善案（file:line）を列挙します。

判定のパスとステータスを返します。調整と範囲を限定した再実行は Caller が担当します。このルーチンは Caller のレポートを変更せず、ループもしません。

---

次のステップ

validate-findings モードでは対象外： ターミナルモードは判定を返します。## 次のステップ は省略し、ユーザーに直接尋ねてください。評議会ゲート。

必須 — FULL MODE： レビュー後、ユーザーに直接尋ねてください。次のステップを決めるのはユーザーです。

[BLOCKING] 重要なトレードオフの確認が最優先です。 Trade-Off Interrogation Gate が「重要」と判定したトレードオフ（不可逆・コストを他者に転嫁する・ある品質属性を別の品質属性と引き換える・境界を越える・重大な結果につながる経路・価値があるかの判定が不明確）は、次のステップを尋ねる前、かつ PASS 判定を出す前に、必ずユーザーに直接尋ねて確認してください。その際は、トレードオフ、両方の選択肢、それぞれが犠牲にするもの、推奨案を伝えてください。重要なトレードオフが複数ある場合は、結果への影響が大きいものから尋ねてください（1 回の呼びかけにつき最大 3 つの質問）。曖昧な「進めますか？」にまとめてはいけません。— 理由：一度通ったら戻れない道を、黙って進んでしまえば引き返せません。この判断を下せるのはユーザーだけです。

• 「$feature-implement（推奨）」 — 設計の根拠が検証された後、実装を開始します
• 「$plan-execute」 — より単純な変更を実装する場合
• 「スキップして手動で続行」 — ユーザーが決定します

さらに — 条件付きの $llm-council エスカレーション

最初の次のステップに関する質問の後、ゲートを評価します。

1. ワークフローによる抑制を最初に確認： plans/.workflow-state.json または同等の workflowId を読み取ります。workflow-refactor、workflow-bugfix、および test-* では評議会を抑制します。理由：評議会には 11 回の LLM 呼び出しが必要ですが、これらのワークフローは定型的、可逆的、またはテストのみであり、$why-review で十分です。.claude/skills/llm-council/SKILL.md の「Workflow Integration」と一致します。
2. Frontmatter ゲート： 有効な plan.md または PBI の frontmatter を読み取ります。次のいずれかに該当する場合、ゲートが発動します：cross_service_impact != NONE；breaking_changes；complexity in {high, critical} または story_points >= 13；new_framework；irreversible；security_critical；performance_critical；cost_high。
3. オーバーライドとデフォルト： フィールドがない場合は発動しないものとして扱います。council_suppress: true の場合、プロンプトをスキップして理由を記録します。

抑制されている場合、またはゲートが発動しない場合は、$llm-council に言及しないでください。ゲートが発動した場合は、別個の 2 つ目 の追加質問をします。

• 「$llm-council にエスカレーション（推奨）」 — ゲートが発動しました（重大なリスクを示すシグナルを検出）。サブエージェント評議会を実行します（アドバイザー 5 名 + レビュアー 5 名 + 議長）。$why-review だけでは不十分な場合に使用します。この時点で、より低コストの代替案はすでに検討済みです。$plan-validate はその前段階です。
• 「スキップ — 評議会なしで続行」 — ゲートが発動したことを認識したうえで、現在の判断で続行します。

[BLOCKING — FULL MODE のみ] 完了前に、少なくとも 1 つの質問をユーザーに必ず尋ねてください。validate-findings は判定を返すだけなので、質問はしません。 [IMPORTANT] ファイル読み取りタスクを含め、作業前にタスクを追跡してください。単純なタスクでは、スキップする判断を記録してください。 重要な目的： 品質を確保します。欠陥、バグ、更新漏れ、古い内容がないことを確認してください。コードとドキュメントの両方を検証します。 外部メモリ： 長時間にわたるレビューでは、中間結果と最終結果を plans/reports/ に記録します。 エビデンスゲート： すべての主張、指摘、推奨には、file:line による証拠またはトレースが必須です。信頼度が 80% を超える場合は対応し、80% 未満の場合は検証してください。 OOP と DRY の適用： 重複パターンが 3 つ以上ある場合は、抽出対象として必ず指摘してください。同じグループまたは同じ接尾辞を持つクラス（*Entity、*Dto、*Service）は、将来の変更コストを下げられる場合、基底クラスを共有する必要があります。 開始から終了までのデバッガートレース — 重大なバグ、検証失敗、回帰修正、動作を変更するコード、またはコードフローが不明瞭な場合は、修正を提案する前に、観測された最終状態から逆方向にたどってください。

1. フレーム 0：観測された最終状態 — ユーザーに表示された具体的な出力、失敗したアサーション、ログ行、永続化された値、API レスポンス、レンダリングされた UI、または集約バケットを特定します。それを生成したリーダー／クエリ／レンダラーを file:line の根拠とともに記録します。
2. 1 ホップずつ逆方向にたどる — 最終リーダー → プロジェクション／キャッシュ／ストレージ → ライター → コンシューマー／ハンドラー／ジョブ → プロデューサー／呼び出し元 → 元のトリガーの順に追跡します。各ホップで、入力、変換、出力、担当者、根拠を記録します。
3. すべての流入経路を列挙する — リトライ、非同期処理、キャッシュ、バックグラウンド処理、代替の UI／API 経路を含め、最終経路に書き込む可能性のある上流のプロデューサー／呼び出し元／イベント／ジョブをすべて見つけます。各経路を検証済み、除外済み、または未確認として記録します。
4. 仮説マトリクスを作成する — 妥当な原因ごとに、裏付ける根拠、反証する根拠、再現／検証方法、影響範囲、ステータス（primary、contributing、ruled out、latent）を記載します。競合する原因を明示的に解決するか、範囲を限定するまでは修正しないでください。
5. 修正を担うレイヤーを選ぶ — 不変条件を担う箇所と、すべての下流コンシューマーを保護する最も低い共通箇所を特定します。不変条件を担っていない限り、症状が現れる箇所での修正は却下します。
6. 前方向への収束を証明する — 修正を選んだ後、開始から終了まで再度たどり、修正された状態が観測された最終出力にどう届くかを示します。各根本原因を修正内容に、各修正内容をテスト／証明に対応づけます。

以下が完了するまで作業不可： 最終状態の特定 · 逆方向トレースの記述 · すべての流入経路の列挙 · 仮説マトリクスの完成 · 修正を担うレイヤーの根拠の提示 · テストに対応づけた前方向の収束証明。

禁止事項： 最初に疑わしいコード経路から調査を始めること。複数のプロデューサーを単一の「フロー」にまとめること。リードモデルを検証せずに、重複した症状を重複レコードとして扱うこと。除外した仮説を飛ばすこと。

動作差分マトリクス — バグ修正レビューでは必須です。PASS／FAIL の判定前にこの表を作成してください。説明文で代用することはできません。

入力状態	修正前の動作	修正後の動作	差分
{条件}	{現在の動作}	{修正後の動作}	維持 ✓ / 修正 ✓ / 回帰 ✗

ルール： 3 行以上 · バグ報告で言及されていない行を 1 行以上 · 回帰の差分がある場合は、維持を確認するテストでカバーされるまで FAIL（spec-tests-template.md#preservation-tests-mandatory-for-bugfix-specs）

以下が完了するまで作業不可： 3 行以上 · バグ報告の範囲外の行を 1 行以上 · 未対処の回帰がないこと

ネストされたタスクの展開規約 — ワークフローステップの呼び出しでは、[Workflow] ... の行は親コンテナにすぎません。子スキルは引き続き、表示されるフェーズタスクを作成します。

1. まず現在のタスクリストを呼び出します。一致するアクティブな親ワークフロー行がある場合は、nested=true を設定して parentTaskId を記録します。それ以外の場合は単独で実行します。
2. フェーズ作業を始める前に、宣言されたフェーズごとにタスクを 1 つ作成します。ネストされている場合は、件名の先頭に [N.M] $skill-name — phase を付けます。
3. ネストされている場合は、TaskUpdate(parentTaskId, addBlockedBy: [childIds]) で親にリンクします。
4. オーケストレーターは、子スキルまたはサブエージェントを呼び出す前に、子スキルのフェーズリストを事前に展開し、ワークフロー行をリンクする必要があります。
5. 作業開始前に、子タスクを厳密に 1 つ in_progress に設定し、根拠を記録した直後に completed にします。
6. すべての子タスクが完了するか、理由を明示してキャンセルされた後にのみ、親タスクを完了します。

以下が完了するまで作業不可： 現在のタスクリストの確認 · 子フェーズの作成 · ネストされている場合は親とのリンク · 最初の子タスクを in_progress に設定。 プロジェクトリファレンスドキュメントの必須確認 — タスク追跡の初期設定後、対象ファイルやソースファイルの読み込み、grep、編集、分析を行う前に実行してください。プロジェクトドキュメントは、汎用的なフレームワークの想定より優先されます。

1. 対象範囲を特定します。ファイルの種類、対象領域、操作内容を確認してください。
2. まず docs/project-config.json を読みます。これはプロジェクトの機械可読なマップです。 このリポジトリにおける唯一の信頼できる情報源です（モジュール／パス、フレームワークと検索キーワード、テスト／E2E／統合テストの実行コマンド、デザインシステム、アーキテクチャルール、ワークフローパターン）。調査、計画、コーディングの前に、正確なパス、実行コマンド、規約の根拠として参照してください。フレームワークの既定値を決めつけないでください（CLAUDE.md とリファレンスドキュメントはこのファイルから派生しています）。このファイル、またはドキュメントインデックス、lessons.md、CLAUDE.md、AGENTS.md、必須のリファレンスドキュメントが存在しないか古くなっている場合は、まず $project-init または対象を絞ったルート（$project-config、$docs-init、$scan-all、$scan --target=<key>、$claude-md-init）を自動実行してください。Codex のミラーまたは AGENTS.md が古くなっている場合は、ユーザーに $sync-codex の実行を依頼してください（自動実行は禁止です）。
3. トリガーごとの必須ドキュメント：常に docs/project-reference/lessons.md；ドキュメント検索 docs-index-reference.md；レビュー code-review-rules.md；バックエンド／CQRS／API backend-patterns-reference.md；ドメイン／エンティティ domain-entities-reference.md；フロントエンド／UI frontend-patterns-reference.md；スタイル／デザイン scss-styling-guide.md + design-system/design-system-canonical.md；統合テスト integration-test-reference.md；E2E e2e-test-reference.md；機能ドキュメント／仕様 feature-spec-reference.md + spec-system-reference.md + spec-principles.md；動作／公開コントラクト／仕様／テストコードの同期 workflow-spec-test-code-cycle-reference.md；派生仕様インデックス／ERD／再実装ガイド spec-system-reference.md + docs/specs/ 配下の元となる機能仕様；アーキテクチャ／新しい領域 project-structure-reference.md。
4. 必須ドキュメントをすべて読み、対象作業に入る前に次のように明記してください：Reference docs read: ... | Not applicable: ...。

準備完了の条件： 対象範囲を評価し、docs/project-config.json を参照し、必須ドキュメントを確認・読了するか初期設定ルートを完了し、lessons.md を確認し、参照情報を明記していること。 クロススタック影響の追跡 — 最初のレビューアクション：変更を全体として理解してから、ファイルを評価します。レビュー対象のすべての差分について、変更の背景を記録し、主な影響範囲のパイプライン全体をクライアント↔サーバー間の境界をまたいでエンドツーエンドで追跡し、一方の層への変更がもう一方の層を気付かないうちに壊すことがないようにします。（SYNC:cross-service-check とは異なり、そちらがサービス間／イベント境界を担当するのに対し、こちらは1つのアプリ内のクライアント↔サーバー層の境界を担当します。パイプライン全体を網羅するには両方を組み合わせてください。）

1. まず変更の背景を理解する — ファイルごとのレビューに入る前に、短い 変更の背景 を記述します。変更内容、意図（理由）、変更の起点となる層（フロントエンド／バックエンド／共有／インフラ）、主な影響を受ける機能／フローを記載します。問題点を指摘する前に行ってください。
2. クロススタックの境界を特定する — 主な影響範囲について、クライアントとサーバー間の契約境界を特定します。API ルート／エンドポイントと HTTP メソッド、リクエスト／レスポンス DTO またはペイロードの形状、共有型／スキーマ、イベント／メッセージ契約、クエリ／ルートパラメーターなどです。docs/project-config.json とプロジェクトの規約から層の構成を推測します。
3. 変更の方向に沿ってパイプライン全体をエンドツーエンドで追跡する：
   • バックエンドの変更 → すべてのフロントエンドの利用箇所まで順方向に追跡： ハンドラー／コントローラー → レスポンス DTO／シリアライザー → API クライアント／サービス → ストア／状態 → コンポーネント／テンプレートでの表示または送信。
   • フロントエンドの変更 → バックエンド契約まで逆方向に追跡： コンポーネント／フォーム → API クライアント呼び出し → ルート／エンドポイント → リクエスト DTO／検証 → ハンドラー／ドメイン。
   • .code-graph/graph.db がある場合は、$graph-connect-api と python .claude/scripts/code_graph trace <file> --direction both --json を使って接続関係を把握します。ない場合は、両方の層でルートパス、DTO／型名、各フィールド名を grep します。
4. 両側の整合性を確認する — 変更された境界ごとに、もう一方の層との整合性を確認します。ルートパスと HTTP メソッド、フィールド名と型、null 許容性／省略可能性、必須／省略可能なパラメーター、列挙値、認証／権限、エラー／ステータスの形式を確認してください。不整合はすべて 破壊的変更 として指摘します（バックエンドの変更がフロントエンドの利用箇所を壊す場合、またはフロントエンドがバックエンドで拒否される値を送るようになった場合）。
5. 境界を分類する： NONE（契約変更なし）／ADDITIVE（後方互換性あり）／BREAKING（もう一方の層の利用側も変更が必要）。もう一方の層の利用側が同じ差分で更新されていない BREAKING な境界は、少なくとも HIGH の重要度とします（認証／金銭／データ整合性に関わる経路では CRITICAL）。

スキップできるのは、クロスレイヤーの境界がない変更に限ります。純粋なドキュメント、データ契約を伴わない純粋なスタイル変更、または単一層のツールが該当します。次のように明記してください：Single-tier change — no cross-stack seam。バックエンドのみのリポジトリ、または単一層のリポジトリでも、内部の利用箇所を追跡します（サービス／イベント境界には SYNC:cross-service-check を使用）。

次の条件を満たすまで BLOCKED： 変更の背景を記録済み · 境界を特定済み、または明示的に N/A と記載済み · 変更の方向に沿ってパイプライン全体を追跡済み · 変更されたすべての境界を NONE／ADDITIVE／BREAKING に分類済み。 サービス横断チェック — マイクロサービス／イベント駆動型の場合、調査、計画、仕様書、機能ドキュメントを確定する前に必ず実施します。下流のコンシューマーを見落とすと、気づかれないままリグレッションが発生します。

境界	grep 用語
イベントプロデューサー	Publish, Dispatch, Send, emit, EventBus, outbox, IntegrationEvent
イベントコンシューマー	Consumer, EventHandler, Subscribe, @EventListener, inbox
Saga／オーケストレーション	Saga, ProcessManager, Choreography, Workflow, Orchestrator
同期サービス呼び出し	他サービスとの HTTP／gRPC 呼び出し
共有コントラクト	OpenAPI 仕様、proto、共有 DTO — 破壊的変更にフラグを立てる
データの所有権	他サービスが同じテーブル／コレクションを読み書きしている → Shared-DB アンチパターン

各タッチポイントで確認する項目： 所有サービス · メッセージ名 · コンシューマー · リスク（NONE / ADDITIVE / BREAKING）。

次の確認が完了するまでブロック： プロデューサーの調査 · コンシューマーの調査 · Saga の確認 · コントラクトのレビュー · 破壊的変更リスクへのフラグ付け

タスク追跡と外部レポートの永続化 — 実行前にこれを準備し、その後、対象／ソースの作業に着手する前にプロジェクト参照ドキュメントを事前取得します。

1. 対象ファイルの読み取り、grep、編集、分析の前に、簡潔なタスクの内訳を作成します。コンテキストを失った場合は、まず現在のタスクリストを確認します。
2. 作業を開始する前にタスクを 1 つ in_progress にし、根拠を得たら直ちに completed にします。状態の変更をまとめて行ってはいけません。
3. 計画／レビュー作業では、最初の所見を得る前に plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md を作成します。
4. 各ファイル／セクション／判断の確認後に所見を追記し、最後にレポートファイルをもとにまとめます。
5. 最終出力には Full report: plans/reports/{filename} を記載します。

次の確認が完了するまでブロック： タスクの内訳が存在すること、計画／レビュー作業のレポートパスが宣言されていること、次の所見に進む前に最初の所見が保存されていること。

批判的思考の姿勢 — 批判的思考と順序立てた思考を適用します。すべての主張には追跡可能な証拠が必要であり、行動に移すには確信度が 80% を超えている必要があります。 ハルシネーション対策： 推測を事実として提示してはいけません。すべての主張に出典を示し、不確実性があれば率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信度にも懐疑的でいてください。証拠のない確信こそが、あらゆるハルシネーションの根本原因です。 Sequential Thinking Protocol — 複雑または曖昧な作業のための、構造化された多段階推論です。一度の推論で進めるのが危険な、計画、レビュー、デバッグ、アイデアの精緻化に使用します。

使用するタイミング： 複雑な問題の分解 · 修正が必要な適応型計画 · 軌道修正を伴う分析 · 不明確または発展中の範囲 · 多段階の解決策 · 仮説駆動型デバッグ · 分野横断的なトレードオフ評価。

形式（明示モード — 思考の軌跡を表示）：

1. Thought N/M: [aspect] — 1つの思考につき1つの観点を扱い、前提や不確実性を明示します
2. Thought N/M [REVISION of Thought K]: ... — 以前の推論が無効になった場合に使用します。Original / Why revised / Impact を明示します
3. Thought N/M [BRANCH A from Thought K]: ... — 代替案を検討し、判断理由を示して結論をまとめます
4. Thought N/M [HYPOTHESIS]: ... に続けて [VERIFICATION]: ... — 実行前に検証します
5. Thought N/N [FINAL] — 検証済みで、重要な観点をすべて扱い、確信度が80%を超える場合に限ります

必須の締めくくり： 確信度（%）を明記 · 前提を列挙 · 未解決の質問を提示 · 具体的な次のアクションを示す。

停止条件： 重要な判断の確信度が80%未満 → ユーザーに直接質問してエスカレーションします · 同じ思考を3回以上修正 → 問題を再定義します · 分岐数が3を超える → サブタスクに分割します。

暗黙モード： マーカーを追加すると回答が煩雑になる場合（推論が正確さに役立つ日常的な作業）は、マーカーを表示せずにこの方法論を内部で適用します。

詳細： $sequential-thinking スキル（.claude/skills/sequential-thinking/SKILL.md）を参照してください。実例（API 設計、デバッグ、アーキテクチャ）、高度な手法（段階的な精緻化、仮説検証、収束）、メタ戦略（不確実性への対処、修正の連鎖）が掲載されています。

AI Mistake Prevention — あらゆるタスクで避けるべき失敗パターン：

コンテキストが変化した後は、ファイルを読み直します。 コンテキストの圧縮、中断後の再開、長時間にわたる作業によって、記憶が古くなっている可能性があります。行動する前に、ファイルの現状を確認します。 生成した内容を、根拠となるソースと照合して検証します。 AI は API、名前、主張、ドキュメントの事実を幻覚することがあります。記載または参照する前に、該当するソースを確認します。 削除または名前変更する前に、後続の参照を確認します。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元が古くなる可能性があります。まず参照先を洗い出します。 編集後は、影響の連鎖全体をたどります。 定義を変更すると、派生出力や利用側への影響を見落とすことがあります。完了を宣言する前に、影響を受ける連鎖を追跡します。 最初の出力だけでなく、影響を受ける出力をすべて検証します。 チェックが1つ成功しても、すべて成功したとは限りません。変更の影響を受ける可能性があるすべての出力面を検証します。 既存の値は意図的なものと考え、変更または不具合として指摘する前に、なぜそうなっているのかを確認します。 定数、上限、フラグ、しきい値、文言、パターンを変更または報告する前に、近接するコンテキストと履歴、呼び出し元の処理順序、同じ規約を使う2か所以上の類似した呼び出し箇所を確認します。WHAT（何をするか）だけを記し、WHY（なぜそうするか）を記していないドキュメントは、根拠の説明が不足しているのであり、ガードが欠けている証拠ではありません。 行動する前に曖昧さを明らかにし、黙って選択しません。 複数の妥当な解釈がある場合は、明示的に質問するか、リスクを伴う前提を明記します。 インフラが管理する中間状態ではなく、システムが担う結果を検証します。 非同期処理を検証するときは、最終的なビジネス状態を確認します。共有インフラ上で実行中の他プロセスも書き込める、配信や再試行に関する記録は決して検証対象にしません。そのようなチェックは単独実行では成功しても、同じインフラをほかの処理と共有した途端に不安定になります。 共有ガイダンスは、対象となる役割に関連する内容に保ちます。 普遍的なガイダンスは、それを受け取るすべてのスキルやエージェントに役立つものでなければなりません。コード固有の要件は、コード固有のプロトコルにのみ記載します。 エビデンスに基づく推論 — 憶測は禁止です。すべての主張に証拠が必要です。

1. すべての主張について、file:line、grep の結果、またはフレームワークのドキュメントを引用してください
2. 確信度を明示してください：80%超なら自由に進めてよく、60〜80%なら先に検証し、60%未満なら推奨してはいけません
3. アーキテクチャの変更には、サービスをまたいだ検証が必要です
4. 「証拠が十分ではありません」は、妥当であり、期待される出力です

以下が完了するまで作業はブロックされます： - [ ] 証拠となるファイルパス（file:line） - [ ] grep 検索の実施 - [ ] 類似パターンを3つ以上確認 - [ ] 確信度の明示

証拠なしでの使用は禁止： 「明らかに」「私はこう思います」「〜のはずです」「おそらく」「これが原因です」 未完了の場合 → 次を出力してください："証拠が不十分です。検証済み：[...]。未検証：[...]。"

検証済みの指摘の修正と全体再レビューのループ — 再レビューはラウンド数ではなく、検証済みの指摘を修正するサイクルによって開始されます。レビューの目的：レビュー → 指摘の検証 → 検証済みの指摘を修正 → 全体再レビュー。ラウンドの終了基準を満たす完全なレビューが完了するまで繰り返します（以下の重大度の下限を参照）。クリーンなレビューが完了した時点でループは終了します。以降のラウンドは不要です。

別名 セルフレビュー収束ループ。 これは歴史的な名称です。2ラウンドの上限はありません。「ダブルラウンドトリップ」とは、検証済みの指摘を修正すると、少なくとも1回の新たな再レビューが必要になるという意味にすぎません。以下の3ラウンド上限の範囲内で、クリーンなレビューが完了するまで続けます。

ラウンド上限 — 最大3ラウンド（上限であり、目標ではありません）。 どのラウンドでも、クリーンなレビューが完了した時点でループは直ちに終了します。ラウンド1も例外ではありません。上限は、作業を続ける義務を課すものではありません。重大度の下限を適用したうえで、ブロッキング指摘が残ったままラウンド3に達した場合は、停止し、未解決の指摘を列挙してユーザーに直接確認し、エスカレーションしてください。上限に達したからといって、何も伝えずに「十分良好」として PASS を出してはいけません。また、上限をクリーンなレビューの要件の代わりにしてはいけません。進展がない状態が2回続いた場合のブロッカールールは、引き続き先に適用されます。どちらかが先に発生した時点でエスカレーションしてください。

重大度の下限 — ラウンド3から、LOW はブロッキング対象外になります。 終了基準はラウンドごとに厳しくなります。これにより、仕上げのためにループを繰り返すのではなく、影響度に基づいて収束させます。 すべての箇所で述語を1つだけ定義します。blocking_findings(round, findings) は、ラウンド1〜2では検証済みのすべての指摘事項を返し、ラウンド3以降では検証済みのCRITICAL／HIGH／MEDIUMの指摘事項のみを返します。二値ゲート（テスト合格、セキュリティ上の必須修正、必須成果物）は、それを所有する不変条件で明示的に免除されている場合に限り、対象外です。

ラウンド	終了基準 — 新しい全件レビューが以下を満たしたらループ終了	続行するために修正必須
1-2	重大度を問わず、検証済みの指摘事項がゼロ	CRITICAL · HIGH · MEDIUM · LOW
3+	検証済みのCRITICAL／HIGH／MEDIUMの指摘事項がゼロ — LOWのみなら合格	CRITICAL · HIGH · MEDIUMのみ

ラウンド3以降、LOWの指摘事項は修正必須ではありません。検証済みの指摘事項がすべてLOWのラウンドは、ループをただちに終了します。それらを理由に次のラウンドを開始してはいけません。重大度の区分はSYNC:severity-rubric（CRITICALはマージをブロック · HIGHは必須修正 · MEDIUMは修正推奨 · LOWは可能なら修正）に従います。ラウンド1〜2の基準は変わらないため、簡単に直せるLOWも、早い段階で修正します。

重大度下限ルール：

• 保留したLOWを黙って除外してはいけません。 修正されていないLOWはすべて、ファイル、行、説明とともに最終レポートの## Deferred LOW Findings (severity floor, round ≥3)に記載し、担当者が対応を予定できるようにします。レポートから除外することは、クリーンな合格ではなくプロトコル違反です。
• 終了条件を満たすために指摘事項の区分を下げてはいけません。 実際にはCRITICAL／HIGH／MEDIUMである指摘事項をLOWに格下げしてループを終了するのは、誤った合格です。重大度はSYNC:severity-rubricに従い、終了基準を適用する前に、影響度に基づいて決めます。適用後に決めてはいけません。また、終了を意識して決めてもいけません。理由：ラベルを付け替えれば到達できる下限は、下限ではありません。
• 下限が制約するのはループであり、基準ではありません。 下限は_反復_を終了させるものであり、既知のCRITICAL／HIGH／MEDIUMを含む状態でのリリースを許可するものではありません。また、指摘事項を採用する際の指摘事項存続基準を引き下げるものでもありません。
• 下限はハードゲートには適用されません。 テスト合格ゲート（テストスイートが実際に合格する必要があります）、セキュリティ上の必須修正ゲート、および重大度ではなく二値の基準を持つゲートは影響を受けません。テスト失敗は失敗であり、LOWの指摘事項ではありません。

全般的な適用範囲（新たな出力／判断すべて）： 新たに作成した出力や判断には、少なくとも1回のセルフレビューが必要です。新たな判断には、少なくとも1回の$why-review --validate-findingsパスが必要です。再確認の対象として指摘されたものは、その出力を最終版として扱う前に、少なくとも1回再確認します。このループは、レビュー用スキルだけでなく、成果物を作成するあらゆるスキルに適用されるデフォルトの収束契約です。

ルーティング不変条件（スキル作成者向け）： 指摘事項を検証するスキルは、それらを必ず$why-review --validate-findings（最終バリデーター）に渡す必要があります。インラインの指摘事項検証を独自に実装してはいけません。why-reviewを経由することで、指摘事項存続基準とこのループが適用されます。verify-review-validate-coverageセンサーは、このルートが使われていることを機械的に検証します。

ラウンド1： メインセッションでレビューします。対象ファイルを読み、内容を把握し、問題点を記録します。指摘事項と判定（PASS／FAIL）を出力します。

ラウンド1後の判断：

• 問題なし（PASS、指摘事項ゼロ） → レビューを終了します。確認のために新しいサブエージェントを起動してはいけません。
• blocking_findings(round, findings)が空でない → まず、使用中のレビュー用スキルの指摘事項検証ゲートを実行します。レビュー用スキルのデフォルトゲートは$why-review --validate-findings <report-path>です。検証済みの指摘事項のみを修正し、その後、新しいタスク分解を使ってレビュー手順を最初からやり直します。

修正サイクルのたびに、新しい全件レビューを行います： 現在の対象全体に対し、レビュー手順を最初から実行します。その手順でサブエージェントを使用する場合は、spawn_agentを新たに呼び出してください。以前のエージェントを再利用してはいけません。レビュアーは、前のラウンドの記憶を一切持たず、すべてのファイルを最初から読み直します。起動方法についてはSYNC:fresh-context-review、標準のAgentプロンプトテンプレートについてはSYNC:review-protocol-injectionを参照してください。新しい全件レビューでは、次の点を必ず検出します。

• 前のラウンドで見落とされた横断的な問題
• 変更したファイル間の相互作用によるバグ
• 規約からの逸脱（新しいコードと既存パターンとの不整合）
• 存在すべきなのに欠けている要素
• 前のラウンドで合理化され、見過ごされた微妙なエッジケース
• 修正自体が引き起こしたリグレッション

ループの終了： 全件レビューを再実施するたびに、そのラウンドの終了基準に照らして同じ判断を繰り返します。基準を満たしたら終了し、ブロッキング指摘事項が残っていれば、指摘事項を検証し、修正して、最初のレビュー段階からやり直します。ラウンド1〜2では、重大度を問わず指摘事項がゼロなら終了です。ラウンド3以降はCRITICAL／HIGH／MEDIUMがゼロなら終了するため、LOWのみのラウンドでループを終了します（保留するLOWはレポートに記載します）。上限は3ラウンドです。次のいずれかが先に発生した時点で、ユーザーに直接確認を求めてください。同じ検証済み指摘事項が、進展のないまま2回の全件実行で繰り返される · 修正にプロダクト担当者またはオーナーの判断が必要 · ラウンド3終了時点でもCRITICAL／HIGH／MEDIUMが未解決。3ラウンドを超えてループしてはいけません。また、上限到達を合格として扱ってはいけません。

ルール：

• クリーンなラウンド1でレビューを終了します。ラウンド2の実施は必須ではありません。
• ラウンド3以降、検証済みの指摘事項がすべてLOWのラウンドはループを終了します。LOWだけを修正するために次のラウンドを開始してはいけません。その代わり、LOWを保留として記載します。
• ラウンド3の終了条件を満たすために、CRITICAL／HIGH／MEDIUMをLOWに格下げしてはいけません。重大度は基準の適用前に、影響度に基づいて割り当てます。
• 未検証の指摘事項を修正してはいけません。まず、呼び出し元が指定する検証ゲートを使って検証します。
• 存続する各指摘事項は、why-reviewの指摘事項検証ルーチンで定義される指摘事項存続基準も満たす必要があります。この基準は一般的な行動判断ゲートより意図的に厳しく設定されています。「この指摘事項を残すか」は「この証拠に基づいて対応するか」より厳しい問いです。基準未満の指摘事項は、そのまま残さず、格下げするか削除します。
• 修正サイクル後の全件レビューを省略してはいけません（修正のたびに、それ以前の判定は無効になります）。
• ラウンドをまたいでサブエージェントを再利用してはいけません。サブエージェントを使う反復ごとに、新しいAgent呼び出しを起動します。
• メインエージェントはサブエージェントのレポートを読みますが、指摘事項を選別、再解釈、または覆してはいけません。
• 3ラウンドの上限が、クリーンなレビューの要件に取って代わることはありません。上限は暴走するループを抑えるためのものであり、レビューがクリーンでないままリリースすることを許可するものではありません。クリーンな合格なら、どのラウンドでもループを早期終了できます。上限に達した場合は、合格ではなくエスカレーションします。
• 3ラウンドの上限と、進展のない状態が2回繰り返された場合のブロッカールールを併せて適用します。どちらもエスカレーションのトリガーであり、完了条件ではありません。
• 再帰的な呼び出し回数と、繰り返し発生するブロッカーを、会話コンテキスト内で追跡します（セッションの範囲内）。
• 最終判定には、実行したすべてのラウンドを反映します。

レポートには、実行したラウンドN≥2ごとに## Round N Findings (Fresh Sub-Agent)を含めます。また、LOWが未解決のままラウンド3以降の終了基準でループが終了した場合は、## Deferred LOW Findings (severity floor, round ≥3)を必ず含めます。 新鮮なコンテキストでの再レビュー — 該当する場合は独立したサブエージェントを使ってレビュー全体を最初からやり直し、修正後にオーケストレーターの確証バイアスを排除します。

理由： メインエージェントは、自身（または $feature-implement）が直前に修正した内容を把握しているため、それに合わせて指摘を合理化します。まっさらなサブエージェントには記憶がなく、最初から読み直すため、メインエージェントが退けた問題を見つけられます。サブエージェントのバイアスは、（1）新鮮なコンテキスト、（2）プロトコルの逐語的な埋め込み、（3）メインエージェントがレポートを取捨選択しないことによって軽減されます。

実施するタイミング： 検証済みの指摘事項を修正したサイクルの後に限ります。問題が一つも見つからなかったレビューラウンドでループは終了するため、確認用のサブエージェントを起動してはいけません。問題が見つかったレビューラウンドでは、指摘事項を検証 → 修正 → 最初のフェーズからレビュー全体をやり直します。

手順：

1. レビュー全体の新しい呼び出し／タスク分解を開始します。プロトコルでエージェントの起動が求められる場合は、新しい spawn_agent ツール呼び出しを行います。コードレビューには code-reviewer エージェントタイプを、計画／ドキュメント／成果物のレビューには general-purpose を使用します。
2. 必要なレビュー用プロトコルをすべてプロンプトに逐語的に埋め込みます。完全な一覧とテンプレートについては SYNC:review-protocol-injection を参照してください。プロトコルをファイルパスで参照してはいけません。ファイル読み込みを介した間接参照では、AI の準拠率が低下します（SYNC:shared-protocol-duplication-policy を参照）。
3. サブエージェントは自身のツール呼び出しで対象ファイルをすべて最初から読み直します。ファイル内容をプロンプトに直接渡してはいけません。
4. サブエージェントは、構造化されたレポートを plans/reports/{review-type}-round{N}-{date}.md に書き込みます。
5. メインエージェントはレポートを読み、指摘事項を自身のレポートに反映します。指摘事項を覆したり、取捨選択したりしてはいけません。

ルール：

• 直前のレビュー全体で問題が一つも見つからなかった場合、新鮮なサブエージェントを省略します（修正がなければ、新たに検証することもありません）。
• 修正サイクルの後にレビュー全体をやり直すことを省略してはいけません。修正を行うたびに、それ以前の判定は無効になります。
• ラウンドをまたいでサブエージェントを再利用してはいけません。新しいラウンドごとに、新しい spawn_agent 呼び出しを行います。
• SYNC:double-round-trip-review に定められた終了基準をそのラウンドで満たすまで続けます。ラウンド1～2では、重大度を問わず指摘事項がゼロであること。ラウンド3以降では、CRITICAL／HIGH／MEDIUM の指摘事項がゼロであること。このため、検証済みの指摘事項がすべて LOW であるラウンドではループを終了し、それらの LOW は次回以降に持ち越す項目として列挙して、次のラウンドを開始してはいけません。同じ阻害要因が進展なく3回繰り返された場合は、ユーザーに直接確認してエスカレーションします。
• 反復回数と繰り返し発生している阻害要因は、会話コンテキスト内で追跡します（セッション単位。永続ファイルは使用しません）。

レビュー用プロトコルの埋め込み — 新しいサブエージェントのレビュー用プロンプトには、11個のプロトコルブロックを逐語的に埋め込む必要があります。以下のテンプレートには、11個すべての本文がすでに展開されて埋め込まれています。実行時には、テンプレート全体を Agent 呼び出しの prompt フィールドにそのままコピーし、Task／Round／Reference Docs／Target Files／Output セクションにある {placeholders} のみ、状況に応じた値に置き換えてください。埋め込まれたプロトコルセクションには手を加えてはいけません。

本文をインラインで展開する理由： プレースホルダーマーカーを使うと、実行時にファイル読み込みを介した間接参照が必要になります。間接参照を挟むと AI の準拠率が大幅に低下します（SYNC:shared-protocol-duplication-policy を参照）。そのため、テンプレートには11個すべてのプロトコル本文があらかじめ埋め込まれています。

サブエージェントタイプの選択

• code-reviewer — コードレビュー（ソースファイル、git diff、実装のレビュー）
• general-purpose — 計画／ドキュメント／成果物のレビュー（Markdown の計画書、ドキュメント、仕様書のレビュー）

標準 Agent 呼び出しテンプレート（逐語的にコピー）

spawn_agent({
  description: "Fresh Round {N} review",
  agent_type: "code-reviewer",
  prompt: `
## Task
{review-specific task — e.g., "Review all uncommitted changes for code quality" | "Review plan files under {plan-dir}" | "Review integration tests in {path}"}

## Round
Round {N}. You have ZERO memory of prior rounds. Re-read all target files from scratch via your own tool calls. Do NOT trust anything from the main agent beyond this prompt.

## Protocols (follow VERBATIM — these are non-negotiable)

### Spec ↔ Tests ↔ Code Triangulation
DO THIS FIRST — before any per-protocol check below. The review target is the WHOLE PACKAGE, not the diff alone: load the behavior's spec (§3 ACs / §4 BRs / §8 TCs), its tests, and the changed code TOGETHER, and reason about their mutual consistency BEFORE judging any one in isolation.
1. Locate all three faces: the Feature Spec section(s) governing the changed behavior, the tests that guard it, and the production code that implements it. A missing face is itself a finding (SPEC-GAP / TEST-GAP / DEAD-SPEC).
2. Triangulate pairwise — every disagreement is a finding; classify which face is wrong:
   - code vs spec: behavior the code does that no §3/§4/§8 rule describes → CODE-EXTRA or SPEC-STALE; a [HARD] §4 rule or §5 invariant with no enforcing code path → CODE-WRONG.
   - tests vs spec: a §8 TC with no test, or a test asserting behavior no TC/rule names → TEST-GAP or SPEC-SILENT.
   - tests vs code: a changed code path with no covering test → TEST-GAP; a test that still passes against a deliberately broken invariant → WEAK-TEST (apply the mutation thinking in Bug Detection).
3. Hidden-rule capture: any invariant the code enforces but the spec never states (SPEC-SILENT) MUST be surfaced as a finding to add into §3/§4/§8 AND guarded with a test — the enrichment loop, never a silent pass.
4. Only after the three faces agree — or every disagreement is logged as a finding — proceed to the per-protocol checks below; when enrichment adds spec/test content, re-review the package against the enriched spec.
NEVER mark review PASS while any spec/test/code face disagrees without a logged finding. The diff is the entry point; the package is the unit of judgment.

### Evidence-Based Reasoning
Speculation is FORBIDDEN. Every claim needs proof.
1. Cite file:line, grep results, or framework docs for EVERY claim
2. Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend
3. Cross-service validation required for architectural changes
4. "I don't have enough evidence" is valid and expected output
BLOCKED until: Evidence file path (file:line) provided; Grep search performed; 3+ similar patterns found; Confidence level stated.
Forbidden without proof: "obviously", "I think", "should be", "probably", "this is because".
If incomplete → output: "Insufficient evidence. Verified: [...]. Not verified: [...]."

### Bug Detection
MUST check categories 1-4 for EVERY review. Never skip.
1. Null Safety: Can params/returns be null? Are they guarded? Optional chaining gaps? .find() returns checked?
2. Boundary Conditions: Off-by-one (< vs <=)? Empty collections handled? Zero/negative values? Max limits?
3. Error Handling: Try-catch scope correct? Silent swallowed exceptions? Error types specific? Cleanup in finally?
4. Resource Management: Connections/streams closed? Subscriptions unsubscribed on destroy? Timers cleared? Memory bounded?
5. Concurrency (if async): Missing await? Race conditions on shared state? Stale closures? Retry storms?
6. Stack-Specific: Check the configured language/runtime pitfalls and framework-specific failure modes discovered from local code.
Classify: CRITICAL (crash/corrupt) → FAIL | HIGH (incorrect behavior) → FAIL | MEDIUM (edge case) → WARN | LOW (defensive) → INFO.

### Design Patterns Quality
Priority checks for every code change:
1. DRY via OOP: Same-suffix classes (*Entity, *Dto, *Service) MUST share base class. 3+ similar patterns → extract to shared abstraction.
2. Right Responsibility: Logic in LOWEST layer (Entity > Domain Service > Application Service > Controller). Never business logic in controllers.
3. SOLID: Single responsibility (one reason to change). Open-closed (extend, don't modify). Liskov (subtypes substitutable). Interface segregation (small interfaces). Dependency inversion (depend on abstractions).
4. After extraction/move/rename: Grep ENTIRE scope for dangling references. Zero tolerance.
5. YAGNI gate: NEVER recommend patterns unless 3+ occurrences exist. Don't extract for hypothetical future use.
Anti-patterns to flag: God Object, Copy-Paste inheritance, Circular Dependency, Leaky Abstraction.

### Logic & Intention Review
Verify WHAT code does matches WHY it was changed.
1. Change Intention Check: Every changed file MUST serve the stated purpose. Flag unrelated changes as scope creep.
2. Happy Path Trace: Walk through one complete success scenario through changed code.
3. Error Path Trace: Walk through one failure/edge case scenario through changed code.
4. Acceptance Mapping: If plan context available, map every acceptance criterion to a code change.
5. Tests Verify Intent: For test/spec changes, verify tests name the protected business rule or invariant and would fail if that intent breaks.
6. Migration Test Exclusion: Do not write tests for migration code. Schema/data migrations are one-time execution paths, not core application logic.
NEVER mark review PASS without completing both traces (happy + error path).

### Test Spec Verification
Map changed code to test specifications.
1. Identify the project's test/spec format from existing docs, test-case files, BDD feature files, or spec folders.
2. Every changed code path MUST map to a corresponding test case/spec (or flag as "needs test case").
3. New functions/endpoints/handlers → flag for test spec creation.
4. Migration files are excluded from test/spec creation; schema/data migrations are one-time execution paths, not core application logic.
5. If spec evidence fields exist, verify they point to actual code (file:line, not stale references).
6. Verify each meaningful test case names the business intent/invariant; flag behavior-only cases that only mirror implementation details.
7. Auth/data changes → verify corresponding authorization and data-state test cases exist.
8. If no specs exist for a changed path → log the gap and recommend the project's test-spec workflow.
NEVER skip test mapping. Untested code paths are the #1 source of production bugs.

### Behavioral Delta Matrix
MANDATORY for any bugfix review. Produce input-state × pre-fix × post-fix × delta table BEFORE writing verdict.
- Minimum 3 rows; include at least one row OUTSIDE the original bug report.
- Any "REGRESSION" delta → review returns FAIL until a preservation test is added.
- Narrative descriptions do NOT substitute for the matrix.
Example rows (external-record sync fix):
| Input                 | Pre-fix | Post-fix                  | Delta      |
| --------------------- | ------- | ------------------------- | ---------- |
| Record exists (valid) | Reused  | Always recreated → orphan | REGRESSION |
| Record missing (404)  | Error   | Recreated                 | Fixed      |

### Fix-Layer Accountability
NEVER fix at the crash site. Trace the full flow, fix at the owning layer. The crash site is a SYMPTOM, not the cause.
MANDATORY before ANY fix:
1. Trace full data flow — Map the complete path from data origin to crash site across ALL layers (storage → backend → API → frontend → UI). Identify where bad state ENTERS, not where it CRASHES.
2. Identify the invariant owner — Which layer's contract guarantees this value is valid? Fix at the LOWEST layer that owns the invariant, not the highest layer that consumes it.
3. One fix, maximum protection — If fix requires touching 3+ files with defensive checks, you are at the wrong layer — go lower.
4. Verify no bypass paths — Confirm all data flows through the fix point. Check for direct construction skipping factories, clone/spread without re-validation, raw data not wrapped in domain models, mutations outside the model layer.
BLOCKED until: Full data flow traced (origin → crash); Invariant owner identified with file:line evidence; All access sites audited (grep count); Fix layer justified (lowest layer that protects most consumers).
Anti-patterns (REJECT): "Fix it where it crashes" (crash site ≠ cause site, trace upstream); "Add defensive checks at every consumer" (scattered defense = wrong layer); "Both fix is safer" (pick ONE authoritative layer).

### Rationalization Prevention
AI skips steps via these evasions. Recognize and reject:
- "Too simple for a plan" → Simple + wrong assumptions = wasted time. Plan anyway.
- "I'll test after" → RED before GREEN. Write/verify test first.
- "Already searched" → Show grep evidence with file:line. No proof = no search.
- "Just do it" → Still need task tracking. Skip depth, never skip tracking.
- "Just a small fix" → Small fix in wrong location cascades. Verify file:line first.
- "Code is self-explanatory" → Future readers need evidence trail. Document anyway.
- "Combine steps to save time" → Combined steps dilute focus. Each step has distinct purpose.

### Graph-Assisted Investigation
MANDATORY when .code-graph/graph.db exists.
HARD-GATE: MUST run at least ONE graph command on key files before concluding any investigation.
Pattern: Grep finds files → trace --direction both reveals full system flow → Grep verifies details.
- Investigation/Scout: trace --direction both on 2-3 entry files
- Fix/Debug: callers_of on buggy function + tests_for
- Feature/Enhancement: connections on files to be modified
- Code Review: tests_for on changed functions
- Blast Radius: trace --direction downstream
CLI: python .claude/scripts/code_graph {command} --json. Use --node-mode file first (10-30x less noise), then --node-mode function for detail.

### Understand Code First
HARD-GATE: Do NOT write, plan, or fix until you READ existing code.
1. Search 3+ similar patterns (grep/glob) — cite file:line evidence.
2. Read existing files in target area — understand structure, base classes, conventions.
3. Run python .claude/scripts/code_graph trace <file> --direction both --json when .code-graph/graph.db exists.
4. Map dependencies via connections or callers_of — know what depends on your target.
5. Write investigation to .ai/workspace/analysis/ for non-trivial tasks (3+ files).
6. Re-read analysis file before implementing — never work from memory alone.
7. NEVER invent new patterns when existing ones work — match exactly or document deviation.
BLOCKED until: Read target files; Grep 3+ patterns; Graph trace (if graph.db exists); Assumptions verified with evidence.

## Reference Docs (READ before reviewing)
- `.claude/docs/development-rules.md` — canonical development rules, code-quality guidelines, and pre-commit checklist
- docs/project-reference/code-review-rules.md
- {skill-specific reference docs — e.g., integration-test-reference.md for integration-test-review; backend-patterns-reference.md for backend reviews; frontend-patterns-reference.md for frontend reviews}

## Target Files
{explicit file list OR "run git diff to see uncommitted changes" OR "read all files under {plan-dir}"}

## Output
Write a structured report to plans/reports/{review-type}-round{N}-{date}.md with sections:
- Status: PASS | FAIL
- Issue Count: {number}
- Critical Issues (with file:line evidence)
- High Priority Issues (with file:line evidence)
- Medium / Low Issues
- Cross-cutting findings

Return the report path and status to the main agent.
Every finding MUST have file:line evidence. Speculation is forbidden.
`
})

ルール

• 11 個のプロトコルセクションをすべて含め、テンプレートをそのままコピーしてください。
• Task／Round／Reference Docs／Target Files／Output セクションの {placeholders} のみ、状況に応じた内容に置き換えてください。
• コードレビューには code-reviewer、計画／ドキュメント／成果物のレビューには general-purpose の agent_type を選択してください。
• いずれのプロトコルセクションも言い換えたり、要約したり、省略したりしないでください。
• ファイルの内容をインラインで渡さないでください。サブエージェントは独自のツール呼び出しで読み込むため、新鮮なコンテキストを得られます。
• プロトコルをファイルパスやタグ名で参照しないでください。本文はすでに上に埋め込まれています。
• プロトコル用のプレースホルダーマーカーを導入しないでください。プロトコルは展開された状態のままにしてください。

グラフ影響分析 — .code-graph/graph.db が存在する場合は、blast-radius --json を実行して、変更の影響を受けるすべてのファイルを検出してください（7 種類のエッジ：CALLS、MESSAGE_BUS、API_ENDPOINT、TRIGGERS_EVENT、PRODUCES_EVENT、TRIGGERS_COMMAND_EVENT、INHERITS）。差分を計算します：impacted_files - changed_files = 変更漏れの可能性があるファイル。リスク：5 未満は低、5～20 は中、20 超は高。影響の大きいファイルの深い依存関係を調べるには、trace --direction downstream を使用してください。

重大度基準 — 修正の容易さではなく、結果に基づいてすべての指摘を分類してください。すべてのレビューで同じ尺度を使い、「高」がどこでも同じ意味になるようにします。

重大度	対応	定義
CRITICAL	マージをブロック	実行時に気づかれない障害、データ破損、検証の回避、セキュリティ上の脆弱性
HIGH	必ず修正	動作の誤り、不変条件の欠落、アーキテクチャ違反
MEDIUM	修正を推奨	設計上の負債、保守性の問題、将来バグになる可能性
LOW	修正すると望ましい	慣例、ドキュメント、軽微な明確さの問題

スコアベースのスキルでは、数値スケールをこれらの段階に対応付けてください。別の用語体系を作らないでください。

• 0～2 の基準スコア（例：production-readiness-review）：0 = CRITICAL/HIGH（基準未達で、本番環境への準備を妨げる）、1 = MEDIUM（部分的に達成、修正を推奨）、2 = 合格（指摘なし）。
• 2 軸スコア（例：パフォーマンスレビュー、影響度 × 発生可能性）：結果のセルを最も近い段階に対応付けます。影響度が高く、発生可能性も高い → CRITICAL/HIGH、影響度が低い、または発生可能性が低い → MEDIUM/LOW。

指摘の段階によってゲートが決まります。PASS の前に、CRITICAL/HIGH は解決するか、オーナーが明示的に受け入れる必要があります。MEDIUM/LOW は、追跡対象のフォローアップを設定したうえでリリースできます。 目標契約の充足ループ — ユーザーの目標を外部ファイルに保存して、それに基づいて実行し、保存されたすべての必須基準に合格するか、ブロッカーがエスカレーションされるまでレビューと修正を繰り返します。範囲を限定したクローズドループです。終わりのない自律的な探索は絶対に行いません。

1. 有効な目標を解決する（次の順）：有効な計画の goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → 現在のユーザーリクエストから新しい目標契約を作成する（テンプレート：.claude/templates/goal-contract-template.md）。
2. 必須セクション： Original Request、Purpose、Success Criteria（チェックボックス。必須か任意かを明記）、Constraints、Evidence Required、Iteration Log、Goal Satisfaction matrix。
3. 作業前： 有効な目標を読み、予定している作業を保存済みの成功基準に対応付けます。実行は保存済みの基準に基づいて行い、チャットの記憶だけに頼ってはいけません。
4. 実行／検証後： 結果、証拠の参照先（file:line、コマンド出力、レポートのパス）、残っているギャップを記載した Iteration Log のエントリーを追記します。
5. レビューチェックポイント： Goal Satisfaction matrix を出力します。形式は | Success Criterion | Evidence | Status | とし、ステータスは PASS／FAIL／BLOCKED とします。全体を PASS とするには、すべての必須基準が PASS である必要があります。
6. ループ規則（再試行）： 必須基準が FAIL → ギャップが実在することを検証 → 修正 → 影響を受ける基準のみ再レビュー。すべての必須基準が PASS になったら、適切に停止します。
7. エスカレーション規則（停止）： 基準に進展がない状態が2回連続する場合、またはユーザーの入力が必要なブロッカーがある場合は、ユーザー向けの理由を添えて基準を BLOCKED とし、エスカレーションします。無期限にループしてはいけません。
8. スキップ規則： 簡単な会話タスクでは、記録に一行の理由を残す場合に限り、目標ファイルを省略できます。ユーザーが承認したチェックポイントのスキップは、理由と範囲を添えて目標ファイルに記録します。
9. セキュリティ： 目標ファイルにシークレット、トークン、認証情報、顧客の個人データを保存してはいけません。証拠の参照先を記録し、機密情報の値はマスキングしてください。

以下を満たすまで先に進めません： 有効な目標を解決する（またはスキップ理由を記録する） · 編集前に保存済みの成功基準を読む · 実行後に反復の証拠を追記する · PASS 判定の前に Goal Satisfaction matrix を出力する トレードオフの確認ゲート — いかなる判定、スコア、指摘、推奨を出す前にも、必ず次の3つの質問を行ってください。レビュー対象そのものについてだけでなく、あなたが提示するすべての推奨についても同様です。理由：代償を示さずにメリットだけを挙げるのはレビューではなく、賛同です。最も大きな代償は、誰も書き留めなかったものです。

1. トレードオフはありますか？ 何を犠牲にするのかを明示してください。「なし」／「純粋なメリット」は分析未完了であり、回答ではありません。ないと主張する場合は、確認した観点と、それぞれに影響がない理由を述べてください：将来の変更コスト · 複雑さ · パフォーマンス／レイテンシー · メモリ／コスト · 結合度 · 可逆性 · 移行の負担 · 運用負荷 · 影響範囲 · セキュリティ態勢 · テスト容易性 · チームのスキル／習熟期間 · 提供までの時間 · UX。
2. それだけの価値はありますか？ 得られるもの（指標を含む） · かかるコスト · 誰が負担するか · いつ発生するかを明示して、メリットと代償を比較し、そのうえで 価値がある／価値がない／不明 と判定してください。指標もコストも示さない「より良い」は、この質問への回答として不合格です。「価値がない」場合は、そのまま推奨し続けず、撤回または代替してください。
3. そのトレードオフは、ユーザーに確認するだけの重要性がありますか？ 重要なトレードオフを決めるのはユーザーであり、あなたではありません。次のいずれかに該当する場合は重要です：不可逆／一方通行（データ移行、公開契約、ストレージ形式、ベンダーロックイン） · コストを他者に転嫁する（別チーム、運用／オンコール担当、将来のメンテナー、エンドユーザー） · ある品質特性を別の品質特性と引き換える（正確性↔速度、セキュリティ↔利便性、レイテンシー↔コスト、シンプルさ↔柔軟性） · 境界を越える（クライアント↔サーバー層、サービス契約、イベント契約、共有ライブラリ） · 重大な影響を伴う経路（認証、金銭、データ整合性、破壊的変更、残存リスクが高または中） · 価値の判定が不明。

重要 → 判定を確定させずに停止し、ユーザーに直接確認してください — トレードオフ、両方の選択肢、それぞれが犠牲にするもの、そしてあなたの推奨を示してください。重要でない → 1行の根拠とともにその場に記録し、続行してください。

質問できない実行コンテキスト — 黙って済ませず、引き継いでエスカレーションしてください。 ユーザーへの直接質問が届くのはメインの対話型エージェントだけです。サブエージェントはユーザーに質問できず、ターミナル／判定のみのモードは設計上、何も質問しません。そのようなコンテキストで実行している場合、義務は免除ではなく、転送されます。次のすべてを行ってください：(a) 質問1と2を通常どおり完了する。(b) 重要度を判定し、トレードオフ評価の行に confirmed? = NO — cannot ask from this context と記録する。(c) 未確認の重要なトレードオフを返却する要約／判定で明示し、呼び出し元（または親オーケストレーター）があなたに代わってユーザーに直接確認するようエスカレーションする — ディスク上のレポートファイル内だけで触れられた重要なトレードオフは、引き継ぎとはみなされません。(d) 無条件の PASS を出さない — 判定に未確認の重要なトレードオフがあると明記し、ユーザーが回答するまで呼び出し元のゲートが閉じたままになるようにする。呼び出し元は、あなたの返答を読んだ時点でエスカレーション義務を引き継ぎます。

この例外が対象とするのは到達可能性であり、利便性ではありません。ユーザーに実際に連絡できない場合（起動されたサブエージェント、ターミナルの検証／判定のみのモード、非対話型／ヘッドレス実行）に限り適用されます。質問を省略する、一方通行の変更を独断で承認する、質問が面倒だから重要度を下げる許可には決してなりません — 質問できるなら、必ず質問してください。

レビュー対象の判断ごと、および推奨ごとに、トレードオフ評価の行を出力してください：| decision | sacrifices | gain (metric) | who pays, when | WORTH IT/NOT/UNCLEAR | material? | confirmed? |。

次の条件を満たすまで進行不可：トレードオフが明示されている（または、確認した観点を挙げた根拠が示されている） · 価値の判定が出されている · 重要度が判定されている · すべての重要なトレードオフがユーザーに確認済み、または — 質問できないコンテキストでは — 呼び出し元が確認できるよう返却する判定に引き継がれている。確認も引き継ぎもされていない重要なトレードオフを、PASS と判定することはできません。また、重大度の低い注記として埋もれさせてはなりません。

トレードオフを確認せずに「トレードオフはない」と答えてはなりません · ユーザーに代わって重要なトレードオフを黙って決めてはなりません · 意見の収束や提供のプレッシャーを、一方通行の変更を強行する根拠にしてはなりません · 複数の重要なトレードオフを曖昧な「進めますか？」にまとめてはなりません。

• 必須 対象作業に着手する前に、ブートストラップとしてタスクを追跡し、一度に1つずつタスクのステータスを遷移させてください。

• 必須 計画とレビューの所見を plans/reports/ に段階的に保存し、ディスク上の情報をもとに統合してください。

• 必須 調査、計画、コーディングを始める前に、docs/project-config.json（モジュール／パス、実行コマンド、規約、アーキテクチャ／ワークフロールールを記載したプロジェクトマップ）と、必須のプロジェクト参照ドキュメントを読み、「Reference docs read: ...」と明記してください。

• 必須 常に lessons.md を含めてください。プロジェクト設定と規約は、一般的なフレームワークのデフォルト設定より優先されます。

• 必須 プロジェクト設定、ルートの指示ファイル、必須の参照ドキュメントが欠落している、または古くなっている場合は、プロジェクト固有の通常作業を始める前に $project-init または適切な下位レベルの手順を自動実行してください。

必ず注意 最初のレビューアクションとして、変更の背景を記録し、影響を受ける主要領域のパイプライン全体をクライアント↔サーバー間の境界をまたいで包括的に追跡してください（BE→FE の順方向、FE→BE の逆方向）。両層でルート／DTO／フィールド／型／null 許容性／認証が一致していることを確認してください。不一致はすべて BREAKING の所見です。単一層またはドキュメントのみの変更の場合に限り省略でき、その旨を記載してください。

重要・必ず注意 マイクロサービス／イベント駆動型の場合は、タスク範囲内のプロデューサー、コンシューマー、サガ、コントラクトを調査してください。各タッチポイントについて、所有者・メッセージ・コンシューマー・リスク（NONE／ADDITIVE／BREAKING）を記載してください。コンシューマーが欠落していると、気づかれないリグレッションにつながります。

重要・必ず注意 デバッガー追跡ゲート：重大なバグ／修正／調査／レビュー作業では、観測された最終出力から始めて、リーダー → ストレージ／プロジェクション → ライター → コンシューマー／ジョブ → プロデューサー／トリガーの順に逆方向へ追跡してください。修正前に、すべての入力経路と仮説を列挙してください。追跡、仮説マトリックス、修正を担当する層、順方向の収束証明が揃うまで、作業はブロックされます。

• 必須 親ワークフローの行は、子フェーズの追跡の代わりにはなりません。入れ子になっている場合はフェーズを展開し、親にリンクしてください。

• 必須 オーケストレーターは呼び出し前に子スキルのフェーズを展開し、[N.M] $skill-name — phase のプレフィックスと「同時に in_progress は1つのみ」のルールを使用してください。

• 必須 作業前に有効な Goal Contract を確定し（有効なプランの goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → 現在のリクエストから作成）、編集前に保存済みの成功基準を読んでください。

• 必須 実行後に反復の証拠を追記し、PASS を報告する前に Goal Satisfaction マトリックス（PASS／FAIL／BLOCKED）を出力してください。検証済みの FAIL があれば繰り返し、進展がない状態の反復やブロッカーが続く場合はエスカレーションしてください。Goal ファイルにシークレットを保存してはいけません。

• 必須 所見は影響度に応じて Critical／High／Medium／Low に分類してください。Critical／High の所見は、修正されるか担当者が受け入れるまで PASS を阻止します。

• 必須 スコアベースのスキル（sre 0-2、perf の2軸）は、別の深刻度用語を使わず、同じ4段階に対応づけてください。

プロンプト強化の締めくくりアンカー

• 重要・必ず注意 このスキルで宣言されたステップ順を守ってください。ユーザーの明示的な承認なしに、ステップを省略、順序変更、統合してはいけません。

• 重要・必ず注意 各ステップ／サブスキルの呼び出しでは、実行前に in_progress、実行後に completed を設定してください。

• 重要・必ず注意 省略したステップには、必ず明示的な理由を添えてください。完了したステップには、必ず簡潔な証拠を添えてください。

• 重要・必ず注意 Task ツールを利用できない場合は、同等のステップごとの計画トラッカーを使用し、ステータスを同期してください。

• 必須・重要・必ず注意 レビューループ（別名 セルフレビュ―収束ループ）を実行してください：レビュー → 指摘事項を検証 → 検証済みの指摘事項を修正 → 全体を再レビュー。指摘事項がゼロの完全なレビューを1回完了した時点でレビューを終了します。新たに生成された出力や判断には、少なくとも1回のセルフレビューを行ってください。新たな判断には、最終判断とする前に少なくとも1回の $why-review --validate-findings による検証を行ってください。

• 必須 重大度の下限を適用してください：ラウンド1～2は、重大度を問わず指摘事項がゼロになった時点で終了します。**ラウンド3以降は CRITICAL／HIGH／MEDIUM の指摘事項がゼロであることが基準です。LOW の指摘事項は修正不要となるため、LOW のみのラウンドでループを終了します。**報告書には、対応を保留した LOW の指摘事項をすべて記載してください。終了条件を満たすために、実際の CRITICAL／HIGH／MEDIUM の指摘事項を LOW に格下げしてはなりません。また、この下限を二値判定のゲート（テスト合格、セキュリティ上の必須修正）に適用してはなりません。

• 必須 ラウンド上限を3に設定してください。これは上限であり、決して目標ではありません：ラウンド数にかかわらず、問題のないレビューが完了したら直ちにループを終了します（ラウンド1も含みます）。ラウンド3の完了時に CRITICAL／HIGH／MEDIUM の指摘事項が未解決の場合は、停止してユーザーに直接確認を求め、エスカレーションしてください。黙って PASS にしてはなりません。進展のない状態が2回繰り返された場合のブロッカー規則は、これより早い終了条件です。先に該当した条件でエスカレーションしてください。終わりのないループは決して行わないでください。

• 必須・必ず注意・常に、3つのトレードオフに関する質問をしてください — レビュー対象そのものと、提案するすべての推奨事項について、次を確認してください：（1）トレードオフはありますか？ 何を犠牲にするのかを明示してください（変更コスト・複雑さ・パフォーマンス・結合度・可逆性・移行・運用負荷・影響範囲・セキュリティ・テスト容易性・提供までの時間・UX）。「なし」／「純粋なメリット」では分析が不十分です。確認した観点を明記してください。（2）それに見合う価値はありますか？ 利益（指標を含む）とコスト、誰が負担するのか、いつ発生するのかを比較し、WORTH IT／NOT WORTH IT／UNCLEAR と判定してください。NOT WORTH IT の場合は、撤回するか、別の案に置き換えてください。（3）ユーザーに確認するほど重要なトレードオフですか？ 元に戻せない変更・一方向の決定、別チーム／運用担当者／メンテナー／ユーザーへのコスト転嫁、ある品質属性と別の品質属性のトレード、ティア／サービス／イベント／ライブラリの境界を越える変更、認証／金銭／データ整合性／破壊的変更／High または Medium リスクの経路、あるいは判定が UNCLEAR の場合は、停止し、判定前にユーザーへ直接確認してください。

• 必須 ユーザーの確認がない重要なトレードオフを PASS にしてはなりません。重要なトレードオフを LOW の注記に埋もれさせたり、黙って決定したりしてはなりません。また、提供や収束を急ぐ圧力を、一方向の決定を承認する根拠にしてはなりません。— 理由：元に戻せない一方向の決定を選ぶのはユーザーであり、レビュー担当者ではありません。

• 必須 — ユーザーに質問できないコンテキストでは、黙って進めず、必ず引き継いでエスカレーションしてください。 ユーザーに直接質問できるのはメインの対話型エージェントのみです。サブエージェントはユーザーに質問できず、ターミナル／判定のみのモードでは仕様上、質問を行いません。この場合、義務は免除されるのではなく、引き継がれます。トレードオフを明示し、重要性を判断し、confirmed? = NO — cannot ask from this context と記録してください。返却する判定／要約に未確認の重要なトレードオフを記載し、呼び出し元がエスカレーションできるようにしてください（ディスク上の報告書にだけ注記しても引き継ぎにはなりません）。無条件の PASS を決して出してはなりません。これはユーザーに実際に連絡できない場合（起動されたサブエージェント、ターミナルの検証モード、ヘッドレス実行）に限り適用されます。ユーザーに質問できる場合は、必ず質問してください。

並列サブエージェントのディスパッチ — タスクの分解ができた時点で、実行する前に並列化を計画します。明らかに独立したタスクを順次実行すると、実時間を無駄にします。対象は、ワークフローのステップ、計画、バッチ更新、調査、リサーチ、スキャン、レビュー、ドキュメントの同期など、すべての複数ステップの作業です。計画の実行はメタデータによるゲート制御とし、デフォルトで並列化することは絶対にありません — ファンアウトは、計画で宣言された内容（PAR／SEQ タグとフェーズごとの書き込み対象）のみに従います。タグのない計画は順次実行します。理由：導出した書き込み対象では、連鎖的な書き込みや生成される書き込みを検出できないためです。

1. すべてのタスクに PAR または SEQ のタグを付けます。 PAR にできるのは、入力に保留中のすべてのタスクの出力が含まれず、かつ書き込み対象が他のすべての PAR タスクと重複しない場合です。それ以外は SEQ とし、その理由となる依存関係を MUST ATTENTION に明記します。
2. PAR タスクをウェーブにまとめます。 同じウェーブのメンバー間に依存関係があってはなりません。同じファイルに書き込むタスクを同じウェーブに含めることは絶対にありません。読み取り専用の作業（検索、調査、レビュー、リサーチ）は自由に並列化できます。
3. ディスパッチ前に宣言します： Parallel plan: wave 1 = [...] · wave 2 = [...] · SEQ = [...] (reason)。
4. 各ウェーブは1つのメッセージで起動します — すべての spawn_agent 呼び出しを1つの応答にまとめ、ターンごとに小分けしてはなりません。各タスクを適切な専門家に割り当てます（.claude/skills/shared/sub-agent-selection-guide.md）。何でも担当させる役として code-reviewer を使うことは絶対にありません。
5. 各サブエージェントには自己完結したブリーフを渡します： 目標 · 範囲と担当ファイル · 参照ドキュメント · 返却要件（要約と Full report: のパス。SYNC:subagent-return-contract に準拠） · plans/reports/ への段階的な保存（SYNC:incremental-persistence に準拠）。
6. 各ウェーブにバリアを設けます。 すべてのメンバーが返答するまで、次に進んではなりません（条件によりスキップされたタスクも返答済みとして扱います）。統合し、各タスクを完了またはスキップとして記録してから、次のウェーブをディスパッチします。変更を伴うステップはバリアを越えるまで待機します。
7. 階層は1段階までです。 ディスパッチされたサブエージェントは自身のブリーフを実行します。そのエージェントの .claude/agents/*.md の定義で許可されている場合を除き、さらなるファンアウトはオーケストレーターの役割です。

並列化してはならないタスク： 書き込み先を共有するタスク · 保留中のタスクの出力を利用するタスク · 単一ファイルだけの簡単な作業（ディスパッチのオーバーヘッドが効果を上回るもの） · スキルまたはワークフローで順序が明示的に固定されている作業 · ユーザーの承認待ちのゲート。

以下を満たすまでブロック： すべてのタスクに PAR／SEQ のタグを付け、各 SEQ に理由を明記して MUST ATTENTION を満たす · ウェーブを宣言し、書き込み対象が重複しないことを確認する · 各ウェーブを1つのメッセージで起動する · 次のウェーブに進む前にバリアを守る。

• 必須 タスクの計画後、各タスクに PAR／SEQ のタグを付け、すべての PAR ウェーブを1つのメッセージで並列サブエージェントとして起動します。ワークフロー、バッチ更新、調査、リサーチ、レビューはデフォルトで並列化します。計画の実行では、計画で宣言された内容に基づく場合にのみファンアウトします。
• 必須 ウェーブごとに書き込み対象を重複させない · 次のウェーブに進む前に全員の返答を待つ · 専門家に割り当てる · サブエージェント自身のエージェント定義で許可されていない限り、サブエージェントがさらにファンアウトすることは絶対にありません。

Project Protocol Overlay — このスキルを実行する前に、このスキルに適用されるプロジェクトオーバーレイのルールを解決してください。プロジェクトのスキルプロトコルインデックス（デフォルトは docs/project-reference/skill-protocols-reference.md。docs/project-config.json の referenceDocs エントリでパスが上書きされます）の Target 列とこのスキル名を照合し、最も具体的に一致する階層のみを採用します（完全一致 > glob > *）。この優先順位はオーバーレイ同士にのみ適用され、このスキルとの間には適用されません。 一致した本文のみを読み取り、<protocols-dir>/<Name>.md として解決してください。行の Body リンクは表示テキストであり、読み取りパスではありません。一致した本文が存在しないか形式不正の場合は、報告してスキップしてください。インデックスの Description から再構成してはいけません。インデックスがない場合、または一致がない場合は、オーバーレイなしで、何も報告せずに進めてください。契約の全文は .claude/skills/project-skill-protocol/references/registry.md にあります。

オーバーレイは追加のみです。このスキル独自のプロトコルにルールを追加するものであり、すでに記載されているルールを置き換えたり、上書きしたり、無効化したり、別の意味に解釈したりしてはいけません。すべてのオーバーレイを取り除いたとき、このスキルの動作は文書化された内容と完全に一致しなければなりません。オーバーレイは補足であり、権限を強化するものではありません。ワークフローのゲート、Git の規律、レビューゲート、ユーザー確認ゲートを免除することはできません。オーバーレイとスキルの間に実質的な矛盾がある場合、または同じ具体性のオーバーレイ同士が直接矛盾する場合は、両方をユーザーに提示してください。黙って解決してはいけません。

必ず注意： 実行前に、このスキルのプロジェクトプロトコルオーバーレイを解決してください。最も具体的に一致する階層のみを採用します（完全一致 > glob > *。これはオーバーレイ同士の優先順位であり、このスキルとの間には適用されません）。一致した本文のみを <protocols-dir>/<Name>.md から読み取ってください。本文が存在しないか形式不正の場合は報告し、再構成してはいけません。オーバーレイは追加のみであり、このスキル独自のルールを置き換えることはありません。また、補足であり、権限を強化するものではありません。同じ具体性のオーバーレイ間に矛盾がある場合は、ユーザーに提示してください。

最後の注意事項

重要・必須の注意事項 — 目標： 要求されたレビュー対象を特定し、該当する敵対的レビューの手順（計画／PBI の根拠、コード変更、ドキュメント／仕様／レポート、指摘事項、または明示された成果物）を適用してください。後続作業に進む前に、判断、指摘事項、計画が敵対的な根拠レビューに耐えられるようにします。

重要・必須の注意事項 — 主な手順（完全モード）。スキルの AI が忘れがちなため、順番どおりに実行してください。 (1) モードを検出する — --validate-findings は終端処理です。(2) 自己再帰的なレビューのループを確立する — プロトコルループを主軸（ホスト非依存）とし、利用可能な場合は任意で /goal ゲートを追加し、さらに Task Bootstrap（フェーズタスクと最後の Findings Validation Gate タスク）を行います。(3) 対象の種類を特定し、有効な Goal Contract を読み、懸念事項に応じて振り分けます。(4) 懐疑的な立場でレビューする — 7 つの Anti-Bias 項目（トレードオフの厳密な検討ゲートを含む：トレードオフがあるか、価値があるか、重要かを確認し、重要ならユーザーに確認する）、Validation Checklist（項目の有無だけでなく、品質と深さも確認する）、第 2 ラウンドの再レビュー、仕様↔テスト↔コードの三者照合を行います。(5) FINDINGS VALIDATION GATE — 終端処理の --validate-findings を再実行し、整合性を取ったうえで、問題がなくなるまで完全な再レビューをやり直します（最大 2 回）。その後、次の手順をユーザーに直接尋ねます。ユーザーの明示的な承認なしに、手順を省略、並べ替え、統合してはいけません。理由：これらの手順こそがレビューの完全性です。どれかを省けば、根拠が検証されていない判断を公開することになります。

適用中のプロトコル（このスキルに含まれる SYNC／共有ブロックの簡潔な要約）： これは要点を示すものです。上記の正式な本文が拘束力を持ちます。必ず各項目を遵守し、要約の一文を完全なルールとして扱ってはいけません。

• 終端から開始点へさかのぼるデバッガートレース： 複雑なバグについては、観測された最終状態からトリガーまでさかのぼって追跡します。
• 動作差分マトリクス： バグ修正の判定には、報告内容以外の項目を1つ含む、3行以上の修正前／修正後の差分表が必要です。
• ネストされたタスクの作成： ワークフローの各行では、引き続き子フェーズのタスクを展開します。ネストされている場合は親タスクにリンクします。
• プロジェクト参照ドキュメント： 規約を判断する前に、対象範囲に該当するプロジェクトドキュメント（必ず lessons.md）を読みます。
• タスク追跡と外部レポート： タスクを初期化します。長時間のレビューで得た知見は、plans/reports/ に逐次保存します。
• 批判的思考： すべての主張を追跡し、証拠で裏付けます。確信度が80％を超えた場合に行動し、常に自分の判断を疑います。
• 順次思考： 複数ステップの思考では、確信度のまとめとともに、REVISION／BRANCH／HYPOTHESIS マーカーを付けた Thought N/M 形式を使います。
• AI の誤り防止： 生成した内容を証拠と照合し、下流の参照先を追跡し、影響を受ける出力をすべて検証します。コンテキストを失った後は読み直し、曖昧さを明示します。
• 証拠に基づく推論： すべての主張に file:line、grep、またはドキュメントを引用します。証拠がなければ、推奨はしません。
• 二重の往復レビュー： レビュー → 検証 → 検証済みの内容を修正 → 問題がなくなるまで全体を再レビューする、というループを実行します。
• 新しいコンテキストでのレビュー： 修正サイクルの後は、メモリーがまっさらなサブエージェントで全体のレビューをやり直します。
• レビュープロトコルの注入： 11個すべてのプロトコル本文を、各新規サブエージェントのプロンプトにそのまま埋め込みます。
• グラフ影響分析： graph.db が存在する場合は影響範囲分析を実行します。影響を受けるファイルから変更済みファイルを除いたものが、古くなっているファイルです。
• 重大度の基準： 結果に基づいて指摘事項を Critical／High／Medium／Low に分類します。Critical／High の指摘がある場合、PASS にはできません。
• トレードオフの精査ゲート： 必ず「トレードオフはあるか？ それだけの価値はあるか？」と確認します。重大な場合は、PASS とする前にユーザーの確認を得ます。
• サブエージェントの並列ディスパッチ： タスクに PAR／SEQ のタグを付け、PAR タスクを書き込み範囲が重ならない単位にまとめ、各単位を1つのメッセージで起動します。次に進む前にバリアを設けます。

重要：必ず注意すること デフォルトの姿勢は、検証者ではなく懐疑的な姿勢です。いかなる判定を下す前にも、7項目すべての反バイアスゲートを完了してください。却下した代替案を少なくとも1つ最も強い形で提示する、まだ見えていない代替案を少なくとも1つ挙げる、選択した方針に反対する論拠を2～3個列挙する、隠れた前提を2～3個ストレステストする、事前検死を行う、長所と短所が対称に検討されているか確認する、トレードオフの精査ゲートを実施する――その理由：項目が記載されているだけでは合格になりません。また、すでにその推論を支持しているレビュアーには、問題点を見つけるための強制的なリセットが必要です。 重要：常に3つのトレードオフに関する質問を必ず確認すること — レビュー対象の判断、および自分が行うすべての推奨事項について、次の質問を必ず確認してください。（1）トレードオフはありますか？ 将来の変更コスト · 複雑さ · パフォーマンス · 結合度 · 可逆性 · 移行 · 運用負荷 · 影響範囲 · セキュリティ · テスト容易性 · チームのスキル · 提供までの時間 · UX のうち、何を犠牲にするかを挙げてください。「トレードオフなし」／「純粋なメリット」は分析未完了です。確認した各項目と、それぞれに影響がない理由を明記してください。（2）その価値はありますか？ 得られるものと犠牲にするものを明示的に比較してください。何が得られるのか（指標を添えて）、何が犠牲になるのか、誰が負担するのか、いつ発生するのかを示し、価値あり／価値なし／不明のいずれかを提示してください。価値なしの場合は、推奨を撤回するか別の案に置き換えてください。決してそのまま推奨し続けてはいけません。（3）そのトレードオフは、ユーザーに確認するほど重大ですか？ 取り消せない場合（一方通行の選択） · 別のチーム／運用担当者／保守担当者／ユーザーにコストを転嫁する場合 · ある品質特性を別の品質特性と引き換えにする場合 · 階層／サービス／イベント／ライブラリの境界を越える場合 · 認証／金銭／データ整合性／破壊的変更／High または Medium のリスクを伴う経路の場合 · または価値の判定が不明の場合は、重大です。次のステップに関する質問をする前、および PASS 判定を出す前に、必ず作業を止め、トレードオフ、両方の選択肢、それぞれが犠牲にするもの、および推奨案を示したうえで、独立した質問としてユーザーに直接確認してください。レビューのたびに Trade-Off Assessment テーブルを出力してください。重大なトレードオフについてユーザーの確認が得られていない場合、決して PASS にしてはいけません。また、重大なトレードオフを Low 重要度の注記に埋もれさせてはいけません。validate-findings のターミナルモードでは、評価して記録するだけにし、質問はしないでください。呼び出し元がエスカレーションすべき事項としてフラグを立ててください。— 理由：コストを示さずにメリットを挙げるのはレビューではなく推奨であり、コストを明らかにしない修正は取り除く不具合より高くつき、一方通行の選択を行うかどうかはユーザーが決めることであって、レビュー担当者が決めることではありません。 重要：レビューを始める前に、対象の種類を必ず特定すること：計画／PBI の根拠、コード変更、ドキュメント／仕様／レポート、指摘事項、または別の成果物。コミット／PR／diff の入力は、コード変更のレビューとして扱うのが既定です。「有効な計画はありません」としてよいのは、計画の根拠を求める依頼が未解決の場合に限ります。対象の種類を、明示せずに別のものへ切り替えてはいけません。— 理由：対象の種類を誤ると、誤った成果物を誤ったチェックリストでレビューすることになります。 重要：再帰ガードは必須であり、例外はありません：フルモードで $why-review --validate-findings を呼び出せるのは最大1回です。validate-findings モードはターミナルモードです。why-review を再度呼び出すこと、ゲートを実行すること、サブエージェントを起動することは決して許されません。— 理由：ターミナルモードでこれらを行うと、無限再帰が発生します。 重要・必ず注意 すべての指摘に、file:line の根拠、重大度、確信度を記載してください（80％を超える場合は対応し、60％未満の場合は推奨しないこと）。「おそらく／〜すべき／〜だと思います」は認めません。理由：立証されていない指摘は、レビュー結果ではなく推測です。 重要・必ず注意 Easy-to-Change を基準に判断してください。すべての指摘、テスト、リファクタリング、抽象化は、将来の変更コストを下げる必要があります。実際の敵（結合、隠れた状態、重複した知識、意図の不明確さ、時期尚早で取り消せない決定）を明示するか、推奨を却下してください。理由：この指標は、変更コストを高める下流の「ベストプラクティス」より優先されます。 重要・必ず注意 慣例を判断する前に、既存パターンを3つ以上検索し、対象ファイルを読んでください。近くにあるパターンを「誤り」と指摘する前に、適合性を評価してください（最も近い例が、前提条件まで一致するとは限りません）。理由：一般的なフレームワークのデフォルトより、ローカルの慣例が優先されます。文脈を無視したパターンマッチングは、誤った指摘を生みます。 重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな TODO タスクに分割してください。フルモードでは、スキルの開始時（タスクの初期設定）に、完了タスクとして Findings Validation Gate を作成し、指摘がある場合は必ず実行してください。$why-review --validate-findings を再度呼び出し（同一セッション内で、ターミナルとして）、すべての指摘が正確で、根拠に裏付けられ、妥当で、ベストプラクティスに沿っていることを確認してください。表面化した指摘の問題や改善点に対してのみ、再実行してください（最大2回まで。それ以上必要な場合はユーザーに直接確認してください）。理由：このゲートにより、誇張された指摘、誤読した指摘、根拠のない指摘を引き渡す前に検出できます。 重要・必ず注意 レビューループを実行してください：レビュー → 指摘の検証 → 検証済みの指摘を修正 → 完全な再レビュー。指摘がゼロの完全なレビューが完了したら、レビューを終了します。未検証の指摘は決して修正しないでください。ラウンドをまたいでサブエージェントを再利用しないでください（新しい spawn_agent 呼び出しを作成してください）。メインエージェントはサブエージェントの報告を読みますが、選別も上書きもしません。理由：修正のたびに以前の判定は無効になり、オーケストレーターの確証バイアスは、記憶がない新しいレビュー担当者なら発見するリグレッションを見逃します。 重要・必ず注意 差分だけでなく、パッケージ全体を判断してください。動作仕様（§3 AC／§4 BR／§8 TC）、テスト、変更されたコードをすべて読み、突き合わせてください。いずれかが欠けている、または食い違っている場合、それ自体が指摘です（CODE-WRONG／SPEC-STALE／TEST-GAP／SPEC-SILENT）。記録された指摘なしに、食い違いがある状態で PASS と判定してはいけません。理由：差分は確認の入口であり、判断の単位はパッケージ全体です。 重要・必ず注意 対象が統合テスト／E2E テストを含む場合、または変更によって統合テストの対象となる動作が変わる場合は、Integration-Test-Review Linkage を適用してください。8つのテスト品質ゲートは $integration-test-review が担うため、プロトコル（デフォルトは Mode A）を読むか、同スキルに委任してください（Mode B はスタンドアロンのフルモードの場合のみ）。次の4つのガード条件のいずれかに該当する場合はスキップし、延期した旨を記録してください：validate-findings モード、$integration-test-review の Phase 9 から呼び出された場合、どのフェーズ（0.8、6、7.5）であっても changes-review または $workflow-review-changes から呼び出された場合、あるいは $debug-investigate の根本原因ゲートから呼び出された場合。理由：このスキルの Test/spec/doc sync 次元では、テストが不変条件を保護していることを立証するとしていますが、それを判断できるのは該当ゲートだけです。また、ガードなしで呼び出すと、why-review → integration-test-review → why-review の循環が発生します。 重要・必ず注意 動作を変える指摘にはすべて、仕様との乖離判定（CODE-WRONG／SPEC-STALE／AMBIGUOUS／SPEC-SILENT／in-sync）と、具体的なテストへのフィードバック対応の両方を含めてください。SPEC-SILENT の判定には、仕様を充実させる対応（§4 BR／§3 AC + §8 TC）も必須です。どちらか一方が欠けていれば、問題あり（HAS-ISSUES）とし、指摘をクリーンと判定してはいけません。理由：コードだけを修正すると、不変条件が仕様から暗黙のうちに抜け落ち、保護されないままになります。 重要・必ず注意 バグ修正／リグレッション／動作変更のレビューでは、End-to-Start デバッガートレース（観測された最終状態 → 逆方向への追跡 → フィーダーパス → 仮説マトリクス → 担当レイヤー → 前方向の収束証明）を実施し、判定の前に Behavioral Delta Matrix（3行以上、うち1行以上はバグ報告の範囲外）を作成してください。REGRESSION の差分が1つでもあれば、その差分をカバーする保持テストが追加されるまで FAIL としてください。理由：説明的な主張はリグレッションを隠しがちです。症状から修正を始めると、マトリクスとトレースを通じた検証が抜け落ちます。 重要・必ず注意 担当レイヤー、つまり不変条件を担う最下層で修正してください。症状やクラッシュが発生する箇所では決して修正しないでください。防御的チェックを伴う3つ以上のファイルに触れる修正は、担当レイヤーを間違えている兆候です。さらに下のレイヤーを調べてください。理由：症状が起きる箇所でのパッチでは、他のすべての利用者が影響を受け続けます。 重要・必ず注意 PASS と判定する前に、残存リスクが High／Medium の場合は、修正、低減、またはユーザー／オーナーによる明示的な受け入れを必須としてください。AI が抽出した仕様／TC は、正規のオーナー／レビュ―ゲートが承認しない限り、根拠として認められません。理由：オーナーが定めていない残存リスクは、合格ではなく先送りされた障害です。 重要・必ず注意 重複するパターンが3つ以上ある場合は抽出を指摘してください。また、同じサフィックスのクラス（*Entity／*Dto／*Service）は、将来の変更コストを下げる場合、共通の基底クラスにするよう指摘してください。出現箇所が3つ未満のパターンは決して推奨しないでください（YAGNI）。理由：過剰な抽象化も抽象化不足も、将来の変更コストを高めます。 重要・必ず注意 Project Reference Docs Gate が選定した参考ドキュメントを読み（docs/project-reference/lessons.md は必ず含めてください）、長期レビューの指摘は plans/reports/ に随時保存してください。次のステップに進む前に、フルモードではユーザーに直接確認してください。自動的に先へ進んではいけません。理由：プロジェクトのドキュメントは一般的な前提より優先されます。外部メモリはコンテキストの圧縮後も残り、レビューゲートの所有者はユーザーです。 重要・必ず注意 作業品質を確認するための最終レビュー TODO タスクを追加してください。 特に注意が必要です 批判的思考と順序立てた思考を適用してください。すべての主張には、適切な追跡可能な根拠が必要です（リポジトリ／コードに関する主張は file:line、調査、製品、コンテンツ、ドキュメントに関する主張はソース URL または該当する資料のセクション）。行動に移す際の確信度は80％超とし、60％未満の場合は推奨しないでください。ハルシネーション対策：推測を事実として提示せず、不確実さは率直に認め、独立して相互参照し、自分の確信度を常に懐疑的に見直してください。

特に注意が必要です 順序立てた思考を適用してください。複数の手順がある場合は、Thought N/M、REVISION／BRANCH／HYPOTHESIS マーカーを使い、確信度を明記してください。$sequential-thinking スキルを参照してください。

特に注意が必要です AI の誤りを防止してください。生成した内容を根拠と照合し、削除や名称変更の前に下流の参照先をたどり、影響を受けるすべての出力を確認し、コンテキストを失った後はファイルを読み直し、行動に移る前に曖昧さを明らかにしてください。

[IMPORTANT] タスクの規模を分析し、着手前に体系的に細分化して、多くの小さな TODO タスクに分けてください。これは非常に重要です。

[GOAL REMINDER — MUST ATTENTION CRITICAL]

すべてのレビュー対象が妥当で、正確で、根拠に裏付けられ、ベストプラクティスに沿っていることを確認してください。 常に3つのトレードオフに関する質問をしてください（あらゆる判断と推奨について）： (1) トレードオフはありますか？ ――何を犠牲にするかを明示してください。「ない」では分析が未完了です。(2) その価値はありますか？ ――誰がいつ負担するコストに対して、どのような利益が得られるかを評価してください。価値あり／価値なし／不明。(3) そのトレードオフはユーザーへの確認が必要なほど重大ですか？ ――取り消し不能、コストの他者への転嫁、ある品質特性と別の品質特性との引き換え、境界の侵犯、重大な影響を伴う経路、または不明に該当する場合は、停止し、判断を示す前に必ずユーザーに直接確認してください。 重大なトレードオフを黙って解決してはなりません。理由：対価に触れずに利益を挙げるのはレビューではなく、推奨にすぎません。一方通行の判断を下すかどうかはユーザーが決めることであり、あなたではありません。 必須の第2パス（フルモード）： 第1ラウンドで所見が1件でも出た場合、引き継ぎ前に、その所見が正確で妥当かを確認するため、必ず $why-review --validate-findings を2回目に実行してください。絶対に省略せず、この手順を避けるために所見を隠したり、重要度を下げたり、過少に報告したりしてはなりません。自己再帰的なレビューループ（主にホストに依存しないプロトコルループと、利用可能な場合の /goal Stop-hook ゲート）は、所見の検証が終わるまで終了をブロックします。理由：検証されていない所見は裏付けのない主張であり、2回目の自己レビューによって第1ラウンドで正当化された誤読や誇張を見つけられます。

合理化の防止：

回避行動	反論
「対応中の計画はない」	未解決の計画の根拠に関するリクエストにのみ有効です。コミット／差分／PBI／ドキュメントが対象です。
「単なるコードレビュー」	それでも対象を特定し、ドキュメントを読み、グラフを実行し、テスト／仕様／ドキュメントを対応付けます。
「指摘事項は明白に見える」	すべての指摘事項をターミナルの --validate-findings で検証します。
「1回目のレビューで十分」	Full モードで指摘事項が1つでもある場合、2回目の --validate-findings を必ず実行します。プロトコルのレビューループ（および利用可能な場合は /goal Stop フック）により、実行するまで終了できません。
「指摘事項をゼロと報告して、ゲートを省略する」	検証を回避するために指摘事項を抑制または格下げすることは、SKEPTIC の姿勢が禁じるまさにその偏りです。指摘事項を提示し、その後で検証してください。
「再実行せず、その場で検証する」	2回目のパスとは、書き出したレポートに対してターミナルで $why-review --validate-findings を実際に呼び出すことであり、頭の中でざっと見直すことではありません。
「すべての観点を一度に確認する」	各観点を個別に集中して確認します。注意を分けることで見落としを発見できます。
「後で尋ねる」	Full モードでは、完了前にユーザーに次のステップを尋ねます。
「問題なし／各観点で一致している」	既定では SKEPTIC の姿勢を取り、Anti-Bias の7項目をすべて完了し、仕様↔テスト↔コードを三者照合します。一致しない観点はすべて指摘事項です。
「ここにトレードオフはない／純粋な改善だ」	検討していないことは、存在しないことを意味しません。確認した観点（変更コスト、複雑さ、パフォーマンス、結合度、可逆性、運用、セキュリティ、デリバリー）を挙げ、それぞれに影響がない理由を説明します。
「トレードオフは明らかなので問題ない」	利得、コスト、負担する人、時期を示し、明示的に WORTH IT／NOT WORTH IT／UNCLEAR の判定を出します。「明らか」は判定ではありません。
「尋ねる代わりに、レポートにトレードオフを書いておく」	重大なトレードオフについては、PASS とする前にユーザーへ直接確認する必要があります。レポート内に埋もれた記述は、確認の代わりにはなりません。
「単なるレビューなので、エスカレーションを決める立場ではない」	重大なトレードオフを提示し、ユーザーに判断を委ねることもレビューの役割です。黙っていれば、誰も判断しないことになります。
「動作は変わるが、仕様への影響はない」	仕様逸脱の判定とテストフィードバックのアクションを提示します。SPEC-SILENT とするには、§4 BR／§3 AC と §8 TC の拡充が必要です。
「クラッシュする箇所を修正する」	所有するレイヤー（不変条件を所有する最下位レイヤー）で修正します。クラッシュ箇所は症状であり、原因ではありません。
「リスクは高いが、リリースする」	PASS とする前に、残存リスクが高または中の場合は修正するか、低減するか、オーナーの承認を得る必要があります。

---

締めくくりのリマインダー — 変更しやすさが成功の指標です。 調査結果、 テスト、リファクタリング、抽象化のすべてについて、次の問いに答える必要があります。 これは次の変更をより安価にしますか、それともより高価にしますか？ 将来の 変更コストを下げないなら、却下してください。結合、隠れた状態、知識の重複、 意図の不明瞭さこそが真の敵です。名指しで指摘してください。

フックレスプロンプトプロトコルミラー（自動同期）

ソース：.claude/.ck.json + .claude/skills/shared/sync-inline-versions.md（:full ブロック）+ .claude/scripts/lib/hookless-prompt-protocol.cjs

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず遵守・重大。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとし、プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から把握します。共有 AI-SDD は shared/sdd-artifact-contract.md を適用してください。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されたプロジェクト参照ドキュメントを開いてください。仕様、テストケース、動作変更、公開コントラクト、または docs/specs/ に関する作業では、仕様とテストとコードの同期を保つ必要がある場合、ドキュメントインデックスに記載されたローカルの仕様ドキュメント（feature-spec-reference.md、spec-system-reference.md、spec-principles.md、workflow-spec-test-code-cycle-reference.md）を経由してください。いずれかのファイル、または必須の参照ドキュメントが存在しないか古くなっている場合、通常のプロジェクト固有の作業を始める前に、$project-init（または $project-config、$docs-init、$scan-all、$scan --target=<key> など、範囲を絞った下位レベルの手順）を自動実行してください。この共有コンテキストとローカルドキュメントが利用できる場合、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトが明示的なスラッシュ形式のスキル／ワークフローコマンドで始まる場合は、それを直接実行します。それ以外の場合は、プロンプトをワークフローカタログおよびスキルリストと照合します。
2. 分析： 最適な選択肢を決定します。直接実行する、スキルを呼び出す、標準ワークフローを有効にする、またはカスタムのステップ構成を作成する、のいずれかです。
3. 自動選択： 最適な選択肢を自分で選びます。直接実行、スキル、標準ワークフロー、カスタムワークフローのどれにするか、ユーザーに選択を求めないでください。
4. 有効化： ワークフローを選択した場合は $start-workflow <workflowId> を呼び出します。スキルを選択した場合はそのスキルを呼び出します。カスタムワークフローの場合はカスタムステップを直接順に実行し、直接実行の場合はタスクに着手します。
5. タスクの作成： 選択した経路に複数のステップがある場合、実行前にすべてのワークフロー／スキル／カスタムステップについてタスクを追跡します。
6. 並列化： タスクリストを実行する前に、各タスクに PAR（入力が独立しており、書き込み先が他のすべての PAR タスクと重複しない）または SEQ（依存関係の阻害要因を明記）を付け、PAR タスクをウェーブにまとめ、ウェーブ計画を宣言し、各ウェーブのサブエージェントを1つのメッセージで起動します。各ウェーブでは全員の完了を待ち、サブエージェント自身の定義でそれ以上の並列化が許可されている場合を除き、ファンアウトは1階層に限ります。独立したタスクを順次実行するのは欠陥です。共有の書き込み先がある場合、出力を利用するタスク、単純な単一ファイル作業、スキルまたはワークフローで明示的に順序が定められている場合、ユーザーの承認が必要な場合は、並列化しないでください。
7. 実行： コンテキスト指示の ワークフローステップの進行と並列フェーズ のルールに従って進めます。進行はモデルが判断し、サブエージェントの完了はインライン呼び出しと同じようにステップを進めます。並列フェーズのグループは全員の完了を待つバリアです（全メンバーが戻るまで進まず、決して逐次実行しないでください）。

共有 AI-SDD プロトコルマーカー

ソース：.claude/skills/shared/sync-inline-versions.md

SYNC:ai-sdd-artifact-contract

AI-SDD 成果物契約 — 共有する仕様駆動開発のルールは、移植可能な状態に保ち、ソース側で管理します。

1. 再利用可能な AI-SDD の原則は .claude に置き、リポジトリ固有のパス、コマンド、担当者、製品、形式はプロジェクト設定または参照ドキュメントに記載します。
2. サイクルを維持します：spec -> plan -> tasks -> implement -> verify -> update spec/docs。
3. すべての要件または不変条件を、判断、タスク、TC／テスト、ソースの根拠、ドキュメント／仕様の更新まで追跡します。
4. コードから仕様への抽出は、正規の仕様オーナーが承認するまでは参照専用として扱います。
5. 同期されたコンテキストがあれば、サポート対象の AI ツールで計画、実装、レビュー、検証を行えます。複数のツールを使うかどうかは任意です。
6. まず .claude のソースを更新してから、生成されたミラーを同期します。.agents、.codex、AGENTS.md を手動で編集しないでください。— 理由：ミラーは生成された成果物であり、次回の同期時に手動編集内容が上書きされます
7. docs/project-config.json、ルートの指示ファイル、または必須のプロジェクト参照ドキュメントが欠落しているか古い場合は、通常のプロジェクト固有の作業を行う前に、$project-init または適切な下位レベルの手順を自動実行します。

有効な参照先： アクティブなスキルルート内の shared/sdd-artifact-contract.md。

---

SYNC:ai-sdd-artifact-contract:reminder

• 必須 shared/sdd-artifact-contract.md を適用し、再利用可能な AI-SDD は .claude に、ローカルルールはプロジェクトのドキュメントに保持します。
• 必須 コードから仕様への抽出は、正規の承認を得るまで参照専用です。サポート対象の AI ツールであれば、同期されたコンテキストを使って実行できます。
• 必須 生成されたミラーを同期する前に .claude のソースを更新します。.agents、.codex、AGENTS.md を手動で編集しないでください。
• 必須 プロジェクト設定、ルートの指示ファイル、または必須の参照ドキュメントが欠落しているか古い場合は、プロジェクト固有の作業を $project-init または適切なセットアップ手順に自動的に振り分けます。 [TASK-PLANNING] [必須] ワークフローまたはスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成／更新し、各手順の開始時と完了時に同期してください。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的な改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割して追跡します。最後のタスクに「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみを扱います：

1. 症状ではなく、失敗モード（推論や前提の誤り）を特定します。「間違った enum 値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を確認します。この失敗モードは 3 つ以上の状況／コードベースに当てはまりますか？当てはまらない場合は、もう一段階抽象化します。
3. 普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除きます。どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめます。
5. 再発ゲート：「このリマインダーがなければ、今後のセッションで再発するか？」いいえ → $learn は省略します。
6. 自動修正ゲート：「$code-review／$code-simplifier／$security-review／$lint で検出できるか？」はい → 代わりにレビュー用スキルを改善します。
7. 両方のゲートを通過した場合は、ユーザーに $learn の実行を依頼します。 [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。あらゆる主張に追跡可能な証拠を求め、行動する際は確信度を 80% 超とします。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実性を率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。証拠のない確信が、あらゆるハルシネーションの根本原因です。 AI の注意力の原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、最も重要なルールを上部と下部の両方に 3 つずつ配置し、長いコンテキストでも指示への準拠を維持します。 目標主導の実行： まず成功基準を定め、検証できるまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストは意図を検証します： テストは現在の動作をなぞるだけでなく、ビジネスルールや不変条件を保護し、保護対象の意図が崩れたときに失敗する必要があります。

よくある AI のミスを防ぐ（システムの教訓）

• コンテキスト圧縮後はファイルを再読込してください。 編集するには、同じコンテキスト内で事前に Read している必要があります。圧縮によって読込状態は消去されます。編集前に再読込してください。
• 一括置換後は古い用語を grep してください。 AI は検索・置換の完全性を過信します。一括編集後はリポジトリ全体を grep し、ドキュメント／設定／カタログに参照漏れがないか確認してください。
• 削除前に下流の参照を確認してください。 削除の影響は、ドキュメントやコードの陳腐化へ連鎖します。削除前に参照元ファイルを洗い出してください。
• 記憶を失った後、新しく作成する前に既存の状態を確認してください。 圧縮によってこれまでの作業の記憶が消去されます。作業を再開するときは現在の状態を確認し、決してむやみに重複作成しないでください。
• AI 生成コンテンツは実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントへの記載や参照の前に、grep して実在を確認してください。
• 編集後は依存関係を最後までたどってください。 定義を変更しても、その下流の利用箇所を見落とすことがあります。依存関係をすべてたどってください。
• 名前を変更するときは、利用側の全ファイル形式を grep してください。 ファイル形式によっては、参照先が見つからなくてもエラーなしで無視されます。コード、テンプレート、設定、生成ファイルを検索してください。
• 正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することと、実行されることは同じではありません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップもたどってください。
• ソースが変わったら、正規データを埋め込んでいるドキュメントも更新してください。 派生データ（ワークフロー、スキーマ、設定など）を直接記載しているドキュメントは、気づかないうちに古くなります。ソースと合わせて、該当する埋め込みドキュメントをすべて更新してください。
• コンテキスト復旧後は、サブエージェントの結果を検証してください。 親エージェントが圧縮されている間にバックグラウンドエージェントが完了している場合があります。完了したはずだと信じず、出力を grep して確認してください。
• 対象の全一覧とサブエージェントへの割り当てを照合してください。 カテゴリごとにサブエージェントを並行実行すると、境界上の項目を見落とすことがあります。作業を進める前に、割り当ての和集合を対象一覧と照合してください。
• サブエージェントが引き継ぐ知識は、そのエージェントの .md 定義に書かれた内容だけです。組み込みの Explore ではなく、カスタムエージェント種別を使用してください。 ツールの採用には、権限＋知識＋適用（番号付きワークフロー手順）が必要です。
• サブエージェントの調査結果は最後にまとめてではなく、随時保存してください。 長時間実行されるサブエージェントは、最終書き込み前に打ち切られることがあり、調査結果が失われます。報告ファイルにセクションごとに追記するよう指示してください。
• デバッグ時は修正する前に「どちらの責任か」を確認してください。 呼び出し元（データが誤っている）と呼び出し先（処理が誤っている）をたどり、責任のある層を修正してください。症状が表れる箇所だけを修正してはいけません。
• テスト失敗時は、追跡や編集の前に暫定判定を記録してから調査してください。 次の 5 つの分類をすべて使ってください。SOURCE-WRONG（本番コードが意図に反している）、TEST-WRONG（アサーション／セットアップが古くなっている）、TEST-NOT-OPTIMAL（妥当だが脆弱、または情報量の少ないテスト）、ENVIRONMENT-BLOCKED（外部状態のため判定できない）、AMBIGUOUS（意図や証拠から安全に選べない）。その後、根本原因をたどり、適用される仕様（存在する場合は docs/specs/**）とソースの両方に照らして検証してください。成功を無理に得るために、アサーションを弱めたり、スキップを追加したり、タイムアウトを緩めたり、ソースを変更したりしてはいけません。
• 抽出／リファクタリング後は、削除した名前をすべて grep してください。 主要ファイルの作業完了は、他のファイルもクリーンであることを意味しません。完了を宣言する前に、対象範囲全体で削除したシンボルを一つずつ grep してください。
• 既存の値には意図があると考え、変更したり不具合だと指摘したりする前に、必ず理由を確認してください。 パターンマッチで「誤り」と決めつけると、背景を見落とします。定数／上限／フラグ／しきい値を変更または報告する前に、コメント、git blame、呼び出し元の処理順序（値を正しくする保証は、通常、該当行の直前に実行されるコードにあります）、同じ規約を使っている 2 つ以上の類似した呼び出し箇所を確認してください。理由なしに WHAT（何をするか）だけを記したドキュメントは、根拠が欠けているのではなく、WHY（なぜそうするか）の説明が不足しているということです。検証作業でも、正確な file:line の引用が証明するのは転記が正確であることだけであり、不具合の存在ではありません。
• 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 一つのビルドが成功しても、すべてが成功したとは限りません。複数のスタックにまたがる変更（バックエンド／フロントエンド／テスト／ドキュメント）では、すべての出力を検証してください。
• 近くにあるパターンをコピーする前に、適合性を評価してください。 最も近い例が適合するとは限りません。新しいコンテキストが同じ制約、基底クラス、スコープ、ライフタイムを共有するか確認してください。
• デバッグでは全体を優先し、目についた箇所に飛びつかないでください。 最初に思いついた原因へすぐ飛びつかないでください。前提条件（設定、環境変数、パス、DB、エンドポイント、認証情報、バージョン、DI、データ）をすべて列挙し、それぞれを証拠（推論ではなく grep／クエリ）に照らして検証してください。「何があればこの仮説は否定されるか？」と問い、何も答えられないなら、それは仮説ではありません。最もコストの高い失敗は、バグが一度も疑われていない層にあるのに、「明らか」だと思い込んだ層をさらに深掘りすることです。
• 変更は最小限にし、差分テストを適用してください（コンテキストに合わせて判断）。 2 つのモードがあります。（1）バグ修正 → すべての行がバグに直接関係するようにし、スタイル変更はしないでください。不要になったインポートを削除してよいのは、あなたの変更によって不要になったものだけです。（2）レビュー／機能強化 → 改善を実装し、「主な依頼を超える機能強化：[内容]」と明示してください。黙ってスコープを拡大しないでください。差分テスト：「X を依頼されていなかったとしても、この行は存在していたか？」いいえなら、削除するか明示してください。
• 実装前に曖昧さを明らかにし、黙って解釈を選ばないでください。 複数の妥当な解釈がある場合は、それぞれの工数とともに提示してください。「[依頼] は（1）[N 時間]、（2）[N 時間]のいずれかと解釈できます。どちらが重要ですか？」まずスコープ／形式／量／制約に関する前提を列挙してください。より簡単な方法がある場合は、そのことも伝えてください。黙って選ばないでください。
• [必須の最初のアクション] 応答する前に、必ず適切なスキルまたはワークフローを有効にしてください。 ワークフローカタログとスキル一覧に照らしてタスクを確認し、スキルの呼び出し、または $start-workflow <workflowId> で実行してください。確認する前に回答やコード作成をしてはいけません。省略はプロトコル違反です。
• Why-Review の敵対的な視点は、計画、判断、設計をレビューするときに適用してください。 基本姿勢は VALIDATOR（妥当性を確認する側）ではなく SKEPTIC（懐疑的な側）です。却下された代替案の最も強い論拠を組み立て、述べられた理由を一つずつ逆転させて「何を犠牲にするのか」を問い、上位 2～3 個の前提をストレステストし、プレモーテム（「リリースしたが 3 か月後に失敗した。何が壊れたのか？」）を行い、作成者が見落とした代替案を 1～2 個提示してください。セクションがあるだけでは十分ではありません。重要なのは、因果関係に基づく推論、具体的な軽減策、証拠です。「より良い」や「注意深く監視する」だけでは不十分です。
• 大規模なレビューでは、サブエージェントへのプロンプトで報告書の書き込みを最初に行わせてください。 多数のファイルを扱うサブエージェントは、最終書き込みの前に予算を使い切り、調査結果を失うことがあります。プロンプトは、（1）報告書の書き込みを最初に明示する成果物とする、（2）まとめてではなくファイル／セクションごとに追記する、（3）読み込みで予算を使い切らないようスコープを限定する、という構成にしてください。報告ファイルを残さず文の途中で打ち切られた場合は、同じプロンプトを再試行せず、より狭いスコープで再実行してください。
• コンテキスト圧縮後は、続行する前に以前の各フェーズの結果をすべて再検証してください。 要約が示すのは意図であり、環境の状態（git のインデックス、ファイルシステム、プロセス）ではありません。再開時はまず git status を確認し、変更したファイルを再読込し、ファイルシステムを検証してください。証拠で確認されるまでは、「完了した」という主張もすべて未検証の仮説です。
• OOM／メモリ：行サイズより先に行数を確認してください。 次の順にトリアージします。（1）上限のないクエリ — 条件を設定するトリガーとなる DB フィルターがありませんか？ DB 側にフィルターを移せば、OOM を解消できます。（2）行サイズが大きいですか？ プロジェクションを使えば比例して減らせます。費用対効果では、プロジェクションより行数削減が優先です。
• システムが担う最終結果をアサートし、インフラストラクチャが担う中間状態をアサートしないでください。 非同期処理（キュー／ブローカーへの配信、再試行、バックグラウンドジョブ、キャッシュ、レプリケーション）をテストする場合は、最終的なビジネス／エンティティの状態をアサートしてください。配信の記録、つまり消費／送信ステータス、試行回数、最終エラー、ブローカー、スケジューラー、outbox／inbox テーブル内の行の有無や件数をアサートしてはいけません。この記録は共有インフラストラクチャに存在し、並行して動く任意のプロセス（別のワーカー、2 つ目のレプリカ、残っているローカルコンテナー）から書き込めるうえ、通常は決定的な共有キーが使われます。そのため、こうしたアサーションは気づかないうちにシステムではなく開発者の環境をテストします。単独実行では成功しても、同じブローカー＋データベースをほかの何かが共有した途端に不安定になります。すべてのアサーションで、次の判定の問いを使ってください。「どのプロセスが処理しても、この結果は成り立つか？」いいえなら、代わりに収束後のデータ状態をアサートしてください。系として、プロセスローカルな障害注入やプロセス内テレメトリーを、任意のプロセスが実行する処理のゲートとして使うことはできません。負荷増幅に使ってください（有効化 → 範囲を限定した時間枠 → 無効化 → 収束をアサート）。前提条件として使ってはいけません。
• ドメイン概念を汎用／共有／インフラストラクチャ層に持ち込まないでください。 再利用可能な層（共有ライブラリ、フレームワーク、インフラモジュール）は、利用側に固有のドメイン概念（テナント／顧客／製品 ID、ビジネスエンティティ、機能ルール）を一切参照してはいけません。漏れがコンパイルされ、実行されると、再利用可能なはずの層が一つの利用側と結合していても、レビューで気づかれずに通過してしまいます。共有型からドメイン情報を排除し、サブクラス化／コンポジションを通じて、ドメインフィールド／ロジックを利用側へ移してください。理由：一つの利用側のドメインに結合した層は、もはや再利用可能ではありません。