plan-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 を確認してから、関連するファイルだけを開いてください。

[BLOCKING] スキルの手順は定められた順序で実行してください。ユーザーが明示的に承認しない限り、手順の省略、並べ替え、統合は絶対に行わないでください。 [BLOCKING] 各手順またはサブスキルを呼び出す前に、タスクの追跡を更新してください。手順の開始時に in_progress、終了時に completed に設定してください。 [BLOCKING] 完了またはスキップした手順には、すべて簡潔な証拠または明示的なスキップ理由を記載してください。 [BLOCKING] Task ツールを利用できない場合は、同じステータス遷移を適用しながら、同等の手順別プランのトラッカーを作成して維持してください。

クイックサマリー

目標： 幻覚がなく（既存コードに関するすべての主張が file:line で証明されている）、実装に着手できる状態（すべてのステップが具体的で、すぐにコーディングできるほど小さい）でない限り、計画が実装に進むのを阻止します。実装計画を自動レビューし、有効性、正確性、ベストプラクティスへの適合性を確認します。再帰的： 指摘事項がある場合は、$why-review --validate-findings で指摘事項を検証し、計画ファイル内の検証済み指摘事項のみを修正して、ラウンドの終了基準を満たすまで計画レビュー全体を再実行します — ラウンド1～2では指摘事項ゼロ、ラウンド3以降ではCRITICAL／HIGH／MEDIUMがゼロ（LOWのみのラウンドではループを終了し、修正せず保留）。

各フェーズのレビューでは、Mode、Wave、write set、SEQ依存関係を分割できないメタデータ契約として扱います。いずれかのフィールドに不一致があれば、承認を阻止します。

概要： AIによるセルフレビュー（ユーザーへの聞き取りを行う $plan-validate とは異なり、自動実行）で、実装前に計画をゲートします。

• 目的： バリデーターではなく、懐疑的な立場でレビューします。既存コードに関するすべての主張には file:line による証拠が必要です（幻覚防止ゲート）。各フェーズは「詳細かつ十分に小さい」粒度ゲート（≤5ファイル、≤3h、計画を立てる動詞なし）を通過する必要があります。曖昧すぎる場合は詳細化し、大きすぎる場合は分割します。
• 主な手順（順番に実行）： フェーズ0で計画タイプを検出 → ステップ1で plan.md、goal.md、すべての phase-*.md を読み、要件／ステップ／ファイル／リスクを抽出 → ステップ2で4つのチェックリストグループを評価：有効性（概要、要件、ステップ、ファイル）・正確性（粒度ゲート＋幻覚防止／コード証明ゲート＋仕様／TCカバレッジ＋ゴール契約マッピング）・ベストプラクティス（YAGNI／KISS／DRY／アーキテクチャ）・完全性（リスク、テスト、成功基準、セキュリティ、グラフ依存関係）→ 11の敵対的手法＋バイアス防止ゲート＋8つの計画の観点を実行 → 変更対象ファイルごとにグラフをトレース（graph.dbが存在する場合）→ ステップ3でPASS／WARN／FAILを判定 → ステップ4で結果を出力 → ステップ5で再帰的な検証・修正・再レビューのループを実行。
• 計画タイプを最初に検出（フェーズ0）： 適切な観点を適用します。バグ修正ではBehavioral Delta Matrixが必須となり、セキュリティ／パフォーマンス／リファクタリング／契約／インフラ／データスキーマでは、それぞれ対象を絞ったチェックが追加されます。
• 指摘事項を決して検証せずに修正しないでください： plan.md／phase-*.md を編集する前に $why-review --validate-findings ゲートを実行し、検証済みの指摘事項のみを最小の該当箇所で修正してから、記憶を持たない新しいサブエージェントでレビュー全体を最初からやり直します。ラウンドの基準を満たすまでループします。
• 重大度の下限 — ラウンド3以降はLOWではブロックされません。 ラウンド1～2では、重大度を問わず指摘事項ゼロが必要です。ラウンド3以降の基準は、検証済みのCRITICAL／HIGH／MEDIUMがゼロであることです。検証済みの指摘事項がすべてLOWであるレビューラウンドでは、ループを終了します。 LOWの指摘事項だけを理由にレビュー全体を再開しないでください。レポートの ## Deferred LOW Findings (severity floor, round ≥3) に記録してPASSとします。終了条件を満たすために、実際のCRITICAL／HIGH／MEDIUMをLOWに再分類してはなりません。また、幻覚によるコードの主張や証拠不足の指摘に重大度の下限を適用してはなりません。これらは定義上HIGHであり、保留できません。重大度の区分は SYNC:severity-rubric に従います。
• ラウンド上限は3 — 上限であり、目標ではありません。 クリーンなPASSが出た場合は、ラウンド1を含め、どのラウンドでも直ちにループを終了します。同じブロッカーが進展のないまま完全な再レビューで2回連続して残った場合、指摘事項が未解決のままラウンド3が完了した場合、または指摘事項にプロダクト／オーナーの判断が必要な場合は、ユーザーに直接確認します。上限到達はエスカレーションにつながりますが、決してPASSにはなりません。

ワークフロー：

1. 計画を解決する — $ARGUMENTS のパス、または ## Plan Context にあるアクティブな計画を使用します
2. ファイルを読む — plan.md とすべての phase-*.md ファイルを読み、要件／手順／ファイル／リスクを抽出します
3. チェックリストを評価する — 妥当性（概要、要件、手順、ファイル）、正確性（具体性、パス、競合がないこと）、ベストプラクティス（YAGNI／KISS／DRY、アーキテクチャ）、完全性（リスク、テスト、成功条件、セキュリティ）
4. 採点して分類する — PASS（Required をすべて満たし、Recommended の50％以上を満たす）、WARN（Required をすべて満たし、Recommended の50％未満を満たす）、FAIL（Required に未達がある）
5. 結果を出力する — ステータス、合格したチェック、問題点、推奨事項、判定
6. 指摘事項が残っている場合 — まず計画レビュー報告書に対して $why-review --validate-findings を実行し、検証済みで対応可能な問題のみを計画ファイルで修正してから再レビューします（そのラウンドの基準を満たすまでステップ2に戻ります。ラウンド1～2では指摘事項ゼロ、ラウンド3以降では CRITICAL／HIGH／MEDIUM がゼロ。ただし、同じ阻害要因のルールまたは3ラウンドの上限が適用される場合を除きます）

基本原則 — 詳細で、かつ小さく保つ：

• 曖昧すぎる場合 → 詳細化します。具体的なファイルパス、明確な操作、正確なメソッド名を追加します
• 詳細化するには大きすぎる場合 → 分割します。各フェーズを詳細に記述できるまで、小さなフェーズ／サブ計画に分けます
• すぐにコーディングを始められない計画は、準備ができていません。すべての手順は実装可能な状態でなければなりません

主なルール：

• 幻覚を起こさない：既存のソースコードに関する計画内の主張には、すべて file:line による証拠が必要です。未確認のパス、クラス名、動作があれば FAIL です
• PASS：実装に進みます
• WARN：注意して進め、不足点を記録します
• FAIL（指摘事項あり）：$why-review --validate-findings で指摘事項を検証し、検証済みの計画上の問題のみを修正してから、レビュー全体を最初から再実行します。この自己ループを、最低回数を設けず、最大3ラウンドまで繰り返します。完全なレビューで指摘事項がゼロになるまで続けます
• 上限付きループ — エスカレーションのトリガーは2つ。いずれも完了条件ではありません：（a）進展がない場合の安全策 — 進展がないまま、同じ阻害要因が連続する2回の完全な再レビューで残ること。（b）ラウンド上限 — 指摘事項が残ったままラウンド3が完了すること。どちらかが発生したら停止し、ユーザーに直接質問してエスカレーションします。黙って「これで十分」と PASS にしてはいけません。指摘事項がなくなれば、ラウンド1であってもループは直ちに終了します。上限は最大数であり、ノルマではありません
• 建設的に：細かな揚げ足取りではなく、実装を妨げる問題に焦点を当てます

懐疑的になり、批判的思考と順序立てた思考を適用します。すべての主張には追跡可能な証拠と確信度の割合が必要です（Idea は80％を超える必要があります）。

第一原則 — 変更しやすさ

あらゆるコーディング上の判断の成功指標は、将来の変更コスト です。 DRY、SRP、抽象化、デザインパターン、命名、レイヤー化、テストなど、 あらゆる手法は1つの目標、つまり次の変更をより低コストにすることに役立ちます。

コード、リファクタリング、テスト、抽象化を評価するときは、**これによって次の変更のコストが下がるのか、それとも上がるのか？**と問いかけます。

• 変更コストを上げる「ベストプラクティス」は却下します。早すぎる抽象化、推測に基づく汎用化、漏れのある間接化、見返りのない形式主義などが該当します
• 指摘事項では、真の敵を名指しします。結合、隠れた状態、知識の重複、意図の不明確さ、早期に露呈した取り消し不能な判断です
• 変更しやすいシンプルな設計は、そうではない洗練された設計より優れています

以下のルール、パターン、チェックリストを適用する前に、まずこの観点で評価します。この原則と矛盾して変更コストを上げる下位のルールは、この原則を優先して適用しません。

---

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

基本姿勢：検証者ではなく、懐疑者です。正しそうに見えるものを追認するのではなく、うまくいかない点を見つけることが役割です。

確証バイアスの罠： よく構成された計画を読んだAIは、自然と賛同する理由を探しがちです。このセクションは、安易な承認につながる前に、その流れを断ち切るためにあります。

敵対的な検証手法（結論を出す前にすべて適用）

手法1〜6では、計画を実行できるか（現実性、労力、範囲、依存関係）を検証します。手法7〜10では、選択した設計が正しいかを検証します。これは、$why-review の根拠レビューでも用いられる意思決定の質という視点です。両方のグループを適用してください。実行可能な計画でも、誤った判断に基づいていれば失敗です。

1. 実装の現実性チェック 各フェーズについて、次の問いを考えてください。「開発者が今すぐ実装を始めたら、最初に何が壊れるか？」 クリティカルパスを具体的にたどってください。「サービスレイヤーを実装する」のような曖昧なフェーズが、具体的なファイルやクラスに結び付けられない場合は不合格です。

2. 前提条件のストレステスト 暗黙の前提条件を上位3つ挙げ、それぞれについて、次の問いを考えてください。「その前提が誤っていたらどうなるか？」 3つのうち2つが誤っていても成立する計画が有効です。よくある隠れた前提条件には、既存のコードが既知の状態にある・外部APIに変更がない・チームがすでにこの分野の知識を持っている、などがあります。

3. 作業量の現実性チェック 見積もられた各フェーズについて、次の問いを考えてください。「このコードベースで同様の作業が、その見積もり期間内に完了したことはあるか。そのとき何が遅延の原因になったか？」 作業量を2倍以上過小評価している場合、それは有効な計画ではなく、楽観的な推測です。

4. プレモーテム 計画に書かれたとおりにリリースされ、機能が本番環境で1か月稼働したと仮定してください。具体的で、起こりそうな失敗シナリオを1つ書いてください。何も見つからない場合は、十分に深く検討できていません。

5. スコープクリープ検出 提示された機能を提供するために直接必要ではないタスクをすべて指摘してください。「ついでにXもリファクタリングしましょう」はスコープクリープです。

6. 依存関係の盲点 計画が安定していると仮定している外部依存関係（サービス、API、データソース）を2〜3個挙げてください。そのうち1つについて、次の問いを考えてください。「これが変更されたり、なくなったりした場合、何が壊れるか？」 対処方法がどこにもない依存関係の障害は、リスクの見落としです。

7. 却下した代替案を最も強く擁護する 設計上の判断で代替案よりXを選んだ場合、却下した案を可能な限り強く擁護してください。10年の実務経験を持つその分野の上級者なら、その案を選ぶでしょうか。選ぶなら、「Xを選んだから」より強い根拠で却下を証明する必要があります。却下した案に一度も触れない判断は、検討されたのではなく、前提として扱われているからです。

8. なぜ選ばないのか？ 「YだからXを選んだ」について、Xが_何を犠牲にするか_を問いかけてください。利点しか挙げない計画は、トレードオフを避けているのではなく、隠しています。欠点を明示してください。

9. 見落とされた代替案 計画で触れられていない、実現可能なアプローチを1〜2個挙げてください。除外理由のない代替案は、十分に検討された決定ではなく、検討範囲が不十分であることを示します。

10. メリットとデメリットの対称性 選択したアプローチについて、挙げられたメリットとデメリットを数えてください。メリットがデメリットを2倍以上上回る場合、確証バイアスの兆候です。受け入れる前に、不足しているデメリットを明示してください。

11. 反対の立場からの検討 いかなる結論を出す前にも、反対の立場を擁護する文を2文以上書いてください。合格と書こうとしているなら、要改善を主張し、その逆も同様に行います。そのうえで、証拠に基づいて、より説得力のある主張を選んでください。

禁止パターン

• 「構成はよく見える」 → 構成は品質ではありません。実装できますか？
• 「フェーズが明確に定義されている」 → フェーズがあることは正しさを保証しません。各フェーズには何が含まれていますか？
• 「代替案を検討した」 → それらは失敗するよう仕立てられた藁人形ではなく、本当に有効な代替案でしたか？
• 「リスクは管理されている」 → 「注意深く監視する」はリスク軽減策ではありません。誰が、何をきっかけに、どのような対応を取るのですか？
• クリティカルパスをたどらずに**「実現できそう」**と判断する → 有効な評価ではありません。

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

最終判断を書く前に、すべてのチェックを完了してください（必ず注意）：

• 最もリスクの高いフェーズに対して実装実態チェックを実施する
• 3つの暗黙の前提を特定し、ストレステストを行う
• 工数の見積もりをコードベースの複雑さと照らし合わせる
• 事前検証を行う（具体的な本番障害シナリオを1つ挙げる）
• スコープクリープ（提示された機能に必要のないタスク）がないか確認する
• 依存関係の盲点に対処していることを確認する
• 少なくとも1つの却下した設計案について、その案を支持する立場から最も有力な議論を示す
• 計画で言及されていない、実行可能な代替案を少なくとも1つ挙げる
• 計画の主要な設計判断について、メリットとデメリットが対称に検討されているか確認する

チェックが1つでも未完了なら、敵対的レビューは完了していません。戻って対応してください。

「Why-review」との関係： テクニック7〜10とこれらのゲートチェックは、レビュー中に適用する 根拠 の観点です（計画の設計は妥当か）。独立した $why-review --validate-findings ゲートは、指摘事項が出そろった後に実行します（修正前に、指摘事項そのものが正しいか）。両方とも必要です。それぞれ異なる点を検証するため、統合してはなりません。

計画の評価軸に関する思考フレームワーク

計画の種類を判定した後（フェーズ0）、以下の各評価軸について、この思考パターンを用いて評価します。

各評価軸について： （1）計画の領域において、その評価軸が担う役割を理解する。（2）計画がその評価軸について述べている内容を読む。（3）第一原理から実際の懸念を導き出す――この評価軸が弱い場合に何が起きるか。（4）計画の技術スタックに関する知識を適用し、そのスタック固有のギャップを見つける。

評価軸1：スコープの整合性

考えること： 計画のスコープは、提示された目標と完全に一致していますか。広すぎたり、狭すぎたりしていませんか。

• 提示された目標を達成するために必要な変更の最小セットは何ですか。
• 計画に含まれているものの、目標にはない内容は何ですか。→ スコープクリープです。
• 目標に含まれているものの、計画が対処していない内容は何ですか。→ スコープの不足です。
• ストレステスト：「フェーズXを省略した場合でも、機能は動作しますか。」→ 動作するなら、そのフェーズはスコープ外です。

評価軸2：データフローの正確性

考えること： 計画のすべてのフェーズで、データの流れを追跡できますか。

• データはどこで発生し、最終的にどこに到達しますか。
• その間にデータを変換するものは何ですか。その変換について計画に記載されていますか。
• API、メッセージバス、ストレージ、UIなど、システム境界でデータはどう扱われますか。計画では各境界に対処していますか。
• どのようなデータ状態が無効ですか。それらを防ぐ仕組みはありますか。

評価軸3：依存関係チェーンの網羅性

考えること： 計画では、変更による影響をすべて考慮していますか。

• 計画で変更するすべてのファイル／モジュールについて、何がそれをインポートし、何がそれを呼び出し、何がその契約に依存していますか。
• インターフェース／契約を変更する場合、利用するすべての側が列挙されていますか。
• 外部依存関係（サードパーティーサービス、共有インフラ）は安定していますか。障害が発生した場合の代替策はありますか。
• graph.db が存在する場合は、グラフのトレースを実行し、計画に記載されたファイル一覧と下流への影響を照合します。

評価軸4：障害モードの網羅性

考えること： 問題が発生した場合について、計画には何が記載されていますか。

• 外部呼び出し、非同期処理、状態変更ごとに、エラー時の動作はどうなりますか。
• 取り消し不能な操作について、計画にロールバック戦略が含まれていますか。
• 部分的な失敗状態（移行やデプロイが途中まで完了した状態、競合状態）はどうなりますか。対処可能ですか。
• 新しいコードパスについて、監視／アラート計画はありますか。

ディメンション 5：テストの可観測性

考えてください： 開発者は、この計画の実装が正しいかどうかをどのように把握できますか？

• 記載された受け入れ基準は、テストで機械的に検証できますか？
• 単体テストではなく、ログやトレースを通じてのみ観測できる動作はありますか？
• どのフェーズでリスクが生じますか？ そのフェーズにテストはありますか？
• 「テストが合格する」は成功基準ではありません。テスト対象の具体的な動作を挙げてください。
• Spec-Loop のスケジューリング（テスト品質ゲート）。 計画では、単に「テストを追加する」のではなく、Spec-Loop をスケジュールしなければなりません。（1）すべての [HARD] §4 ルール／§5 不変条件について、境界条件の反例とともに、全称量化されたプロパティテスト仕様を用意する（例示テストだけでは不十分です）。（2）変更されたコアロジックには、MUTATION-SCORE 品質基準を適用する（生き残ったミュータントは不変条件の欠落を意味し、ミュータントを倒すテストが必要です）。行カバレッジ％を目標にしてはいけません。（3）動作を変える指摘のたびに仕様とテストの両方を強化し、パッケージを再レビューして新たな欠落がなくなるまで確認する、二重フィードバック＋再レビューのステップを設ける。行カバレッジ％を目標にしてミューテーションスコアの基準を設けない計画、または [HARD]／§5 ルールに対するプロパティ／不変条件のテスト仕様がない計画は、FAIL としてください。

ディメンション 6：知識の前提条件

考えてください： この計画の実装には、計画に明示されていない知識が必要ですか？

• ドメイン知識：ビジネスルールは明記されていますか？ それとも、実装者があらかじめ知っている必要がありますか？
• システム知識：統合ポイントは文書化されていますか？ それとも、実装者が暗黙知に頼る必要がありますか？
• ツールに関する知識：記載されていないセットアップ手順を計画で前提にしていませんか？
• 前提条件のいずれかが明記されていない場合、実装準備は整っていません。

ディメンション 7：見積もりのずれ

考えてください： フロントマターの見積もりは最終的な計画とまだ一致していますか？ それとも、スコープの確定によってコストが変わりましたか？

• 完了前の見積もりは大まかなスコープの推測に基づきますが、最終化されたフェーズから実際のコストが明らかになります。各フェーズファイルの確定済みタスク／TC から bottom_up_hours = Σ phase_hours を再算出し、現在のフロントマターの man_days_traditional／story_points と比較してください。
• SYNC:estimation-framework に従って、likely_days、risk_margin_pct、min-max range を再計算してください。不確実要素が解消された場合（マージンは下がるはずです）や、新たなリスクが明らかになった場合（マージンは上がるはずです）を確認してください。
• |delta| > 20% の場合、フロントマターに reestimate_delta_pct: <signed> と1行の reestimate_reason を必ず追加してください。更新がない場合は FAIL です。
• |delta| > 50% の場合、レビュー判定で SHOULD-RESCOPE を指摘してください。実装開始前に、スコープ変更の判断をユーザーに提示しなければなりません。
• 隠れた増加に注意してください。計画中にフェーズが追加されていないか、TC が当初の見積もりに含まれていたか、統合作業が後から判明していないかを確認してください。

Dimension 8：ドメインエンティティ設計（条件付き — 計画がエンティティ、VO、または集約に触れる場合に実行）

考えること： 計画ではドメインモデルを実際に決定していますか。それとも、難しい部分を実装に先送りしていますか。

SYNC:domain-entity-change-gate（以下にインラインで記載）を適用します。これは、$plan が作成時に従い、$changes-review がレビュー時に従うのと同じプロトコルであり、A–P のチェックリストは $domain-entities-review が管理します。該当しない場合は、No domain-entity surface — Dimension 8 N/A と記載します。

• 未回答、曖昧な説明、または実装への先送りがある判断ポイントは、計画内の file:line を示す FINDING です。タスク内に「entity」という単語があるだけでは、決定したことには決してなりません。
• MUST ATTENTION は、エンティティに関するタスクの前に、計画でパラダイムとサブドメインとの適合性が示されていることを確認します。CRUD サブドメインにリッチなドメインモデルを提案する計画は FINDING です（保護すべき不変条件のない儀式にすぎません）。不変またはイベントソーシングされたモデルに対してセッターやカプセル化のタスクを提案する計画も同様です。
• 該当する各項目について、意図だけでなく担当ファイルが明記されているか確認します。分類・不変条件の所有権と失敗の通知・集約境界と並行性・構築と再構成の区別・イベント・プロパティ TC のテスト要件。
• 特に見落としやすい点：真の不変条件ではなく UI 画面や DB テーブルを基準に集約境界を決めている・集約間の参照がオブジェクトナビゲーションとして計画されている・競合するルートに並行性トークンがない・集合ベースの不変条件（「メールアドレスが一意」など）に強制する仕組みがない・不変条件がエンティティではなくバリデーターやハンドラーに計画されている・イベントのディスパッチ時期が計画されていない。
• 指摘する前に、計画の境界選択を最も妥当な形で捉えます。常に一貫性を保つ必要がある真の不変条件を守るため、意図的に大きな集約を選ぶのは正しいことです。求めるのはより小さな境界ではなく、不変条件です。

次元を使って、的を絞った、根拠のある質問を作成してください。「もっと詳しく記載する」といった一般的な提案はしないでください。

---

ミッション

実装計画を自己レビューし、妥当性、正確性、ベストプラクティスを確認して、実装に進む前に修正が必要なすべての点を明らかにします。

重要な違い： AI による自動の自己レビューであり、$plan-validate のようなユーザーへのヒアリングではありません。

計画の解決方法

1. $ARGUMENTS が指定されている場合 → そのパスを使用します
2. それ以外の場合は、## Plan Context セクション → アクティブな計画パスを使用します
3. 計画が見つからない場合 → エラー：「No plan to review. Run $plan first.」

ワークフロー

フェーズ 0：計画の種類を判定する

チェックリストに進む前に、必ず plan.md を読み、計画を分類します。理由：種類によって、サブエージェント、重点項目、Behavioral Delta Matrix が必須かどうかが決まります。

計画に含まれるシグナル	種類	追加のレビュー重点項目
タイトルまたは説明に「fix」「bug」「regression」「defect」が含まれる	Bugfix	Behavioral Delta Matrix（必須）、保持対象の一覧、回帰テスト
「migrate」「schema」「database」「index」が含まれる	Data/Schema	ロールバック手順、ダウンタイムゼロの戦略、データ保持、マイグレーションの冪等性
「auth」「permission」「security」「encrypt」「token」「RBAC」が含まれる	Security	脅威モデリング、攻撃対象領域、信頼境界の変更、サブエージェント：security-auditor
「performance」「latency」「cache」「N+1」「throughput」が含まれる	Performance	ベースライン指標、リグレッションのリスク、測定戦略、サブエージェント：performance-optimizer
「refactor」「extract」「rename」「restructure」が含まれる	Refactor	動作の保持、影響範囲、参照切れ
「API」「contract」「endpoint」「consumer」「event」が含まれる	Contract/Integration	後方互換性、コンシューマーへの影響、バージョン管理戦略
「infra」「CI」「pipeline」「deploy」が含まれる	Infrastructure/DevOps	ロールバック計画、環境の同等性、シークレットの取り扱い
上記のいずれにも該当しない	Feature	標準チェックリスト、受け入れ基準との対応付け、YAGNI

複数のシグナルに該当する場合は、すべての種類を列挙し、それぞれの重点項目をすべて適用します。

計画の種類によって決まる項目：

• 使用するサブエージェントの種類（上記の「サブエージェントの種類の選択」を参照）
• Adversarial Review Mindset のどのセクションを重点的に確認するか
• Behavioral Delta Matrix が必須かどうか（バグ修正のみ）

---

ステップ 1：計画ファイルを読む

計画ディレクトリを読みます。

• plan.md — 概要、フェーズ一覧、フロントマター
• goal.md — Goal Contract（存在する場合）：Original Request、Purpose、Success Criteria（必須か任意か）、Constraints
• phase-*.md — すべてのフェーズファイル
• 抽出する項目：要件、実装手順、ファイル一覧、リスク

{plan-dir}/goal.md が存在しない場合は、plans/goals/{YYMMDD-HHmm}-{slug}/goal.md を参照します。Goal Contract がまったく存在しない場合は、No active goal — plan reviewed against plan.md requirements only. と記録します。

ステップ 2：チェックリストに照らして評価する

妥当性（必須 — すべて合格すること）

#	チェック項目	有無	品質の深さ
1	エグゼクティブサマリーがある — 明確な1〜2文の説明	サマリーセクションはありますか？	正確ですか？作業の範囲を明確にしていますか、それとも複雑さを隠していますか？
2	要件セクションが定義されている — 要件が明示されている	要件セクションはありますか？	要件は具体的なユーザーニーズですか、それとも曖昧な技術目標ですか？
3	実装手順がある — 実行可能なタスク	実装手順はありますか？	手順は具体的ですか（ファイル名、メソッド名など）、それとも曖昧な作業ですか？
4	作成／変更するファイルの一覧がある — ファイル一覧が記載されている	ファイル一覧はありますか？	ファイルパスは実在しますか（glob／grepで確認済みですか）？プロジェクトの規則に従っていますか？

正確性（必須 — すべて合格すること）

• 粒度ゲート —「詳細かつ十分に小さい」 — いずれかのフェーズが以下の基準のいずれかに不合格の場合、失敗です。そのままコードに着手できない計画は、準備ができていません。

判断フロー — 各フェーズに適用してください：

Phase too vague? (no file paths, planning verbs, unclear actions)
  → YES → DETAIL IT: add specific file paths, exact method names, concrete actions
  → NO ↓
Phase too big? (>5 files OR >3h effort OR single step is a mini-project)
  → YES → BREAK IT: split into smaller sibling phases until each meets limits
  → NO → PASS this phase

5項目の基準（各フェーズですべて合格すること）：

#	基準	合格例	不合格例
1	手順で具体的なファイルを指定している	「{source-root}/auth/loginを変更する」	「認証を実装する」
2	計画を表す動詞を使っていない	「validateToken()メソッドを追加する」	「最適な認証方法を決定する」
3	各手順の所要時間が30分以内	「エンドポイントにエラーハンドラーを追加する」	「認証モジュール全体を構築する」
4	フェーズあたり5ファイル以下、かつ3時間以内	3ファイル、2時間	12ファイル、8時間
5	未解決の判断事項がない	アプローチがすべて決定済み	「未定：使用するライブラリ」

失敗につながる計画動詞：「調査する」「決定する」「把握する」「判断する」「評価する」「検討する」「調べる」—これらは実装計画ではなく、調査段階で行うことです。

不合格の場合の対応（指摘事項の検証ゲート通過後）：

現在の計画レビュー報告に対して$why-review --validate-findingsがCLEANを返すまで、以下の改善を適用しないでください。

• 曖昧すぎる → その場で改善する：ファイルパス、メソッド名、具体的な作業を追加して手順を詳しくする
• 大きすぎる（9ファイル以下） → フェーズを同階層の複数フェーズに分割する（フェーズ2A、2B、2C）
• 大きすぎる（10ファイル以上） → サブプランを作成する：{plan-dir}/sub-plans/phase-{XX}-{name}/plan.md

作業例： 不合格：「フェーズ2：データ層 — データベースモデルを設定する、リポジトリを作成する、データアクセスパターンを実装する。所要時間：4時間、ファイル：約8個」 分割後は合格：「フェーズ2A：データスキーマ（1時間、3ファイル）— {source-root}/models/user-entityを作成する、{source-root}/models/session-entityを作成する、{migration-root}/create-users-sessionsを作成する」＋「フェーズ2B：リポジトリ層（1.5時間、3ファイル）— {source-root}/repositories/user-repositoryを作成する、{source-root}/repositories/session-repositoryを作成する、{composition-root}に登録する」

• ファイルパスがプロジェクトのパターンに従っている
• 手順に矛盾や重複がない
• 手順間の依存関係が明確である
• ハルシネーション防止・コード証拠ゲート — 既存のソースコードに関する計画上の主張にfile:lineによる証拠がない場合、失敗です。 | 主張の種類 | 必要な証拠 | | ---------------------- | --------------------------------- | | ファイルパス | ファイルが存在する（glob/read） | | クラス／メソッド名 | シンボルを grep → file:line | | 動作（「X が Y を呼び出す」） | コードの証拠 file:line | | 基底クラス／インターフェース | 継承を検証済み（grep/graph） |

失敗条件： 読み取りを確認していないファイルパス、grep していないメソッド名、既存コードについて「〜のはず」「おそらく」「通常は」といった表現、このコードベースではなく類似プロジェクトを根拠に推測した動作。既存コードへの参照がない新規開発のみの計画 → 合格。

• 新しい技術／ライブラリの確認： プロジェクトに含まれていないパッケージ／ライブラリ／フレームワークを計画に導入する場合、代替案を評価済み（上位 3 件を比較）で、ユーザーが選択を確認済みであることを検証します。評価なしに新しい技術を追加している場合は不合格です。
• テスト仕様の網羅性 — すべてのフェーズに TC の対応付けを含む ## Test Specifications セクションがあること。「TBD」は TDD ファーストモードでは有効です。
• TC と要件の対応付け — すべての機能要件が 1 つ以上の TC に対応していること（または根拠を明記した明示的な「TBD」があること）。
• 動作の維持 — 動作を変更するフェーズでは、期待される動作、維持する変更対象外の動作、および TC／テストによる証明を明記していること。
• ドキュメント／仕様／テストの同期 — 該当するフェーズに、正式な仕様／ドキュメント／テストの更新、または明示的な N/A の根拠が含まれていること。
• 成果物の最新性 — AI が抽出した仕様／TC は承認されるまで参考のみと明記されていること。共有ワークフロー／スキル／ツールの変更には、生成されたミラーの同期が含まれていること。
• Goal Contract との対応付け — 有効な goal.md がある場合、保存済みのすべての必須成功基準が 1 つ以上のフェーズで網羅され、各フェーズの成功基準が保存済みの基準に紐付いていること（または理由を添えて補助作業と明記されていること）。保存済みの必須基準を網羅するフェーズがない場合、または記録された正当な理由なく Goal Contract にない作業を計画に含めた場合は不合格です。Goal Contract がない場合は、No active goal の証拠を示してスキップします。

ベストプラクティス（必須 — すべて合格すること）

#	チェック項目	有無	品質の深さ
1	YAGNI — 不要な機能や過剰な設計がない	計画したすべてのコンポーネントが、明記された要件に紐付いているか？	現在の要件がないのに「役立つかもしれない」と説明されているものや、将来の柔軟性のために追加されたものがあれば指摘します。
2	KISS — 実行可能な最もシンプルな解決策を選んでいる	主な各ステップに方針が示されているか？	同じ効果を得られる、よりシンプルな抽象化はないか？不要なレイヤー、間接化、フレームワークの選択はないか？
3	DRY — ロジックの重複を計画していない	類似したパターンが複数回記述されていないか？	既存のパターンで対応できるのに、新しいパターンを導入していないか？実装時の重複を示唆する手順の繰り返しはないか？
4	アーキテクチャ — .claude/docs/ のプロジェクトパターンに従っている	計画が .claude/docs/ のパターンを参照するか、整合しているか？	確立されたパターンに従っているか、逸脱しているか？逸脱がある場合は、根拠を添えた明示的な正当化が必要です。

網羅性（推奨 — 50％以上の項目に合格）

#	チェック項目	有無	品質の深さ
1	軽減策を含むリスク評価がある — リスクを特定し、対応策を示している	リスクのセクションに少なくとも1項目あるか？	軽減策は具体的なアクション（担当者、時期、実施のきっかけ）か、それとも曖昧な意図（「注意深く監視する」）か？
2	テスト戦略が定義されている — テスト方針が概要として示されている	テストのセクション、または各フェーズのテストに関する記述があるか？	単体テスト、統合テスト、エッジケースの経路を網羅しているか、それとも「テストを書く」だけか？方針は受け入れ基準に関連付けられているか？
3	フェーズごとの成功基準 — 測定可能な成果が定義されている	各フェーズに成功基準が明記されているか？	基準は測定可能か？基準を満たせなかった場合、ロールバックが実行されるか、それとも努力目標にとどまるか？
4	セキュリティに関する考慮事項に対処している — セキュリティ上の懸念が記されている	セキュリティのセクション、または本文中にセキュリティに関する注記があるか？	セキュリティ上の懸念は、この機能の攻撃対象領域に特有のものか、それとも一般的な定型文（例：「HTTPSを使用する」「入力を検証する」）か？
5	グラフの依存関係を確認している — 変更したファイルのインポーターを確認している	.code-graph/graph.db が存在する場合、変更したファイルごとに importers_of クエリを実行しているか？	直接の呼び出し元だけでなく、すべてのインポーターを確認しているか？graph.db が前提条件であることを明記しているか？見落とした依存先にフラグを付けているか？

ステップ 3：採点して分類する

ステータス	基準	アクション
PASS	必須項目すべてに合格し、推奨項目の50％以上に合格	実装に進む
WARN	必須項目すべてに合格し、推奨項目の50％未満に合格	注意して進め、不足事項を記録する
FAIL	必須チェック項目のいずれかに不合格	停止 — 先に修正する必要がある

ステップ 4：結果を出力する

## Plan Review Result

**Status:** PASS | WARN | FAIL
**Reviewed:** {plan-path}
**Date:** {current-date}

### Summary

{1-2 sentence summary of plan quality}

### Checks Passed ({X}/{Y})

#### Required ({X}/{Y})

- ✅ Check 1
- ✅ Check 2
- ❌ Check 3 (if failed)

#### Recommended ({X}/{Y})

- ✅ Check 1
- ⚠️ Check 2 (missing)

### Issues Found

- ❌ FAIL: {critical issue requiring fix}
- ⚠️ WARN: {minor issue, can proceed}

### Recommendations

1. {specific fix 1}
2. {specific fix 2}

### Verdict

{PROCEED | REVISE_FIRST | BLOCKED}

計画の網羅性をグラフで追跡する

グラフ DB が利用可能な場合、計画が影響を受けるすべてのファイルを網羅していることを確認します。

• 計画の「変更対象ファイル」リストにある各ファイルについて、python .claude/scripts/code_graph trace <file> --direction downstream --json を実行します
• 計画に記載されていない下流ファイルには、「見落としの可能性あり」とフラグを付けます
• これにより、計画の作成者が見落としていた可能性のある、サービス間の影響（MESSAGE_BUS のコンシューマー、イベントハンドラー）を検出できます

再帰的な修正・レビュー手順（重大）

手順： SYNC:double-round-trip-review + SYNC:fresh-context-review + SYNC:review-protocol-injection（すべてこのファイルの上部にインライン化されています）。

レビュー結果が FAIL、WARN、またはゼロ以外の指摘事項となった場合、plan-review はプランファイルを編集する前に、必ず指摘事項検証ゲートを実行する必要があります。修正できるのは、$why-review --validate-findings によって検証された指摘事項のみです。検証済みの対応可能な指摘事項を修正した後、現在のプランに対して最初のレビュー手順から plan-review の全プロトコルを再実行します。既知の指摘事項を修正する前に、再レビューだけを目的として新しいサブエージェントを起動してはいけません。再開した全レビューでサブエージェントを使用する場合は、以下の SYNC:review-protocol-injection にある標準の Agent テンプレートを使用し、過去の修正についての記憶を一切持たずに、すべてのプランファイルを最初から読み直します。

指摘事項検証ゲート（プランの指摘事項を修正する前に必須）

plan-review の出力に指摘事項がひとつでも含まれる場合、このゲートを実行します。対象には、FAIL、WARN、プランの編集を必要とする推奨事項、証拠の不足、未解決のリスク、実装を妨げる曖昧さが含まれます。完了したレビューで指摘事項がゼロの場合のみ、このゲートを省略できます。または、第 3 ラウンド以降は、検証済みの指摘事項が LOW のみである場合に限り、それらを保留として記録し、PASS とします。

1. 別のレビュアーが検証できるだけの十分な証拠とともに、すべての指摘事項を含む plan-review レポートを完成させます。
2. プランファイルを編集する前に、メインのレビューフローでそのレポートに対して $why-review --validate-findings を実行します。
3. why-review が CLEAN を返した場合は、検証済みの対応可能な指摘事項のみを、最も適切な最小範囲のプラン箇所で修正します。
4. why-review が指摘事項に異議を唱える、却下する、または範囲を絞る場合は、まず plan-review レポートを調整し、その後、修正を行う前に $why-review --validate-findings を再実行します。
5. 指摘事項が妥当でも、プロダクトまたは担当者の判断が必要な場合は、不確実な点を回避するように編集するのではなく、作業を止めてユーザーに確認します。

このゲートを通過する前に、レビューの指摘事項を修正する目的で plan.md または phase-*.md を編集してはいけません。 このゲートは指摘事項を検証するものです。検証済みの修正サイクルが完了した後にのみ、新たな全 plan-review を実施します。

ラウンド N（N≥2）の Agent 呼び出しプロンプトを作成する場合：

1. SYNC:review-protocol-injection テンプレートから Agent 呼び出しの形式をそのままコピーします。
2. agent_type: "general-purpose" を使用します（これはプランレビューであり、コードレビューではありません）。
3. 以下の SYNC ブロックの本文全体を、一字一句そのまま埋め込みます（このスキルファイルの上部にインライン化されています）：SYNC:evidence-based-reasoning、SYNC:rationalization-prevention、SYNC:graph-assisted-investigation、SYNC:understand-code-first（プランファイルには適用されない、SYNC:bug-detection、SYNC:test-spec-verification などのコード固有のプロトコルは省略します）。
4. Task を "Review plan files under {plan-dir}. Validate structural completeness, code-proof anti-hallucination (every file:line claim about existing source code must exist), and adversarial simulation (imagine implementing each phase right now — what fails first?)." に設定します。
5. Target Files を "read plan.md and all phase-*.md files under {plan-dir}" に設定します。
6. レポートのパスを plans/reports/plan-review-round{N}-{date}.md に設定します。

サブエージェントからの返答後：

1. サブエージェントのレポートを読みます。
2. 指摘事項を ## Re-Review {N} Findings としてメインレポートに統合します。指摘事項を除外したり、覆したりしてはいけません。
3. FAIL、WARN、または指摘事項が残っている場合： 指摘事項検証ゲートを実行し、検証済みの対応可能な指摘事項のみをプランファイルで修正した後、最初のレビュー手順から plan-review の全プロトコルを再開します。
4. 同一ブロッカーの反復上限： 同じブロッカーが進展なく 2 回の全実行で繰り返された場合は、ユーザーに直接確認してエスカレーションします。
5. 最終判定には、実際に実施したすべてのレビューパスの指摘事項を反映する必要があります。

フロー

┌──────────────────────────────────┐
│  Round 1: Main-session review    │
│  (structural checklist + basic   │
│   code-proof trace)              │
│  Output: PASS / WARN / FAIL      │
└──────────────┬───────────────────┘
               │
        ┌──────▼──────┐
        │ ZERO        │
        │ FINDINGS?   │──YES──→ Proceed to next workflow step
        └──────┬──────┘
               │ NO
        ┌──────▼──────────────────────────────────┐
        │  VALIDATE: Run $why-review              │
        │  --validate-findings on the report.     │
        │  Only validated findings may be fixed.  │
        └──────┬──────────────────────────────────┘
               │
        ┌──────▼──────────────────────────────────┐
        │  FIX: Modify plan files to resolve       │
        │  validated actionable findings           │
        │  (plan.md/phase-*)                       │
        └──────┬──────────────────────────────────┘
               │
        ┌──────▼──────────────────────────────────┐
        │  Round 2+: FULL PLAN RE-REVIEW          │
        │  Re-run the complete plan-review        │
        │  protocol from the first review step.   │
        │  If the protocol uses agents, spawn     │
        │  new agents for that restarted pass.    │
        └──────┬──────────────────────────────────┘
               │
               └──→ Loop until the round's bar is clear (zero findings rounds 1-2; zero CRITICAL/HIGH/MEDIUM round 3+), repeated-blocker rule, or 3-round cap

イテレーションルール

1. 同一ブロッカーの上限 — そのラウンドの基準を満たす完全なレビューを通過するまで続けます（ラウンド1～2では指摘ゼロ、ラウンド3以降ではCRITICAL／HIGH／MEDIUMがゼロで、LOWのみなら終了）。同じブロッカーが進展のないまま完全な実行を2回続けて繰り返す場合は、STOPしてユーザーに直接質問し、エスカレーションします
2. ラウンド数を記録 — 各サイクルの開始時に「Plan review Round N (full re-review)」を記録します
3. 指摘ゼロで終了 — 完全なプランレビューで指摘がなかった場合にのみ先へ進みます。ユーザー／オーナーが対応不要と明示的に承認しない限り、WARNも指摘として扱います
4. スコープの縮小 — 各ラウンドで見つかる問題は、前のラウンドより少なくする必要があります。Round NでRound N-1より多く見つかった場合は、STOPしてエスカレーションします
5. 修正範囲 — why-reviewで検証済みの対応可能な指摘についてのみ、プラン内の最も適切な箇所を最小限修正します。プランを書き直してはいけません
6. 修正方法：
   • 曖昧な手順 → 具体的なファイルパスと実行内容を追加して明確にします
   • セクションの不足 → 追加します（リスク、テスト戦略、成功基準）
   • 手順の矛盾 → 矛盾を解消し、その理由を記録します
   • 過剰な設計 → 簡素化し、不要な複雑さを取り除きます
   • TCマッピングの不足 → TC参照、または理由を添えた「TBD」を追加します
7. 検証済みの修正サイクルごとに — 最初のレビュー手順から完全なプランレビュープロトコルを再実行します。再開したプロトコルでエージェントを使う場合は、新しいAgent呼び出しを行い、以前のエージェントを再利用してはいけません
8. 黙って別の方法に切り替えない — 同じブロッカーが進展のないまま完全な実行を2回続けて繰り返す場合は、ユーザーに直接質問してエスカレーションします。以前のプロトコルに切り替えてはいけません

次のステップ

• 指摘ゼロでPASSの場合（またはラウンド3以降で、延期扱いのLOWのみが記載されたPASSの場合）：「Plan review complete. Proceeding with next workflow step.」と伝えます
• WARNまたはその他の指摘が残る場合：Findings Validation Gateを実行します。プランファイルでは検証済みの対応可能な指摘のみを修正するか、対応不要なリスクについてユーザーに明示的な承認を求めます
• FAILの場合：Findings Validation Gateを実行し、プランファイルでは検証済みの対応可能な指摘のみを修正したうえで、完全なプランレビュープロトコルを再帰的に再実行します
• 同一ブロッカーの上限に達した場合：残っている問題を列挙します。STOPします。ユーザーに直接質問し、プランを修正するか再生成するよう依頼します

重要な注意事項

• 細かい点にこだわらず、建設的に対応します。実装上の問題につながる指摘に注目します
• WARNは自動的に終了する条件ではありません。対応可能なら修正し、対応不要なら先に進む前に明示的な承認を記録します
• FAILは本当に必須の内容が不足している場合に限ります。低い重大度の指摘も、解決するか明示的に承認されるまで追跡します
• 簡易レビューは絶対に行わないでください — 実際のテストでは「単純な」プランでも13件のバグが見つかっています。必ず宣言された完全なレビュープロトコルを実行し、任意のラウンド数を理由に途中でやめてはいけません

---

スキル間の連携（単独実行：ユーザーに直接質問する必要があります。ワークフロー内の場合はスキップしてください。）

必須 — 例外なし このスキルの完了後、必ずユーザーに直接質問して、次の選択肢を提示してください。タスクが「単純」または「明白」に思える場合も省略してはいけません。判断するのはユーザーです。

• 「Proceed with full workflow (Recommended)」 — ここから続けるのに最適なワークフローを検出します（プランレビュー済み）。これにより、検証、実装、テスト、ドキュメントの手順を省略せずに進められます。
• 「$plan-validate」 — プランの前提条件を確認するため、ユーザーに質問します
• 「$feature-implement」または「$plan-execute」 — プランが承認済みで、実装の準備ができている場合
• 「Skip, continue manually」 — ユーザーが決定します

[BLOCKING] これは検証ゲートです。レビュー結果を提示し、ユーザーの確認を得るため、必ずユーザーに直接質問してください。少なくとも1つ質問せずに完了することは違反です。 [IMPORTANT] 作業を始める前に、タスク管理を使って、読み込む各ファイルのタスクを含むすべての作業を小さなタスクに分割してください。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合は、省略してよいかを AI がユーザーに尋ねてください。

重要な目的： 品質を確保します。欠陥、バグ、更新漏れ、古い内容がないようにしてください。コードとドキュメントの両方を検証してください。

外部メモリ： 複雑または長時間にわたる作業（調査、分析、スキャン、レビュー）では、中間調査結果と最終結果を plans/reports/ のレポートファイルに記録してください。これにより、コンテキストの喪失を防ぎ、成果物として活用できます。

エビデンスゲート： 必須 — すべての主張、発見事項、推奨事項には、file:line 形式の根拠、または信頼度のパーセンテージを付した追跡可能な証拠が必要です。信頼度が 80％を超える場合は対応し、80％未満の場合は先に検証してください。

OOP と DRY の徹底： 必須 — 基底クラス、ジェネリック、またはヘルパーに抽出すべき重複パターンを指摘してください。同じグループ（同じサフィックス、同じライフサイクル、同じ目的）に属するクラスは、共通の基底クラスを共有する必要があります（現時点では空でも構いません。将来の共通ロジックや子クラスでのオーバーライドに備えられます）。プロジェクトで、その技術スタック向けのコードリンター／アナライザーが設定されていることを確認してください。

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

入力状態	修正前の動作	修正後の動作	差分
{条件}	{現在の動作}	{修正後の動作}	維持 ✓ / 修正 ✓ / リグレッション ✗

ルール： 3 行以上 · バグ報告で言及されていない行を 1 行以上含める · 差分がリグレッションの場合、その動作を維持するテストでカバーするまで FAIL とします（spec-tests-template.md#preservation-tests-mandatory-for-bugfix-specs）。

次の条件を満たすまで BLOCKED： 3 行以上 · バグ報告の範囲外の行を 1 行以上含む · 軽減されていないリグレッションがない

グラフを活用した調査 — .code-graph/graph.db が存在する場合は必須です。

必須ゲート： 調査を完了する前に、主要なファイルについて少なくとも 1 つのグラフコマンドを実行しなければなりません。

手順： Grep でファイルを特定 → trace --direction both でシステム全体のフローを把握 → Grep で詳細を検証

タスク	最低限必要なグラフ操作
調査／偵察	エントリーファイル 2～3 個に対して trace --direction both を実行
修正／デバッグ	バグのある関数に対して callers_of と tests_for を実行
機能追加／拡張	変更対象のファイルに対して connections を実行
コードレビュー	変更した関数に対して tests_for を実行
影響範囲の確認	trace --direction downstream を実行

CLI： python .claude/scripts/code_graph {command} --json を使用します。まず --node-mode file を指定してください（ノイズを 10～30 分の 1 に抑えられます）。次に --node-mode function を指定して詳細を確認してください。 サービス間チェック — マイクロサービス／イベント駆動型：調査、計画、仕様書、機能ドキュメントを完了と判断する前に必ず実施します。下流のコンシューマーを見落とすと、気付かれないままリグレッションが発生します。

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

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

以下が完了するまで保留： プロデューサーの調査 · コンシューマーの調査 · Saga の確認 · コントラクトのレビュー · 破壊的変更のリスクの指摘

新鮮なコンテキストでの再レビュー — 該当する場合は独立したサブエージェントを使ってレビュー全体を最初からやり直し、修正後にオーケストレーターが陥る確証バイアスを排除します。

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

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

方法：

1. レビュー全体を新たに実行し、タスクを再度分解します。そのプロトコルでエージェントが必要な場合は、新しい spawn_agent ツール呼び出しを起動します。コードレビューには code-reviewer の agent_type を、計画／ドキュメント／成果物のレビューには 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 回繰り返された場合は、ユーザーに直接確認してエスカレーションします

• 反復回数と繰り返し発生するブロッカーは、会話コンテキスト内で追跡します（セッション内のみ。永続ファイルは使いません） ネストされたタスク展開の契約 — ワークフローのステップを呼び出す場合、[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 にすることが完了していること。

タスク追跡と外部レポートの永続化 — 実行前にこれを初期化し、その後、対象ファイルやソースの作業に取りかかる前にプロジェクト参照ドキュメントを事前取得します。

1. 対象ファイルの読み込み、検索、編集、分析の前に、小規模なタスクの内訳を作成します。コンテキストを失った場合は、まず現在のタスクリストを確認します。
2. 作業前にタスクを1つ in_progress にし、根拠を記録した直後に completed にします。遷移をまとめて実行しないでください。
3. 計画やレビューの作業では、最初の所見を記録する前に plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md を作成します。
4. 各ファイル、セクション、判断の後に所見を追記し、最後にレポートファイルをもとに内容をまとめます。
5. 最終出力には Full report: plans/reports/{filename} を記載します。

ブロック解除の条件： タスクの内訳が作成され、計画やレビューの作業ではレポートパスが宣言され、次の所見に進む前に最初の所見が保存されていること。 見積もりフレームワーク — まずボトムアップで見積もり、SP は DERIVED とします。3日以上になりそうな場合は最小値と最大値の範囲で出力します。スタックに依存しません。基準：開発経験3〜5年、1日あたり生産的な作業時間6時間。AI見積もりでは Claude Code とプロジェクトのコンテキストを前提とします。

手法：

1. 影響範囲の確認（下記）— コードとテストのコストに影響します
2. フェーズに分解 → フェーズごとの時間を算出 → bottom_up_hours = Σ phase_hours
3. likely_days = ceil(bottom_up_hours / 6) × productivity_factor
4. リスクマージン（基本値＋加算分）を合計 → max_days = likely_days × (1 + margin)
5. min_days = likely_days × 0.9
6. likely_days ≥3 の場合は範囲で出力します。<3 の場合は単一の値でも構いません（ただしマージンは記録します）
7. man_days_ai = 同じ範囲 × AI による高速化率
8. story_points は SP-Days を使って likely_days から DERIVED します。決して見積もりの基準にしません。乖離が50%を超える場合は、ボトムアップの見積もりを優先します

生産性係数： 足場となるコード＋コード生成＋AI フックが充実している場合は 0.8 · 成熟した標準的な場合は 1.0 · パターンが弱い場合は 1.2 · 新規開発の場合は 1.5

コスト要因のヒューリスティック（作業種別の行を選ぶ前に適用）：

• UI が支配的なのは CRUD／業務アプリの場合です — バックエンドの1.5〜3倍（状態、バリデーション、レスポンシブ対応、アクセシビリティ、仕上げ）
• バックエンドが支配的なのは次の場合のみです： 複数集約にまたがる不変条件、サービス間コントラクト、スキーマ移行、複雑なクエリ／パフォーマンス、新しいイベントフロー

再利用か新規作成か（レイヤーごとの最重要要因）：

UI の段階	コスト
既存画面でコンポーネントを再利用	0.1-0.3d
既存画面にコントロール／列を追加	0.3-0.8d
コンポーネントを組み合わせて新しい画面を作成	1-2d
独自レイアウト／状態／バリデーションの新画面	2-4d
新しい共有／共通コンポーネント（テーマ適用、テスト済み）	3-6d+

バックエンドの段階	コスト
新しい場所でクエリ／ハンドラーを再利用	0.1-0.3d
既存ハンドラー／エンティティの小規模な更新	0.3-0.8d
既存リポジトリ／モデルに新しいクエリを追加	0.5-1d
既存集約に新しいコマンド／ハンドラーを追加（拡張）	1-2d
新しい集約／エンティティ（リポジトリ、バリデーション、イベント）	2-4d
新しいサービス間コントラクトまたはスキーマ移行	各 2-4d
複数集約にまたがる不変条件／複雑なドメインルール	3-5d

ルール： UI＋バックエンド＋テストの各段階を合計し、生産性係数を適用します。再利用できる場合は段階を省略できます — その旨を明記します。

テスト範囲の要因（test_count を明示的に算出してください。「＋テスト」という曖昧な記載が失敗原因の第1位です）：

要因	件数
正常系のユーザージャーニー	ストーリー／AC の主要フローごとに1件
状態遷移	到達可能な遷移 × 許可されたアクター
複数エンティティの状態の組み合わせ	state(A) × state(B) — 到達可能な組み合わせのみ。直積ではありません
認可マトリクス	(所有者、非所有者、権限昇格済み、未認証) × 各変更操作
バリデーションルール	必須フィールド／境界値／形式／フィールド間チェックごとに1件
UI の状態（新しい画面／ダイアログごと）	正常、読み込み中、空、エラー、一部表示 — 存在する状態のみ
異常系／不変条件	違反可能な業務ルールごとに1件

テスト段階（従来方式、セットアップ＋アサーション＋不安定さを含む）	コスト
1-5 件、フィクスチャを再利用	0.3-0.5d
6-12 件、新しいフィクスチャ1つ	0.5-1d
13-25 件、複数エンティティのセットアップ	1-2d
26-50 件、または新しい状態遷移の網羅	2-3d
>50 件、または E2E ジャーニー全体	3-5d

テストの倍率： 新しいフィクスチャ／シード用ハーネス +0.5d · サービス間／バスのアサーションは各 +0.3d · UI E2E は ×1.5 · 新しいロールごとに +1-2 件

影響範囲（必須の事前確認 — コードとテストの両方に影響）：

1. 直接変更するファイル／コンポーネント — 件数
2. そのうち「複雑なもの」（>500 LOC、複数ハンドラー、中心的、頻繁に変更されるもの）— 件数
3. 下流の利用者（呼び出し元、イベント購読者、サービス間）— 一覧
4. 共有／共通コードへの変更（複数アプリに影響）— yes/no
5. 回帰テストの範囲 — 再テストが必要な領域

ルール： 複雑な箇所に触れる場合は risk_factors に追加します。下流の利用者ごとに回帰テストを +1-3 件追加します。影響範囲が5領域を超える、または複雑な箇所が2つを超える場合は、見積もり前に SPLIT を再検討します。

リスクマージン（最大値を決定）：

likely_days	基本マージン
<1d 軽微	+10%
1-2d 小規模な拡張	+20%
3-4d 実質的な機能	+35%
5-7d 大規模	+50%
8-10d 非常に大規模	+75%
>10d	+100% AND 分割を推奨

リスク要因の加算分（加算方式 — risk_factors に列挙）：

要因	+マージン
touches-complex-existing-feature（>500 LOC、複数ハンドラー、中心的）	+20%
cross-service-contract の変更	+25%
schema-migration-on-populated-data	+25%
new-tech-or-unfamiliar-pattern	+30%
regression-fan-out（再テストが必要な下流領域が3つ以上）	+20%
performance-or-latency-critical	+20%
concurrency-race-event-ordering	+25%
shared-common-code（複数の利用者／アプリ）	+25%
unclear-requirements-or-design	+30%

上限ルール： マージンの合計が100%を超える場合は、作業を停止して分割します（2倍を超える水増しは不誠実です）。likely_days ≥5 でマージンが15%未満の場合は、過小見積もりです。範囲を広げてください。

作業種別の上限（likely_days の厳格な上限）：

作業種別	最大 SP	最大 likely
単一フィールド／設定フラグ／スタイル修正	1	0.5d
既存モデルにプロパティを追加し、既存 UI にバインド	2	1d
拡張エンドポイント＋軽微な UI コントロール（ボタン／メニュー／列）、フィクスチャを再利用	3	2-3d
拡張エンドポイント＋新しい UI 表面、または複数レイヤーの拡張＋新しいドメインルール＋テストファイル2つ以上	5	3-5d
新しいモデル／集約、移行、モジュール間コントラクト、重いテスト（>1.5d）、または新しい UI＋無視できないバックエンド	8	5-7d
新しい UI 表面＋（新しい集約、移行、またはサービス間コントラクト）	13	分割を推奨
サービス間コントラクト＋移行の組み合わせ	13	分割を推奨
これを超える場合	21	分割必須

SP→日数（検証専用）： 1=0.5d/0.25d · 2=1d/0.35d · 3=2d/0.65d · 5=4d/1.0d · 8=6d/1.5d · 13=10d/2.0d（従来方式／AI の likely） AI による高速化： SP 1≈2倍 · 2-3≈3倍 · 5-8≈4倍 · 13以上≈5倍。AI コスト = (code_gen × 1.3) + (test_gen × 1.3)（レビューのオーバーヘッド30%）。

必須のフロントマター：

story_points: <n>
complexity: low | medium | high | critical
man_days_traditional: '<min>-<max>d' # likely が3日以上の場合は範囲、3日未満の場合は '<N>d'
man_days_ai: '<min>-<max>d'
risk_margin_pct: <n> # 基本値＋加算分
risk_factors: [touches-complex-existing-feature, regression-fan-out] # 加算要因の選択肢から指定。該当なしの場合は []
blast_radius:
    touched_areas: <n>
    complex_touched: <n>
    downstream_consumers: [list or count]
    shared_common_code: yes | no
estimate_scope_included: [code, integration-tests, frontend, i18n, docs]
estimate_scope_excluded: [unit-tests, e2e, perf, deployment, code-review-rounds]
estimate_reasoning: |
    以下を含む5〜7行：
    (a) UI の段階 — 適用した行
    (b) バックエンドの段階 — 適用した行
    (c) テスト範囲 — 要因ごとのケース内訳、ファイル数、フィクスチャ、段階の行
    (d) コスト要因 — 支配的な段階とその理由
    (e) 影響範囲 — 変更箇所、複雑な箇所、回帰テスト範囲
    (f) リスク要因 — マージンの要因となるものの一覧と、さらに大きく／小さくならない理由
    例：「UI：Form/Table/Dialog を組み合わせて新画面を作成（約1.5d）。バックエンド：既存集約に新しいコマンドを追加し、
    バリデーションとリポジトリを再利用（約1d）。テスト：遷移4件 × 2アクター＋バリデーション3件＋UI 状態2件 = 13件、
    新しいフィクスチャ1つ → 13-25 件の段階で約1.5d。要因：UI の組み合わせと新しい状態。影響範囲：4領域、複雑な箇所1つ。
    リスク：基本値35%＋複雑な箇所への変更20% = 55% → 最大3.9d → 範囲2.5-4d。」

妥当性のセルフチェック：

• likely_days ≥3d なのに単一の値になっている？ → 不採用。必ず範囲にする
• likely_days ≥5d なのにマージンが15%未満？ → 過小見積もりです。範囲を広げる
• マージンが100%を超えている？ → 停止して、バッファを増やすのではなく分割する
• 既存の複雑な機能に触れるのに、(c) に回帰テストの予算がない？ → 不採用
• 影響範囲が5領域を超える、または複雑な箇所が2つを超えるのに、分割の検討がない？ → 不採用
• 既存モデルと既存 UI への追加だけ？ → テストが1.5dを超えない限り SP は3を上限とする
• 新しい UI 表面（ページ／複雑なフォーム／ダッシュボード）がある？ → バックエンドが単一エンドポイントでも SP 5以上
• バックエンドにサービス間連携／移行／複数集約がある？ → UI に関係なく SP 8以上
• bottom_up_hours / 6 と SP-Days の乖離が50%を超えている？ → ボトムアップの見積もりを優先し、SP を下げる
• テストがない場合に SP が1段階以上下がる？ → テストが支配的な要因です。明記する
• 推論で UI とバックエンド、影響範囲、リスク要因に触れている？ → 不足があれば追加する 批判的思考の姿勢 — 批判的思考と逐次的思考を適用します。すべての主張について根拠を追跡し、確信度が80％を超えてから行動します。 ハルシネーション対策： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実性があれば率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合してください。自分の確信度にも懐疑的でいてください。証拠のない確信こそ、あらゆるハルシネーションの根源です。

逐次的思考プロトコル — 複雑または曖昧な作業に対する、体系的な複数ステップの推論です。一度きりの推論では安全でない、計画、レビュー、デバッグ、アイデアの改善に使用してください。

次の場合に使用： 複雑な問題の分解 · 修正が必要な適応型計画 · 軌道修正を伴う分析 · 不明確または発展中のスコープ · 複数ステップの解決策 · 仮説主導のデバッグ · 複数領域にまたがるトレードオフの評価。

形式（明示モード — 思考の経過を可視化）：

1. Thought N/M: [aspect] — 1つの思考につき1つの観点を扱い、前提や不確実性を明示します
2. Thought N/M [REVISION of Thought K]: ... — 以前の推論が無効になった場合に使用します。元の内容／修正理由／影響を明示します
3. Thought N/M [BRANCH A from Thought K]: ... — 別の選択肢を検討し、判断理由とともに結論を出します
4. Thought N/M [HYPOTHESIS]: ... の後に [VERIFICATION]: ... — 行動する前に検証します
5. Thought N/N [FINAL] — 検証済みで、重要な観点すべてに対応し、確信度が80％を超えている場合に限ります

必須の締めくくり： 確信度（％）を明記 · 前提を列挙 · 未解決の質問を示す · 次の具体的な行動を示す。

停止条件： 重要な判断の確信度が80％未満の場合 → ユーザーに直接質問して確認します · 同じ思考を3回以上修正した場合 → 問題を捉え直します · 分岐が3つを超えた場合 → サブタスクに分割します。

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

詳細： API 設計、デバッグ、アーキテクチャの実例、高度な手法（段階的な改善、仮説検証、収束）、メタ戦略（不確実性への対処、修正の連鎖）については、$sequential-thinking スキル（.claude/skills/sequential-thinking/SKILL.md）を参照してください。 プロジェクト参照ドキュメントのゲート — タスク追跡の初期化後、対象ファイルやソースファイルの読み取り、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/ 配下の元となる Feature Specs、アーキテクチャ／新しい領域は project-structure-reference.md。
4. 必須ドキュメントをすべて読み、対象作業に着手する前に次の形式で記載します：Reference docs read: ... | Not applicable: ...。

準備完了の条件： スコープを評価し、docs/project-config.json を参照し、必須ドキュメントを確認・読了するかセットアップ手順を完了し、lessons.md を確認して、参照情報を記載していること。

まずコードを理解する — 厳格なゲート：既存のコードを読むまで、書き込み、計画、修正を行わないでください。

1. 類似パターンを3つ以上検索します（grep／glob）。根拠として file:line を記載します
2. 対象領域にある既存ファイルを読み、構造、基底クラス、規約を理解します
3. .code-graph/graph.db が存在する場合は、python .claude/scripts/code_graph trace <file> --direction both --json を実行します
4. connections または callers_of で依存関係をマッピングし、対象に依存する要素を把握します
5. 重要なタスク（3ファイル以上）の調査内容を .ai/workspace/analysis/ に記録します
6. 実装前に分析ファイルを読み直します。記憶だけを頼りに作業してはいけません。— 理由：長いコンテキストではファイルから注意が逸れるためです。ファイルが真実の基準です
7. 既存のパターンが使える場合、新しいパターンを決して考案しないでください。完全に一致させるか、逸脱を記録します。— 理由：パターンの不統一はコードベースを分断し、後から読む人すべての作業を遅らせるためです

次の条件を満たすまで作業不可： - [ ] 対象ファイルを読んだ - [ ] 3つ以上のパターンをgrepした - [ ] グラフのトレースを実行した（graph.db が存在する場合）- [ ] 想定を根拠と照らして検証した 検証済み指摘の修正＋完全な再レビューのループ — 再レビューは、ラウンド数ではなく、検証済み指摘の修正サイクルをきっかけに行います。レビューの目的は、review → validate findings → fix validated findings → full re-review を繰り返し、完全なレビューの合格によって、そのラウンドの終了基準を満たすことです（下記の重大度の下限を参照）。レビューに問題がなければループは終了します。以降のラウンドは不要です。

別名、自己レビュー収束ループ。 この名前は歴史的なものです。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)を必ず含めます。 レビュー用プロトコルの埋め込み — 新しいサブエージェントのレビュー用プロンプトには、11 個のプロトコルブロックを必ず逐語的に埋め込んでください。以下のテンプレートには、11 個すべての本文がすでにインラインで展開されています。テンプレート全体を Agent 呼び出しの prompt フィールドに実行時にコピーし、Task／Round／Reference Docs／Target Files／Output セクションの {placeholders} だけを状況に応じた値に置き換えてください。埋め込まれたプロトコルセクションには手を加えないでください。

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

サブエージェントの種類を選択する

• code-reviewer — コードレビュー（ソースファイル、git の差分、実装のレビュー）に使用します
• 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 を選択してください
• いかなるプロトコルセクションも言い換えたり、要約したり、省略したりしないでください
• ファイルの内容をインラインで渡さないでください。サブエージェントは独自のツール呼び出しで読み込むため、最新のコンテキストを得られます
• プロトコルをファイルパスやタグ名で参照しないでください。本文はすでに上記に埋め込まれています
• プロトコル用のプレースホルダーマーカーを追加しないでください。本文は展開された状態のままにしてください

AI の誤り防止 — すべてのタスクで避けるべき失敗パターン：

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

重大度	対応	定義
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. 必須セクション： 元のリクエスト、目的、成功基準（チェックボックス形式。必須と任意を明記）、制約、必要な証拠、反復ログ、ゴール充足マトリクス。
3. 作業前： 有効なゴールを読み、予定する作業を保存済みの成功基準に対応付けます。実行は保存済みの基準に基づくものとし、チャットの記憶だけに頼ってはいけません。
4. 実行／検証後： 結果、証拠への参照（file:line、コマンド出力、レポートのパス）、残っている不足点を反復ログに追記します。
5. レビュゲート： ゴール充足マトリクスを出力します。形式は | Success Criterion | Evidence | Status | とし、ステータスには PASS/FAIL/BLOCKED を使用します。すべての必須基準が PASS の場合にのみ、全体を PASS とします。
6. ループ規則（再試行）： 必須基準が FAIL → 不足が実際にあることを検証 → 修正 → 影響を受ける基準のみを再レビュー。必須基準がすべて PASS になった時点で、適切に終了します。
7. エスカレーション規則（停止）： 基準が進展しない反復が 2 回連続した場合、またはユーザーの入力が必要なブロッカーがある場合 → ユーザー向けの理由を添えて該当基準を BLOCKED にし、エスカレーションします。無期限にループしてはいけません。
8. スキップ規則： 短い会話上のタスクでは、記録済みの一行の理由がある場合に限り、ゴールファイルを省略できます。ユーザーが受け入れたゲートのスキップは、理由と範囲をゴールファイルに記録します。
9. セキュリティ： ゴールファイルにシークレット、トークン、認証情報、非公開の顧客データを決して保存してはいけません。証拠への参照を保存し、機密値はマスキングします。

以下が満たされるまでブロック： 有効なゴールを特定済み（またはスキップ理由を記録済み） · 編集前に保存済みの成功基準を確認済み · 実行後に反復の証拠を追記済み · PASS 判定の前にゴール充足マトリクスを出力済み トレードオフの確認ゲート — いかなる判定、スコア、指摘、推奨を出す前にも、必ず次の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 と判定することはできません。また、重大度の低い注記として埋もれさせてはなりません。

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

ドメインエンティティ変更ゲート — ドメインエンティティ、値オブジェクト、または集約に触れる変更を計画・実装・レビューするすべてのスキルまたはエージェントを拘束する単一のプロトコルです。これにより、プランナー、実装者、レビュー担当者が、同じ変更に同じルールを適用します。完全な A–P チェックリストの正式な所有者は $domain-entities-review です。このゲートは、共通のトリガーと、回答必須の判断項目を定めます。より弱い独自のチェックリストを決して作り直さないでください。理由：計画とレビューでエンティティのルールが食い違うと、レビューで却下される設計を計画が出荷し、手戻りのコストが二重にかかるためです。

トリガー — 次のいずれかに該当すると発動します： 新しいエンティティ／値オブジェクト／集約ルートが導入される · 既存のものにフィールド、不変条件、関係、または状態遷移が追加・削除される · 集約境界、リポジトリ、または集約をまたぐ参照が変更される · ドメインイベントが追加、改名、またはペイロード変更される · ルートの並行性または再構成に関する懸念が変更される。該当するものがない場合は、No domain-entity surface — gate N/A と記載します。

ステップ 1 — 判断する前に検出します。 どちらの回答も、適用されるルールを左右します：

• パラダイム（集約ごとにコードから判定し、決して推測しない）：OO 可変 · 型駆動／不変 · イベントソーシング。セッター、可変性、再構成のルールは OO 可変向けです。他の 2 つに適用すると、誤った指摘や不要な計画タスクが生まれます。
• サブドメインとの適合性： コア（リッチモデルが必要） · 支援（Active Record または軽量モデル） · 汎用（購入し、モデル化しない） · CRUD（トランザクションスクリプト — ここでのリッチエンティティは形式だけのものです）。必須フィールド以外に不変条件がないサブドメインでは、リッチモデルを決して計画したり、指摘したりしないでください。

ステップ 2 — 6 つの判断項目すべてに回答します。 それぞれ、変更において明示的に判断しなければならない事項です：

#	判断項目	回答済みとなる条件
1	分類 — エンティティ、値オブジェクト、集約ルートのいずれか	入れ替えテスト（「同一のコピーと交換可能か？」）を適用している。値オブジェクトは不変で構造的等価性を持ち、リポジトリを持たない
2	不変条件の所有者 — エンティティは「この状態は存在可能か？」を所有し、境界は「この入力は受け入れ可能か？」を所有する	各ルールがどちらか一方に配置され、明示されている。失敗の通知方法（例外または Result）がプロジェクトの規約と一貫している。DB 制約は最後の防衛線であり、ルールでは決してない
3	集約境界と並行性	常に一貫性を保つべき真の不変条件だけを同じ集約にまとめる。集約をまたぐ参照には ID を使う。1 つのトランザクションで変更する集約は 1 つ。並行性トークンはルートが持つ。集合ベースの不変条件（インスタンス間の一意性）には、実際に強制する仕組みを明記し、メモリ内チェックは決して使わない
4	生成と再構成	生成と読み込みの経路が分かれている。読み込み経路ではドメインイベントを一切発行せず、生成ルールも一切再実行しない。必須データはコンストラクター／ファクトリーに置く
5	イベント	集約内で発行する。コミット後にディスパッチする（プロセスをまたぐ場合はアウトボックスを使用）。内部ドメインイベントと公開する統合契約を区別する。ハンドラーは冪等である
6	テストの要件	各不変条件を、全称量化されたプロパティ TC と境界の反例ケースの両方に対応付ける。仕様書で明示し、テストで GUARDED する（Dual-Feedback）。正常系の例が 1 つあるだけでは、カバレッジとは言えない

ステップ 3 — コンテキストに応じて適用します。 判断項目は同じですが、求められる対応は異なります：

呼び出し元のコンテキスト	要件
計画（$plan）	計画では、該当する各項目について判断内容と、それを担当するファイルを明記しなければなりません。未回答の項目がある計画は実行可能ではありません。実装で判明するまで放置せず、表面化させてください。
計画レビュー（$plan-review）	未回答、曖昧な説明、または実装への先送りがある項目は、計画内の file:line を示す指摘事項です。「entity」という語があるだけでは、決して回答になりません。
実装（$plan-execute、$fix、および実装を行うすべてのエージェント — 例：backend-developer）	判断事項は再検討する質問ではなく、入力です。該当する各項目を、計画／仕様で決定されたとおりに、指定された担当ファイルに実装します。未回答の項目が渡された場合はブロッカーです。表面化させて判断を得てください。キーボードを前にして黙って決めたり、計画で未決のままだからといって DB テーブルや UI 画面から集約境界を選んだりしては決していけません。どのルールを適用するかは、引き続きパラダイムとサブドメインとの適合性によって決まります。
変更レビュー（$changes-review）	所有者に引き継ぎます — モード A（デフォルト）： $domain-entities-review のフェーズ 2 の A–P チェックリストを読み、レビューの観点として適用します。モード B（エスカレーション）： 単独で実行され、差分にエンティティファイルが 3 つ以上含まれる場合は、$domain-entities-review に委任します。指摘事項は file:line と重大度を付けて通常の指摘事項セットに加えます。

重複防止 — 次のいずれかに該当する場合は、ゲート全体をスキップします。 委任を示す行を記録してから続行してください：

ゲートを抑止するコンテキスト	委任を示す行
実行中のスキル自体が $domain-entities-review である場合	Gate is this skill's own body — A–P checklist owns it.
$workflow-review-changes 内から呼び出されている場合（ステップ 5 で $domain-entities-review を専用の条件付き並列メンバーとして実行する）	Gate deferred to workflow step 5 $domain-entities-review.
$why-review が --validate-findings の終端モードで実行されている場合	Gate N/A — validate-findings is terminal, no sub-skill calls.

— 理由：このガードがないと、親ワークフローがすでに実行しているレビューと重複し、changes-review → domain-entities-review → why-review → changes-review の循環が発生します。

次のすべてを満たすまで BLOCKED： トリガーの評価が完了（または gate N/A を記録済み） · パラダイムとサブドメインとの適合性を明記済み · 該当する 6 つの判断項目すべてに回答済み、または指摘事項として提示済み · 委任の前にガード行を確認済み。 必ず注意 新しい／更新されたドメインエンティティ、値オブジェクト、または集約を変更計画の対象にする場合、あるいはレビューする場合は、Domain Entity Change Gate を適用してください。完全な A〜P チェックリストは $domain-entities-review が担当します。まずパラダイムとサブドメインへの適合性を判定し、その後、6 つの判断ポイント（分類・不変条件の所有者と失敗の通知・集約境界と並行性・構築と再構成・イベント・property-TC テストの義務）すべてに回答してください。計画では各判断を明記し、計画レビューでは未回答の項目を FINDING として扱います。変更レビューでは担当者に振り分けてください（Mode A は読み取り、Mode B は委任）。3 行重複ガードに該当する場合はスキップし、延期の記録行を残してください。理由：プランナーとレビュアーで同じプロトコルを共有することで、レビューで却下されるエンティティ設計を計画が出荷する事態を防げます。

重要・必ず注意 変更を加える前に、既存パターンを 3 つ以上検索し、コードを読んでください。graph.db が存在する場合は、グラフトレースを実行してください。

• 必須・重要・必ず注意 すべての主張について、file:line の根拠を示してください。確信度が 80% を超える場合に実行し、60% 未満の場合は推奨しないでください。

• 必須・重要・必ず注意 レビューループ（別名 Self-Review Convergence Loop）を実行してください。レビュー → 指摘事項の検証 → 検証済みの指摘事項の修正 → 全体の再レビュー、の順です。指摘事項がゼロの完全なレビューが完了した時点でレビューを終了してください。新たに生成した出力や判断には、少なくとも 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 回続いた場合のブロッカールールは、それより早い終了条件です。どちらか先に該当した時点でエスカレーションしてください。終わりのないループは厳禁です。

重要・必ず注意 graph.db が存在する場合は、主要ファイルに対して少なくとも 1 つのグラフコマンドを実行してください。パターン：grep → グラフトレース → grep で検証。

重要・必ず注意 マイクロサービス／イベント駆動型の場合、タスク範囲内のプロデューサー、コンシューマー、サーガ、コントラクトを調査してください。接点ごとに、担当者・メッセージ・コンシューマー・リスク（NONE／ADDITIVE／BREAKING）を確認してください。コンシューマーの見落としは、気付かれない回帰につながります。

• 必須・必ず注意 見積もり：ボトムアップで算出したフェーズごとの時間を man_days_traditional に反映してください（Σh/6 × productivity_factor）。SP は導出値です。通常、UI のコストが大部分を占めます。新しい UI サーフェス（ページ／複雑なフォーム／ダッシュボード）がある場合は、SP を 1 段階引き上げてください。フロントマターには story_points、complexity、man_days_traditional、man_days_ai、estimate_scope_included、estimate_scope_excluded、estimate_reasoning（UI とバックエンドのコスト要因）を必ず含めてください。既存モデルと既存 UI への追加であれば、テスト範囲が 1.5 日を超える場合を除き、SP は 3 を上限とします。SP 13 は分割を推奨し、SP 21 は必ず分割してください。

必ず注意 クリティカルシンキングとシーケンシャルシンキングを適用してください。すべての主張には適切な追跡可能な根拠が必要です（リポジトリ／コードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または成果物のセクション）。確信度が 80% を超える場合に実行し、60% 未満の場合は推奨しないでください。ハルシネーションを防ぐため、推測を事実として述べないでください。不確実性は率直に認め、独立した情報源と照合し、自分の確信度にも懐疑的でいてください。

必ず注意 シーケンシャルシンキングを適用してください。複数ステップでは Thought N/M、REVISION／BRANCH／HYPOTHESIS マーカー、より正確な確信度（%）を使ってください。$sequential-thinking スキルを参照してください。 必ず注意 AI による誤りを防止してください。生成した内容を証拠と照合して確認し、削除または名前変更の前に下流の参照をたどり、影響を受けるすべての出力を検証し、コンテキストを失った後はファイルを読み直し、行動する前に曖昧さを明らかにしてください。

• 必須 対象作業に着手する前にタスク追跡を開始し、一度に1つのタスクだけを次の状態へ移行してください。

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

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

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

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

• 必須 親ワークフローの行で子フェーズの追跡を代替することはできません。ネストしている場合はフェーズを展開し、親にリンクしてください。

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

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

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

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

• 必須 スコアベースのスキル（sre の 0～2、perf の2軸評価）は、同じ4段階の影響度に対応付けてください。別の重要度用語体系を並行して使用してはいけません。

プロンプト強化の終了時に守るべきルール

重要・必ず注意 このスキルで定められたステップの順序に従ってください。ユーザーの明示的な承認なしに、ステップを省略、並べ替え、統合してはいけません。 重要・必ず注意 各ステップ／サブスキル呼び出しでは、実行前に in_progress にし、実行後に completed にしてください。 重要・必ず注意 スキップした各ステップには明示的な理由を記載してください。完了した各ステップには簡潔な証拠を記載してください。 重要・必ず注意 Task ツールを使用できない場合は、ステップごとの同等の計画トラッカーを用意し、ステータスを同期してください。

• 必須：必ず注意し、トレードオフに関する3つの質問を必ずすること — レビュー対象と、行うすべての推奨について、次の3点を確認してください。（1）トレードオフはあるか？ 何を犠牲にするのかを明示してください（変更コスト・複雑さ・パフォーマンス・結合度・可逆性・移行・運用負荷・影響範囲・セキュリティ・テスト容易性・提供までの時間・UX）。「なし」／「完全なメリット」では分析が不十分です。確認した観点を明記してください。（2）それに見合う価値はあるか？ 利得（指標を添える）とコスト、誰が負担するか、いつ負担するかを比較し、価値あり／価値なし／不明と判定してください。価値なしの場合は、提案を撤回するか、別の案に置き換えてください。（3）ユーザーに確認するほど重要か？ 取り消せない変更／後戻りできない選択・別のチーム／運用担当者／メンテナー／ユーザーへのコスト転嫁・ある品質特性を別の品質特性と引き換えにすること・階層／サービス／イベント／ライブラリの境界を越えること・認証／金銭／データ整合性／破壊的変更／High または Medium リスクの経路・判定が不明の場合は、判定を止め、判定を出す前にユーザーへ直接確認してください。
• 必須： ユーザーの確認を得ていない重要なトレードオフがある場合、決して 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つのメッセージで並列サブエージェントとして起動します。ワークフロー、バッチ更新、調査、リサーチ、レビューはデフォルトで並列化します。計画の実行では、計画で宣言された内容に基づく場合にのみファンアウトします。
• 必須 ウェーブごとに書き込み対象を重複させない · 次のウェーブに進む前に全員の返答を待つ · 専門家に割り当てる · サブエージェント自身のエージェント定義で許可されていない限り、サブエージェントがさらにファンアウトすることは絶対にありません。

プロジェクトプロトコルオーバーレイ — このスキルを実行する前に、スキルに適用されるプロジェクトのオーバーレイルールを解決してください。プロジェクトのスキルプロトコルインデックス（デフォルトでは 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 から読み込みます。本文が欠落または不正な形式の場合は報告し、再構成してはいけません。オーバーレイは追加のみ（このスキル独自のルールを置き換えません）であり、概要であって権限を強化するものではありません。同じ具体性の矛盾はユーザーに提示してください。

最後に確認する事項

重要・必ず注意 Goal： 幻覚がなく（既存コードに関する主張がすべて file:line で証明されている）、実装準備が整っている（すべての手順が具体的で、すぐにコードを書けるほど小さい）計画以外は、実装に進ませないでください。完全なレビューで指摘がゼロになるまで、再帰的にレビューを繰り返してください。

重要・必ず注意 主な手順（順番どおりに、各タスクを1つずつ実行）： Phase 0 で計画の種類を検出 → Step 1 で plan.md／goal.md／すべての phase-*.md を読む → Step 2 で4つのチェックリストグループ（妥当性・正確性［粒度＋幻覚防止＋仕様／TC 網羅性＋Goal-Contract マッピング］・ベストプラクティス・完全性）＋11の敵対的手法＋バイアス防止ゲート＋8つの計画ディメンションを評価し、変更対象の各ファイルをグラフ追跡する → Step 3 で PASS／WARN／FAIL を採点する → Step 4 で結果を出力する → Step 5 で $why-review による再帰的な検証を行う → 検証済みの指摘を修正する → 指摘がゼロになるまで全体を再レビューする。理由：AI はスキル自身の手順を忘れ続けます。これ以外を読まない場合は、この順序に従ってください。

重要・必ず注意 適用中のプロトコル（このスキルが引き継ぐ SYNC／共有ブロックの簡潔な要約）： 各行は上記の正式な本文を示すものです。この要約を正式なブロックの代わりとして扱ってはいけません。以下のすべてのプロトコルを、必ず全文に従って適用してください。

• 動作差分マトリクス： バグ修正のレビューでは、判定の前に input × pre × post × delta の表を作成します。
• グラフ支援による調査： graph.db が存在する場合、主要ファイルに対してグラフコマンドを1つ実行します。
• サービス横断チェック： プロデューサー、コンシューマー、サーガ、コントラクトをスキャンします。コンシューマーの欠落は、気づかれないリグレッションにつながります。
• 新鮮なコンテキストでのレビュー： 修正サイクルごとに、ゼロメモリーのサブエージェントを起動し、最初から読み直させます。
• ネストされたタスクの作成： 子フェーズのタスクを展開します。ネストする場合は、親ワークフローの行にリンクします。
• タスク追跡と外部レポート： タスクの内訳を初期化し、調査結果を plans/reports/ に随時保存します。
• 批判的思考： すべての主張に、追跡可能な file:line の根拠が必要です。推測を事実として提示してはいけません。
• 段階的な思考： 複数ステップの思考では、REVISION／BRANCH／HYPOTHESIS マーカーを付けた Thought N/M を使い、最後に確信度を示します。
• プロジェクト参照ドキュメント： 対象作業の前に、必須のプロジェクト参照ドキュメントを読みます。規約は一般的なデフォルトより優先されます。
• まずコードを理解する： 変更を加える前に、3つ以上のパターンを grep し、コードを読みます。
• 2回のラウンドトリップレビュー： レビュー → 調査結果の検証 → 修正 → クリーンになるまで全体を再レビューします。
• レビュープロトコルの注入： 11個すべてのプロトコル本文を一字一句そのまま、レビューごとに新たに作成するプロンプトへ埋め込みます。
• AI の誤り防止： 生成内容を根拠と照合し、下流の参照を追跡し、影響を受けるすべての出力を検証し、コンテキスト喪失後に読み直し、曖昧さを明示します。
• 重大度の基準： 影響に基づいて Critical／High／Medium／Low に分類します。Critical／High は PASS を阻止します。
• サブエージェントの並列ディスパッチ： タスクに PAR／SEQ のタグを付け、PAR のタスクを互いに書き込み対象が重複しないウェーブにまとめます。各ウェーブは1つのメッセージで起動し、次へ進む前にバリアを設けます。 重要・必ず注意 バリデーターではなく懐疑的な立場でレビューしてください。あなたの仕事は、正しく見える内容を肯定することではなく、実現できない点を見つけることです。判定を下す前に、完全な Anti-Bias Gate（現実性チェック、前提のストレステスト、プレモーテム、却下した代替案のスティールマン、逆張りの観点からの再確認）を実施してください。理由：確証バイアスによって、よく整った計画がそのまま承認されてしまうためです。 必須・重要・必ず注意 Anti-Hallucination Gate：既存のソースコードに関する計画内の主張すべてに、file:line の証拠が必要です（ファイルの存在確認、シンボルの grep、コードを追跡した動作確認）。既存コードについて「〜のはず」「おそらく」「通常は」と述べた場合は FAIL です。グリーンフィールドのみの計画は PASS です。 必須・重要・必ず注意 粒度ゲート「詳細かつ十分に小さい」：5 ファイル超、3 時間超、または計画系の動詞（調査する／特定する／決定する／評価する／検討する／調べる）を含むフェーズはすべて FAIL としてください。曖昧すぎる場合は詳細化し（ファイルパス、正確なメソッド名を記載）、大きすぎる場合は兄弟フェーズ／サブプランに分割してください。理由：すぐにコーディングに取りかかれない計画は、準備ができていません。 必須・重要・必ず注意 まず計画の種類を検出してください（フェーズ 0）。バグ修正では Behavioral Delta Matrix が必須です（3 行以上、バグ報告の範囲外が 1 行以上含まれること。REGRESSION があれば、保全テストでカバーされるまで FAIL）。セキュリティ／パフォーマンス／リファクタリング／コントラクト／インフラでは、それぞれ固有の観点を追加してください。 必須・重要・必ず注意 spec-loop のスケジュール設定：すべての [HARD] §4 ルール／§5 不変条件について、プロパティ／不変条件テストの仕様を計画に含め、MUTATION-SCORE の品質基準を設定してください。ラインカバレッジ率を目標にし、mutation-score の基準を設定していない計画は FAIL です。 必須・重要・必ず注意 指摘事項が 1 件でもある場合、plan.md／phase-*.md を編集する前に $why-review --validate-findings を実行してください。検証済みの指摘事項のみを、責任箇所の最小範囲で修正し、その後、記憶を引き継がない新しいサブエージェントで完全なレビューを最初からやり直してください。クリーンな判定になるまで繰り返してください。このゲートに合格する前に計画ファイルを編集してはいけません。理由：未検証の修正は計画を損ない、レビューを無駄に繰り返す原因となるためです。 必須・重要・必ず注意 ラウンド上限は 3 回です。これは上限であり、目標ではありません。クリーンな判定が出た時点で、ラウンド数にかかわらずただちにループを終了してください。同じ阻害要因が、進展のない完全な再レビューで 2 回連続して残った場合、指摘事項が残ったまま 3 回目が終わった場合、または指摘事項にプロダクト／オーナーの判断が必要な場合は、ユーザーに直接相談してください。3 回を超えてループしてはいけません。また、上限到達を PASS にしてはいけません。 必須・重要・必ず注意 読み取り／grep／編集を始める前に、ブートストラップ用のタスク追跡とタスク分解を行ってください（ファイルを読むごとに 1 タスクを割り当てる）。指摘事項は plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md に逐次保存し、ディスク上の内容をもとに統合してください。最後のレビュータスクも追加してください。理由：長い計画ファイルはコンテキストを使い切るため、レポートファイルを正本とする必要があるためです。 必須・重要・必ず注意 .code-graph/graph.db が存在する場合は、「変更対象ファイル」の各項目についてグラフトレースを実行してください。計画に記載されていない下流ファイルがあれば「見落としの可能性あり」として指摘してください。理由：作成者が見落としたサービス間／イベントハンドラーへの影響を検出するためです。 必須・重要・必ず注意 ディメンション 7 — 見積もりのずれ：適用されている SYNC:estimation-framework に従い、最終確定したフェーズファイルをもとに bottom_up_hours = Σ phase_hours を再算出し、frontmatter と比較してください。|delta| > 20% の場合、frontmatter に reestimate_delta_pct と 1 行の reestimate_reason を必ず記載してください。更新されていない場合は FAIL です。|delta| > 50% の場合は SHOULD-RESCOPE として指摘し、実装前にスコープ変更の判断をユーザーに提示してください。理由：完了前の見積もりは推測したスコープに引きずられ、実際のコストが見える最初の場所はロック済みフェーズとなるためです。 必須・重要・必ず注意 ディメンション 8 — ドメインエンティティ設計（条件付き）：計画がエンティティ、値オブジェクト、または集約に関わる場合は、SYNC:domain-entity-change-gate を適用してください。これは $plan が作成時に従い、$changes-review がレビュー時に従うものと同じプロトコルです。未回答、曖昧な説明、または実装時まで先送りされた判断事項は、計画内の file:line を示す指摘事項です。タスク内に「entity」という語があるだけでは回答になりません。エンティティに関するタスクを始める前に、パラダイムとサブドメインへの適合性が明記されていること、また、該当する各行に担当ファイルが記載されていることを確認してください。該当しない場合は No domain-entity surface — Dimension 8 N/A と記載してください。理由：データベーステーブルや UI 画面を基準に集約境界を決定すると、実装後に覆すコストが最も高くなるためです。 必須・重要・必ず注意 単独実行の最後には、指摘事項と次の選択肢を提示して、ユーザーに直接確認してください。ワークフロー内でのみ省略できます。 必須・重要・必ず注意 すべての指摘事項に file:line の証拠を引用してください（確信度が 80% 超なら対応し、60% 未満なら推奨しない）。仕様／テスト／コードの見解が一致していない状態で記録済みの指摘事項もない場合は、決して PASS としてはいけません。 必須・重要・必ず注意 レビュー前に以下を読んでください：.claude/docs/development-rules.md、docs/project-reference/code-review-rules.md、lessons.md、およびスキル固有のパターン参照資料（backend／frontend／integration-test）。 反合理化：

言い逃れ	反論
「計画は妥当に見える」	構造があること ≠ 正しいことです。既存コードに関する主張はすべて file:line で証明してください。もっともらしい文章は証拠ではありません。
「フェーズは明確に定義されている」	フェーズがあること ≠ 実装可能であることです。各フェーズに5項目の粒度ゲートを適用してください。
「レビューは1回で十分」	検証済みの指摘を修正するサイクルの後にのみ再レビューしてください。問題のない COMPLETE パスでループを終了します。
「実装時に不足分を補える」	曖昧なステップは今すぐ FAIL にしてください。実装は計画を実行するものであり、計画を考案するものではありません。
「代替案も検討した」	それは本物の代替案でしたか。それとも、失敗するよう仕立てた藁人形でしたか。却下した案を最も強い形で提示してください。
「リスクは管理されている」	「注意深く監視する」は軽減策ではありません。具体的な行動、担当者、発動条件を求めてください。
「コードはすでに追跡した」	file:line または grep の証拠を提示してください。証明がなければ、追跡したことにはなりません。

[タスク計画] 作業に取りかかる前に、タスクの範囲を分析し、タスク管理を使って小さなタスクとサブタスクに体系的に分解してください。最後に最終レビューのタスクを追加してください。

---

最後にもう一度 — 成功の指標は変更しやすさです。 すべての指摘、 テスト、リファクタリング、抽象化について、次の変更を 安くするのか、高くするのかという問いに答えてください。将来の 変更コストを下げないものは却下してください。結合、隠れた状態、知識の重複、意図の不明瞭さこそが本当の敵です。名前を挙げて指摘してください。

重要・必ず注意 目標：幻覚がなく（file:line の証拠があり）、実装準備が整っている（具体的で、十分小さなフェーズで構成されている）ことを確認できるまで、どの計画も実装に進ませないでください。問題のないレビューになるまでループしてください。 重要・必ず注意 懐疑的な立場でレビューしてください。既存コードに関する主張にはすべて file:line の証拠を求めてください。曖昧または大きすぎるフェーズは FAIL にしてください。バグ修正には Behavioral Delta Matrix を適用してください。 重要・必ず注意 計画ファイルを編集する前に $why-review --validate-findings を使って指摘を検証してください。検証済みの指摘だけを修正し、指摘がゼロになるまでレビュー全体をやり直してください。

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

ソース：.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. 実行： コンテキスト指示にある Workflow Step Advancement & Parallel Phases のルールに従って進めます。ステップの進行はモデル主導です。サブエージェントの完了はインライン呼び出しと同様にステップを進めます。並列フェーズのグループは全員の完了を待つバリアです（すべてのメンバーが完了した後にのみ進み、決して逐次化しません）。

共有 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、ビジネスエンティティ、機能ルール）を一切参照してはいけません。漏れがコンパイルされ、実行されると、再利用可能なはずの層が一つの利用側と結合していても、レビューで気づかれずに通過してしまいます。共有型からドメイン情報を排除し、サブクラス化／コンポジションを通じて、ドメインフィールド／ロジックを利用側へ移してください。理由：一つの利用側のドメインに結合した層は、もはや再利用可能ではありません。