review-changes

Name: review-changes
Author: duc01226

github.com/duc01226テスト・品質1248 回インストール1 週間前に更新

リポジトリ

review-changes について

コード、ドキュメント、設定、インフラなどの Git 差分をレビューするスキルです。ファイルと行番号を示す根拠付きで指摘を記録し、検証と再レビューの手順に回します。

主な機能

01作業ツリー、ステージ済み、ブランチ、コミットの差分をレビュー
02ファイルと行番号の根拠で変更を確認
03レビュー報告を作成
04指摘を検証と再レビューに回す
05ドキュメントとテストカバレッジを確認

活用シーン

01引き渡し前にブランチをレビュー
02差分から欠陥や古いドキュメントを発見
03動作変更のテストカバレッジを確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/duc01226/easyplatform --skill review-changes

インストール後、Claude Code で/review-changesを入力して読み込まれたか確認します。

詳細

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 の実行を依頼してください。自動実行してはいけません。

状況に応じたドキュメント：

バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-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 ツールを利用できない場合は、同じステータス遷移を含む同等の手順別プラン管理を作成し、維持してください。

[TOP REMINDER — WHY-REVIEW FINDINGS-VALIDATION GATE IS NON-NEGOTIABLE]

このレビューで、スタンドアロンモードにおいて何らかの指摘（Critical／High／Medium／Low）が1件でも発生した場合、修正、ドキュメント更新、コミット、引き継ぎの前に、スキル呼び出しで --validate-findings <report-path> を指定して $why-review スキルを必ず呼び出してください。このゲートを満たす方法は、実際にスキルを呼び出すことだけです。指摘された file:line を自分で読み直すこと、「自己検証」、インラインでの対応や手動での代替は、いずれも認められません。

最初の指摘を記録した時点で、すぐに ToDo を作成してください。記憶に頼ってはいけません。 タスク管理を呼び出し、[Review Phase 6] Why-review findings validation gate — invoke $why-review を追加してください。これによりゲートの進捗が管理され、見落としを防げます。$workflow-review-changes の中では、レポートの作成後に停止してください。検証は親の手順 2 が担当します。プロトコルの詳細はフェーズ 6に、同じ内容は末尾の終了時の注意事項にも記載されています。

クイックサマリー

目標： コード、ドキュメント、設定、インフラ、その他の非コード成果物を対象に、現在の作業ツリー、ステージ済みの変更、ブランチ、またはコミットの差分をレビューし、正確性に関するバグ、欠陥、更新漏れ、古いドキュメント、規約からの逸脱を、根拠とともに見つけます。これにより、レビュー対象のすべての変更が欠陥のない、根拠に裏付けられた、規約に準拠した状態となり、引き継ぎ前に必要なテストやドキュメントとの同期が完了していることを確認します。コードファイルが変更された場合は、コードが変更しやすい状態に保たれていることも確認します。

概要： これだけは読んでください、という要約 —

レポート主導で、証拠を必須とします。 すべての指摘を plans/reports/code-review-{date}-{slug}.md に file:line の証拠付きで記録します。推測は禁止です。「問題なさそう」は判定になりません。教科書的なルールよりも、コードベースの慣例（3 件以上の例を grep で確認）を優先します。
指摘を見つけても、自動修正はしません。 単独モードでは、validate（Phase 6 の $why-review --validate-findings。実際のスキル呼び出し）→ fix（Phase 7）→ Phase 0 から変更全体を対象に $review-changes を再開する、という手順を、全工程で指摘がゼロになるまで繰り返します。$workflow-review-changes 内ではレポートの作成後に停止し、指摘を親に引き渡します。
コードが変更された場合、次の 3 つの委任ゲートは必須です。 Phase 3.5 の $code-simplifier（明瞭さ／保守性）、Phase 3.7 の $integration-test-review による Gate-7 の網羅性（すべての動作変更に対して、対応するテストと仕様 TC が必要）、そして、すべての動作変更に対する Spec Drift Adjudication + Dual-Feedback Ledger（ギャップを仕様とテストの両方に反映します）。
docs-update は必ず最後に実行します。 ループが収束して問題がなくなった後、Phase 8 の $docs-update を変更全体に対して必ず実行します（ワークフロー内では親に委ねる場合に限り、実行を延期します）。

振り分けの境界： このスキルは git diff（デフォルトでは作業ツリー、またはステージ済みの変更、ブランチ、コミット）をレビューします。明示的なファイルセットや SHA 範囲のレビュー、レビューへのフィードバックの処理、または対象範囲が既知の状態で完了前の検証ゲートを実施する場合は、代わりに code-review を使用してください。

共有エンジン（同期を維持）： review-changes と code-review は、同じ review-protocol の SYNC: ブロックを共有します。正規のソースは .claude/skills/shared/sync-inline-versions.md、ポリシーは SYNC:shared-protocol-duplication-policy です。一方のスキルで共有ブロックを変更した場合は、正規ファイルともう一方のスキルも更新し、両者に差異が生じないようにしてください。両スキルの違いは、開始時の意図（diff と明示的な対象範囲）と diff 固有のゲート（integration-test-sync、translation-sync、Phase 3.7 の integration-test-review 網羅性ゲート）のみです。レビュー品質に違いはありません。

ワークフロー：

フェーズ 0：影響範囲 — .code-graph/graph.db が存在する場合は、最初に $graph-blast-radius スキルを呼び出します
フェーズ 0.3：変更タイプ — リスクの高い変更タイプを検出し、リスクタスクを作成します
フェーズ 0.5：計画への準拠 — 有効な計画と照合して確認します（条件付き）
フェーズ 0.7：変更箇所の検出 — AI が変更されたファイルを分類し、観点ごとのタスクを作成します
フェーズ 1：収集 — git status/diff を実行し、レポートファイルを作成します
フェーズ 2：ファイルレビュー — 変更された各ファイルをレビューし、レポートを段階的に更新します
フェーズ 3：新しいコンテキストでの確認ゲート — 指摘事項がすでにある場合はスキップします。明示的なユーザー／ワークフロー／高リスクの統合トリガーがある場合に限り、2回目のサブエージェントを実行します
フェーズ 3.5：Code-Simplifier による最適化（コードファイルの変更時は必須） — 変更されたコードファイルに対象を絞って $code-simplifier を呼び出し、明瞭さ／一貫性／保守性を高める簡素化案を洗い出します。これらを、同じ検証／修正ループに進む指摘事項として記録します（ドキュメントのみの差分はスキップ）
フェーズ 3.7：Integration-Test-Review のカバレッジゲート（動作に影響するコードの変更時は必須） — 差分全体に対して $integration-test-review を呼び出します。7 つの品質ゲートで、変更されたテストを監査します。また、ゲート 7（変更カバレッジ）では、動作が変わる本番ファイルすべてを、該当するテスト（統合テストを優先。単体テストを代わりに使う場合は理由が必要）および仕様書の TC に対応付けます。GAP／SPEC-GAP の結果は、同じ検証／修正ループに進む指摘事項として扱います（ドキュメントのみの差分はスキップし、$workflow-review-changes 内では親の専用ステップに委ねます）
フェーズ 4：仕上げ — 重大な問題、推奨事項、提案するコミットメッセージを生成します
フェーズ 5：ドキュメントのトリアージ — 古くなったドキュメントの指摘事項を、検証／修正ループ用に記録します
フェーズ 6：Why-Review による指摘事項の検証（単独実行時のみ。修正前に必須） — レポートに指摘事項が 1 つ以上含まれる場合、修正前に必ず $why-review スキルを --validate-findings 付きで呼び出し（実際のスキル呼び出しツールを使用）、すべての指摘事項が正確で、根拠に裏付けられ、妥当であり、ベストプラクティスに沿っていることを検証します。これは実際のスキル呼び出しです。自分で該当箇所を読み直すこと、「自己検証」、またはインライン／手動の代替手段では、このゲートを満たしません。このスキルが $workflow-review-changes 内のステップ 1 である場合は、レポート作成後に停止します。指摘事項の検証は、親のステップ 2 が担当します
フェーズ 7：再帰的な修正と全件再レビューのループ（単独実行時のみ） — 単独実行モードで検証済みの指摘事項が残っている場合は、自動修正してから、差分全体を対象とする新しいタスク分解でフェーズ 0 から $review-changes を再度呼び出します。レビュー全体で指摘事項が 0 件になるまで繰り返します。$workflow-review-changes 内では、計画／feature-implement／再開を親のステップ 10〜15 が担当します
フェーズ 8：必須の最終ドキュメント更新ゲート（必須 — レビュー／修正ループが収束し、問題がなくなった時点で実行） — レビューで指摘事項が 0 件になり、すべての修正が適用された後、最終ステップとして必ず変更セット全体に対して $docs-update を呼び出し、古いドキュメントが残らないようにします。これは無条件で実行します（指摘事項の有無には左右されません）。レビューで見つからなかった影響対象のドキュメントを、$docs-update が独自に検出します。$workflow-review-changes 内では、親ワークフローの $docs-update ステップが担当するため、ここでは実行しないでください

重要なルール：

レポート主導：調査結果は必ず plans/reports/code-review-{date}-{slug}.md に記録してください
必ずすべてのフェーズの ToDo タスクを作成してから開始してください
懐疑的に検証する：すべての主張に file:line の証拠が必要です
違反を指摘する前に、既存の例を3件以上 grep して規約を確認してください
DRY 違反、YAGNI／KISS に反する過剰な設計、正確性に関わるバグを積極的に確認してください
変更ファイルにソースコードが含まれる場合は、変更しやすさのゲートを実施してください。将来の編集箇所、結合度、隠れた状態、重複した知識、意図の不明瞭さ、抽象化の境界の健全性を見積もります
変更ファイルにソースコードが含まれる場合は、変更されたコードファイルに対して Phase 3.5 の $code-simplifier 最適化ゲートを実施してください。単純化の機会は、Phase 6 の検証 → Phase 7 の修正ループに流れる指摘事項です（検証せずに自動適用しないでください）
変更ファイルに振る舞いを持つコードが含まれる場合は、差分全体に対して Phase 3.7 の $integration-test-review カバレッジゲートを実施してください。すべての振る舞いの変更を、対応するテスト（インテグレーションテストを優先）および仕様上の TC に紐付ける必要があります。GAP／SPEC-GAP の判定は、同じ Phase 6 → Phase 7 のループで扱う指摘事項であり、記録だけして放置してはいけません
変更ファイルを関連ドキュメントと相互参照し、古くなったドキュメント、テスト仕様、README を指摘してください
**最終ステップとして必須：**レビュー／修正ループの指摘事項がゼロに収束したら、変更セット全体に対して Phase 8 の $docs-update スイープを必ず実施してください。無条件で実施し、判定に問題がなくても省略してはいけません。理由：コードレビューで問題がなくても、$docs-update で実際の変更との整合を取らなければ、ドキュメントは古いままだからです
指摘事項は、Phase 6 の why-review 検証で、現在の指摘事項セットが CLEAN と判定されるまで自動修正の対象になりません
修正サイクルごとに以前のレビュー結果は無効になります。Phase 0 から $review-changes を再開し、修正を含む更新後の差分全体をレビューしてください
完全なレビューで指摘事項がゼロになるまで、レビュー → 指摘事項の検証 → 修正 → 差分全体の再レビューを続けてください。指摘事項があるから、または修正サイクルでレビューを再開したからといって、新たにコンテキストを切り替えたレビューを追加しないでください

**必須：**プロジェクト固有の参考ドキュメントを見つけて読むための ToDo タスクを計画してください

コード規約のドキュメントを検索します：*code-review*、*patterns*、*conventions*、*style-guide*。見つかったものはすべて読みます

アーキテクチャのドキュメントを検索します：*architecture*、*adr-*、サービス／モジュールのルートにある README.md

変更された技術領域（バックエンド、フロントエンド、インフラなど）に関するドキュメントを探します

変更されたファイルのカテゴリに最も関連するドキュメントを読みます

前提条件：実行前に必ず読んでください：

**重要な目的：**品質を確保してください。欠陥、バグ、更新漏れ、古いコンテンツがないことを確認します。成果物とドキュメントの両方を検証してください。

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

**証拠ゲート：**必須。すべての主張、指摘事項、推奨事項には、file:line の証拠、または確信度（実行するには80％超、80％未満なら先に検証する）を付した追跡可能な証拠が必要です。

OOP と DRY の徹底：必須。基底クラス、ジェネリック、ヘルパーへの抽出が望ましい重複パターンを指摘してください。同じグループまたは同じ接尾辞を持つクラスは、現時点で空であっても必ず共通の基底クラスを継承しなければなりません。これにより、将来の共通ロジックや子クラスによるオーバーライドが可能になります。プロジェクトで使用する技術スタック向けに、コードリンター／アナライザーが設定されていることを確認してください。

コードレビュー：現在の変更またはブランチ差分

プロジェクト標準に照らして、現在の変更または明示されたブランチ／コミットの差分をレビューしてください。

レビュー対象

デフォルトでは現在の作業ツリーの変更を対象とします。ブランチ比較をユーザーが求めた場合は、明示されたブランチ／タグ／コミットの差分を対象にします。

以下を使用します：

現在の変更：git status、git diff、git diff --cached
ブランチ差分：git diff <base>...<head> および git diff --name-only <base>...<head>
コミット範囲：git diff <base>..<head> および git diff --name-only <base>..<head>

レビューマインドセット（絶対遵守）

懐疑的な姿勢を保ち、批判的思考と順序立てた思考を適用してください。あらゆる主張について、追跡可能な証拠が必要です。確信度は80％を超えていなければなりません。

実際の実装を読んで正しさを検証し、うのみにしないでください
すべての指摘に file:line の根拠を必ず含めてください（grep の結果、読み取りによる確認）
トレースで証明できた主張だけを含め、証明できない場合は報告から除外してください
前提を問い直してください。「これは実際に動くか？」→呼び出し経路をたどって確認してください
網羅性に疑問を持ってください。「これですべてか？」→関連する使用箇所を grep してください
副作用を検証してください。「これによってほかに何が壊れるか？」→利用側と依存先を確認してください
根拠なしに「問題なさそう」と言わず、何をどのように検証したかを述べてください

第一原則 — 変更しやすさ

差分にソースコードまたはコードに関連するファイル（.cs、.ts、.html、.scss、.css、テスト、スクリプト、ビルド／コードとしての設定）が含まれる場合は、この基準を適用してください。純粋にドキュメントのみの変更では、実行可能な例やコードスニペットを除き、この基準を適用する必要はありません。

成功の尺度：将来の変更コスト。 DRY、SRP、抽象化、デザインパターン、命名、レイヤリング、テストは、すべて一つの目標に役立ちます。次の変更をより低コストにすることです。

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

変更コストを上げる「ベストプラクティス」は退けてください。早すぎる抽象化、推測に基づく汎用化、漏れのある間接化、見返りのない形式主義が該当します。
指摘では、実際の問題を明示してください。結合、隠れた状態、重複した知識、意図の不明確さ、時期尚早に公開された取り消し不能な決定。
外部ライブラリの変更を局所化できる場合は、コンポーネント／サービスの入出力契約など、プロジェクトが所有する境界を優先してください。変更コストを下げず、形式主義を増やすだけのパススルーラッパーは退けてください。
変更しやすいシンプルな設計は、そうではない洗練された設計に勝ります。

以下の具体的なルール、パターン、チェックリストよりも先にこの観点を適用してください。後続のルールが変更コストを上げる場合は、この原則を優先してください。

基本原則（すべて徹底）

YAGNI — 仮定上の将来の問題を解決するコード（未使用のパラメーター、推測に基づくインターフェース、時期尚早な抽象化）を指摘してください
KISS — 不必要に複雑な解決策を指摘してください。「同じ要件を満たす、もっとシンプルな方法はないか？」
DRY — 新しいコードを受け入れる前に、類似コードや重複コードがないか積極的に grep してください。類似パターンが3つ以上ある場合は、抽出を提案してください。
クリーンコード — 洗練より読みやすさを優先してください。名前で意図が伝わるようにします。関数は一つのことを行います。深いネストは避けます。
慣例に従う — パターン違反を指摘する前に、既存の例を3つ以上 grep してください。教科書的なルールより、コードベースの慣例を優先します。
欠陥・バグなし — ロジックの経路をたどってください。エッジケース（null、空、境界値）を検証してください。エラーハンドリングが失敗ケースを網羅しているか確認してください。
根拠が必須 — すべての主張に file:line の根拠または grep の結果が必要です。推測は禁止です。
ドキュメントの陳腐化 — 変更したファイルを関連ドキュメント（機能ドキュメント、テスト仕様、README）と照合してください。古い記述や更新漏れがあれば指摘してください。

変更したファイルについて python .claude/scripts/code_graph batch-query <f1> <f2> --json を実行し、テストカバレッジと呼び出し元への影響を確認してください。

影響範囲の事前分析（最初に必ず実施）

**重要・必須・必ず注意：**あらゆるレビューで最初に行う作業です。ほかのレビュー作業に着手する前に、$graph-blast-radius を実行してください。

.code-graph/graph.db が存在する場合は、変更をレビューする前に graph-blast-radius 分析を実行してください。

$graph-blast-radius スキルを呼び出してください（python .claude/scripts/code_graph blast-radius --json を実行します）
レビューには、影響を受けるファイル数、テストされていない変更、影響範囲の大きさに基づくリスクレベルを含めてください
結果を使ってレビューするファイルの順番を決め、影響が最も大きいファイルから確認してください

グラフを活用した変更レビュー

変更したファイルごとに、影響全体をたどってください。

python .claude/scripts/code_graph trace <changed-file> --direction downstream --json — 変更の影響を受けるすべてのファイル
影響を受けるファイルのうち、テストでカバーされていないものを指摘してください
単純な差分レビューでは見落とす、サービスをまたぐ影響を検出します

レビューアプローチ（レポート主導の複数フェーズ — 重要）

最初に必ず実施：レビューの各フェーズのタスクを作成する 開始する前に、タスク追跡を呼び出して、次のタスクを登録してください。

各フェーズの完了に応じて、タスクのステータスを更新してください。

注：フェーズ 1 で変更ファイルが 10 個以上あることが判明した場合は、フェーズ 2〜4 のタスクを次の体系的レビュー手順のタスクに置き換えてください。 [Review Phase 2] Categorize and fire parallel sub-agents、[Review Phase 3] Synchronize and cross-reference、[Review Phase 3.5] Run $code-simplifier on changed code files、[Review Phase 3.7] Run $integration-test-review coverage gate、[Review Phase 4] Generate consolidated report

フェーズ 0：グラフの影響範囲分析を実行する（最初に必ず実施）

重要：最優先で必ず実施してください。レビュー作業で最初に行う操作です。

$graph-blast-radius スキルを呼び出す
レポートに、変更ファイル数、影響を受けるファイル数、テストされていない変更、リスクレベルを記録する
フェーズ 2 で特に注意してレビューするファイルの優先順位付けに、影響範囲分析の出力を使用する
.code-graph/graph.db が存在しない場合は、「グラフを利用できません — 影響範囲分析をスキップ」と記載し、フェーズ 0.3 に進む

フェーズ 0.3：変更タイプの検出とリスクタスクの作成（必須）

目的： 次元別レビューの前に、この差分に含まれる高リスクな変更タイプを特定します。検出した変更タイプごとに、対象を絞ったリスクタスクを作成します。変更タイプとファイル分類は互いに独立しています。同じファイルが移行とセキュリティ変更の両方に該当する場合もあります。すべて個別に検出してください。

ステップ 1：変更タイプを検出する

git diff --name-only HEAD       # unstaged
git diff --cached --name-only   # staged
# For branch or commit-range review, use the user-provided diff source:
git diff --name-only <base>...<head>

この差分について、それぞれの変更タイプを評価してください：

変更タイプ	検出シグナル（プロジェクトの実際の規約に合わせて調整）	次の場合は TRUE
DepUpgrade	依存関係マニフェストが変更された（`package.json`、`*.csproj`、`Gemfile`、`go.mod`、`requirements.txt`、`Cargo.toml`、`pom.xml` など）	いずれかの依存関係マニフェストでバージョン番号が変更された
Migration	ファイルパスまたは名前からスキーマ変更が示唆される（`migration`、`schema`、`alter_table` を含む、またはプロジェクトのマイグレーション規約に一致する）	マイグレーション規約に該当するファイルが差分に含まれている
BusEvent	新規または変更されたイベント／メッセージ定義、またはコンシューマー（コンシューマーの命名規則やメッセージ型のディレクトリなど、プロジェクトの規約から推測）	コンシューマーまたはイベントクラスが新規作成された、またはその契約が変更された
ApiContract	API 定義ファイル（コントローラー、ルートハンドラー、OpenAPI／GraphQL スキーマ）が変更され、ルートまたはフィールドに差異がある	差分にルート／アクション／フィールドの追加または削除が示されている
SecurityChange	認証／権限の定義が変更された（認証ミドルウェア、権限定数、ポリシー定義など、プロジェクトの規約から推測）	認証または権限のゲートが追加、削除、または変更された
ConfigChange	設定ファイルが変更された（例：`.json`、`.yaml`、`.env`、`Config`、`Options`、`Settings`、`*.toml`）	設定規約に該当するファイルが含まれている
InfraChange	インフラ定義が変更された（`Dockerfile`、`docker-compose*.yml`、CI/CD パイプライン、k8s マニフェスト、IaC ファイル）	インフラ規約に該当するファイルが含まれている

レポートに記録します：

## Change Type Analysis
DepUpgrade: [YES/NO] | Migration: [YES/NO] | BusEvent: [YES/NO]
ApiContract: [YES/NO] | SecurityChange: [YES/NO] | ConfigChange: [YES/NO] | InfraChange: [YES/NO]

ステップ 2：変更タイプ別のリスクタスクを作成する（レビュー作業の前に必ず実施）

必須： TRUE シグナルごとにタスク追跡を呼び出してください。FALSE シグナルに対するタスクは作成しないでください。記載されている懸念事項は出発点です。ドメイン知識も活用してください。 | 条件 | タスク追跡の件名 | 調査すべき主な懸念事項（出発点 — ドメイン知識に基づいて掘り下げてください） | | ------------------- | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DepUpgrade TRUE | [Review-DepUpgrade] Dependency upgrade — semver, breaking changes, security advisories | メジャー／マイナー／パッチのどれですか？上流の CHANGELOG を読み、API の破壊的変更を確認してください。非推奨 API の使用箇所を grep で検索してください。推移的依存関係の変更を確認してください。新しいバージョンに関する既知のセキュリティ勧告はありますか？ピア依存関係との互換性はありますか？テストは引き続き成功しますか？ | | Migration TRUE | [Review-Migration] DB migration — rollback path, volume impact, zero-downtime | ロールバック／Down スクリプトはありますか？テーブルサイズを見積もってください。大きなテーブルではロックの分析が必要です。空でないテーブルに対し、デフォルト値のない NOT NULL 列を追加していませんか？ロックなしオプションを指定してインデックスを作成していますか？デプロイ順序（サービスのデプロイ前／後）は適切ですか？バックフィルを2回実行しても冪等ですか？ | | BusEvent TRUE | [Review-BusEvent] Cross-service event/message — consumer, idempotency, retry, poison pill | 新しいイベントのコンシューマーは存在しますか？再試行戦略は適切ですか。前提となるデータが同期されていない場合、待機して再試行しますか、それとも黙ってスキップしますか？ハンドラーは2回実行しても安全ですか（冪等性）？不正なメッセージへの対処やデッドレターの設定はありますか？ブローカーの保証と順序に関する前提は一致していますか？ | | ApiContract TRUE | [Review-ApiContract] API contract change — backward compat, client alignment, auth | 追加的変更ですか、それとも破壊的変更ですか？破壊的変更の場合、バージョニングまたは連携デプロイが必要です。すべての呼び出し元（UI、他のサービス、テスト）は引き続き互換性がありますか？新しいエンドポイントは適切に保護されていますか？クライアントを更新せずに必須のレスポンスフィールドを追加していませんか？ | | SecurityChange TRUE | [Review-SecurityChange] Security/permission change — all paths covered, no privilege escalation | ゲートに到達するすべてのコードパスを網羅していますか？未認証アクセスが拒否されることを検証する否定テストはありますか？権限昇格の可能性はありますか？強制適用と表示制御の両方が更新されていますか？権限の定義は単一の信頼できる場所にありますか（重複した文字列による不整合のリスクはありませんか）？ | | ConfigChange TRUE | [Review-ConfigChange] Config/env change — all environments, no secrets committed | 新しい設定キーはすべての環境設定に存在しますか？ハードコードされたデフォルト値が、本番環境の設定不足を隠していませんか？差分に秘密情報が含まれていますか？含まれている場合は → 重大です。セットアップガイドに記載されていますか？設定が欠けている場合、アプリケーションはすぐに失敗しますか？ | | InfraChange TRUE | [Review-InfraChange] Infrastructure change — env parity, no dev values in prod, reproducible build | 変更はすべての環境に一貫して影響しますか？ハードコードされた開発用の値（localhost、デバッグフラグ、開発用認証情報）はありませんか？イメージ／依存関係のバージョンは固定されていますか？ローカル開発への影響は文書化されていますか？CI/CD に必要なシークレット／権限は文書化されていますか？ |

AI-SDD のリスク観点： 変更されたファイルが仕様、ワークフロー、ツール、または共有ガイダンスに関わる場合は、これらの観点を適用してください。

観点	レビューの焦点
Contract/API/routes	パブリックな動作、クライアント、生成された仕様、回帰テストの整合性が維持されています。
Permissions/security-review	適用、表示制御、否定テスト、権威ある権限定義の整合性が保たれています。
Config/flags	すべての環境、サンプル、フェイルファスト動作、ドキュメントが最新です。
Docs/spec/test drift	正式な仕様、Section 8 TCs、ダッシュボード、テストコードが同期されているか、明示的に N/A とされています。
Generated mirrors	共有スキル／ワークフロー／ツールの変更が、生成されたエージェント向けの各領域に同期されています。
Reference-only artifacts	AI が抽出した仕様／TC は、担当レビューゲートで承認されるまでドラフト／参考資料として扱われます。

ステップ 3：観点別レビューに進む前に、変更タイプのタスクに取り組む

作成した変更タイプのタスクごとに、以下を行います。

タスクを in_progress に設定します
該当する懸念事項をすべて確認します。上の表は出発点であり、網羅的な上限ではありません
各懸念事項について、PASS の場合は file:line を示し、FAIL／WARN の場合は指摘内容を説明します
レポートの ## {Task Subject} Findings の下に指摘内容を記載します
タスクを completed に設定します

重要： まず変更タイプのタスクをすべて完了してから、Phase 0.7 に進んでください。変更タイプを示すシグナルが見つからない場合は、"高リスクの変更タイプは検出されませんでした" と記録して続行します。

Phase 0.7：変更範囲の検出と動的レビュータスク（必須）

目的： AI が変更の性質を分類し、それに応じたレビュータスクを作成できるようにします。カテゴリは、プロジェクトで実際に変更されたファイルから導き出し、固定の分類を前提としないでください。 定型の分類表に当てはめるのではなく、考えてください。 この手順はすべて AI が担当します。

ステップ 1：差分からカテゴリを導き出す

git diff --name-only HEAD        # unstaged
git diff --cached --name-only    # staged
# For branch or commit-range review, use the user-provided diff source:
git diff --name-only <base>...<head>

変更された各ファイルについて、次の点を調べてカテゴリを推定します。

言語／拡張子： このファイルはどの技術または分野に属していますか？
ディレクトリの意味： このパスは、プロジェクトのどのレイヤー、モジュール、懸念事項を表していますか？
変更の性質： ロジック、データスキーマ、設定、ドキュメント、インフラ、スタイル、テスト、ツールのいずれですか？

固定の分類には割り当てないでください。 現在のリポジトリの実際の構造と用語に合ったカテゴリを導き出してください。

検討の出発点となる一般的なカテゴリタイプ（網羅的ではありません。適切なカテゴリを導き出してください）：

サーバーサイドロジック — ビジネスルール、API ハンドラー、サービス、コンシューマー、イベントプロセッサー
クライアントサイドロジック — UI コンポーネント、状態管理、API 統合
データ／スキーマ — マイグレーション、スキーマ、シードデータ、ドメインモデル
スタイル／アセット — CSS／SCSS、デザイントークン、画像、フォント
設定 — アプリ設定、環境変数、機能フラグ
インフラ — Docker、CI/CD、パイプライン、クラウドマニフェスト
ドキュメント／仕様 — Markdown ドキュメント、ADR、機能仕様、テスト仕様
テスト — ユニット、統合、E2E のテストファイル
ビルド／ツール — ビルドスクリプト、リンター、フォーマッター、バンドラー、エージェントスクリプト
セキュリティ — 認証設定、権限定義、証明書

レポートに記録します。

## Change Surface
{Category name} ({category type}): {N} files
{Category name} ({category type}): {M} files
...

ステップ 2：カテゴリごとに懸念事項を列挙し、タスクを作成する

ここでは空欄を埋めるのではなく、考えてください。 各カテゴリについて SYNC:category-review-thinking を適用します。

特定した各カテゴリについて、以下を行います。

分野を理解する： このカテゴリの目的は何ですか？どのような不変条件が適用されますか？誰が依存していますか？
プロジェクトの規約を確認する： スタイルガイド、この領域固有のパターンドキュメント、README を検索します
第一原理から懸念事項を導き出す — 固定のリストに制限せず、分野に関する知識を活用します
導き出した懸念事項を列挙した [Review-{Category}] {brief concern summary} という名前のタスク追跡タスクを作成します
適切なサブエージェントタイプを選択します（「サブエージェントタイプの選択」を参照）

必ず作成： [Review-General] — 正確性、YAGNI／KISS／DRY、ドキュメントの古さ、テストカバレッジに関する全般的な品質チェックです。他のカテゴリに関係なく、変更されたすべてのファイルを対象に実行します。

サブエージェントの種類の選択：

カテゴリの性質	`agent_type`
コードロジック（あらゆるスタック）	`code-reviewer`
文書化された仕様／PBIを実装	`spec-compliance-reviewer`（事前チェック。`code-reviewer`より先に実施）
セキュリティ、認証、権限	`security-auditor`
パフォーマンス、クエリ効率、レイテンシー	`performance-optimizer`
ドキュメント、計画、仕様、ADR	`general-purpose`
インフラストラクチャ、CI/CD、設定	`general-purpose`
複合またはデフォルト	`code-reviewer`

仕様準拠の事前チェック（変更セットが文書化された docs/specs/** の機能、またはPBI／ストーリーを実装する場合）： spec-compliance-reviewerを最初に起動します。仕様に対する実装の一致を検証し（仕様とのずれ、要件の欠落、余分な機能を検出）、code-reviewerによる品質チェックの前に実施します。変更を管理する仕様／PBIがない場合は省略します（その場合、コードチェックはcode-reviewerのみです）。これがspec-compliance-reviewerの唯一の配備箇所です（sub-agent-selection-guide.mdの「Spec compliance」行）。

UI／フロントエンドの観点（このスキルの担当）： _クライアント側ロジック_または_スタイル／アセット_のカテゴリに、プロジェクトで設定されたフロントエンド／UIファイルのパターンに一致するファイルが含まれる場合、$review-changesがUIレビューを担当し、UIの観点として$review-uiを実行します。できれば、他の観点のエージェントと同じ並列バッチで専用のui-ux-designerサブエージェントを起動してください（サブエージェントを起動できない場合に限り、チェックリストをインラインで取り込みます）。チェックリスト：長いコンテンツのはみ出し（折り返しと省略記号＋ツールチップ）、flexを使用した複数画面サイズへの対応、flex-growと固定サイズ（固定pxではなく、min／maxとflexを優先）、z-indexのスケールの厳守（生の数値や!importantを使わない）、SCSS／BEMの品質。この動作は単独実行時とワークフロー内の両方で同じです。$review-uiは別個のワークフローステップではなく、常にここで実行します。フロントエンドファイルに変更がない場合は、すべて省略します。

ステップ3：タスクを順に進める

作成した各タスクについて：

開始前に、タスクをin_progressに設定します
そのカテゴリの対象範囲に含まれるファイルのみをレビューします
SYNC:category-review-thinkingを適用します。そこに示された例に限らず、自身のドメイン知識も活用してください
## {Task Subject} Findingsセクションに、レポートの指摘事項を記載します
次のタスクを開始する前に、タスクをcompletedに設定します

スキャンだけで観点タスクを完了にしてはいけません。 関連するファイルを一つずつ明示的に確認してください。ファイル数が多いカテゴリ（10件以上）の場合は、Systematic Review Protocolに従って並列サブエージェントにエスカレーションします。

フェーズ0.5：計画への準拠チェック（条件付き — 有効な計画がある場合のみ）

注入されたコンテキストの## Plan Contextを確認します。

「Plan: none」の場合 → 省略し、「有効な計画がないため、計画への準拠チェックを省略」と記録します
「Plan: {path}」の場合 → 計画を読み込み、次を確認します：

{plan-path}/plan.md を読み、フェーズ一覧とスコープを確認します
関連するフェーズファイルを読み、変更対象ファイル、テスト仕様、成功基準を抽出します
確認します（必ず注意すること — 以下の4項目すべて）：
- スコープの一致 — 変更されたファイルが計画の各フェーズに記載されていること（計画にないファイルがあれば警告します）
- テストの証拠 — 完了したフェーズに対応するテストに証拠（ファイル名:行番号）があり、「TBD」ではないこと
- 成功基準の達成 — 変更によってフェーズの成功基準が満たされていること
- テスト意図の追跡可能性 — 対応するテストが、現在の動作だけでなく、保護するビジネスルール／不変条件を明示していること
レビューレポートに「Plan Compliance」セクションを追加します

フェーズ 1：変更の取得とレポートファイルの作成（必ず注意すること）

差分の取得元を特定します：現在の作業ツリー、ステージされた変更、ブランチ比較、またはコミット範囲
現在の変更を確認するには git status を実行し、ブランチを比較するには git diff --name-only <base>...<head> を実行します
実際の変更を確認するには git diff または git diff <base>...<head> を実行します
plans/reports/code-review-{date}-{slug}.md を作成します
Scope、Files to Review、Blast Radius Summary の各セクションを含めて初期化します

フェーズ 2：ファイルごとのレビュー（レポートを段階的に作成）

変更されたファイルごとに、以下を確認して直ちにレポートを更新します。

ファイルパスと変更種別（追加／変更／削除）
Change Summary：変更または追加された内容
Purpose：変更の目的
規約の確認： 類似パターンを3つ以上 grep で検索し、新しいコードが既存の規約に沿っているか確認します
正確性の確認： ロジックの経路を追跡し、null、空の値、境界値、エラーケースを処理しているか確認します
DRY の確認： 類似コード／重複コードを grep で検索し、このロジックがほかの場所にすでに存在していないか確認します
意図の確認： 変更が明示された目的に沿っているか確認します。無関係な変更があれば指摘します
ロジックの追跡： 正常系の経路を1つ、エラー系の経路を1つ追跡します。ロジックが要件に合っているか確認します
意味的な正しさ： 成果物が本来の目的を果たしているか確認します
Issues Found：命名、型、責務、パターン、バグ、過剰な設計、ロジックエラー
次のファイルに進み、同様に繰り返します

フェーズ 3：フレッシュコンテキストゲート（条件付きプロトコル — 指摘事項とフェーズ 0.7 の対象範囲に基づいて分岐）

プロトコル： SYNC:double-round-trip-review + SYNC:fresh-context-review + SYNC:review-protocol-injection（すべて上記にインライン化されています）。 不変条件： フェーズ 3 はレビューのみです。指摘事項の追加はできますが、修正や検証は行ってはなりません。既存の指摘事項について、フレッシュコンテキストで再レビューする必要はありません。指摘事項が1件でもある場合は、フェーズ 6 の why-review 検証に進み、その後フェーズ 7 の自動修正と、フェーズ 0 からの $review-changes 全体の再実行に進みます。フェーズ 7 による再実行だけでは、フェーズ 3 の実行条件を満たしません。

開始ゲート：

フェーズ 2 または各観点のレビューですでに指摘事項が見つかっている場合は、フェーズ 3 をスキップします。次のように記録します：指摘事項がすでに存在するため、フレッシュコンテキストでのレビューをスキップしました。次に必須となるゲートは、フェーズ 6 の why-review 検証です。 その後、フェーズ 4 の統合とフェーズ 6 の検証に進みます。
指摘事項がなく、独立レビューを明示的に行う条件もない場合は、フェーズ 3 をスキップします。次のように記録します：現在のレビューに問題がなく、第2ラウンドの実行条件もないため、フレッシュコンテキストでのレビューをスキップしました。 その後、フェーズ 4 の最終処理に進みます。
現在の指摘事項がゼロで、かつ次の条件が少なくとも1つある場合に限り、フェーズ 3 を実行します。
- ユーザーが第2ラウンドのレビュー／フレッシュコンテキストでのレビューを明示的に依頼している
- 選択されたワークフローで、今回の実行に独立したレビュアーが明示的に必要とされている
- 高リスクの複数ドメインにまたがる変更について、問題なしと判断する前に総合的な検討が必要である

無駄を避けるルール： フェーズ 6 より前に、既知の指摘事項を再レビューする目的でフェーズ 3 を実行しないでください。フェーズ 7 で修正後にレビューを再実行したという理由だけで、フェーズ 3 を実行しないでください。再実行されたレビューは、すでに必須の全体レビューです。指摘事項がなく、上記の明示的な条件もなければ、問題なしとして完了します。

開始ゲートを通過してフェーズ 3 を実行する場合は、フェーズ 0.7 のカテゴリを確認します。異なるドメインが複数変更されている場合（例：サーバー側とクライアント側）は、統合モードを実行します。それ以外の場合は、包括モードを実行します。

［統合モード — 異なるドメインが複数変更されている場合］ Round 2 として統合エージェントを起動します。目的は、個々の領域別タスクでは把握できない、境界をまたぐ問題を検出することです。

Agent 呼び出しプロンプトを作成するとき：

SYNC:review-protocol-injection テンプレートから Agent 呼び出しの形式を逐語的にコピーし、agent_type: "code-reviewer" とします
11 個すべてのユニバーサル SYNC ブロックを逐語的に埋め込みます

Task を次のように設定します：

統合レビュー — この差分で変更された領域にまたがる懸念のみを対象とします。
コンテキストとして、次の領域別の指摘があります：{各領域別タスクの要約}。
自分自身のツール呼び出しを使って、変更されたファイルをすべて最初から読み直してください。

境界をまたぐ懸念のみを対象とします。各領域の内部を再レビューしないでください：
1. コントラクトの整合性：呼び出し元は、呼び出し先が公開する内容と一致していますか？（ルート、パラメーター、フィールド名、型）
2. データの一貫性：レイヤー間でフィールド名や型に一貫性がありますか？
3. セキュリティ境界：両側で認証が適用されていますか？（強制と表示制御）
4. レイヤー間の命名：同じ概念がレイヤーごとに異なる名前で呼ばれていませんか？
5. 配線漏れ：新しいプロデューサーにコンシューマーがありませんか？新しいコンシューマーにプロデューサーがありませんか？新機能のドキュメントがありませんか？
6. ドキュメント：両方の領域の変更が、ドキュメントに反映されていますか？

Target Files を "use the selected diff source from Phase 1" に設定します
レポートのパスを plans/reports/synthesis-review-{date}.md に設定します

サブエージェントの応答後：

統合レポートを読みます
指摘をメインレポートの ## Synthesis Round Findings として統合します。選別または上書きはしないでください
指摘がある場合： ここでは修正せず、Phase 3 を完了としてマークし、Phase 6 の why-review 検証に進みます
指摘がない場合： クリーンな統合パスとして Phase 4 の最終化に進みます

【全体レビューモード — 単一の領域が変更された場合】

境界をまたぐ統合レビューは不要です。標準の全体レビュー Round 2 を起動します。

Agent 呼び出しプロンプトを作成するとき：

SYNC:review-protocol-injection テンプレートから Agent 呼び出しの形式を逐語的にコピーします
領域の主要な懸念に基づいて agent_type を選択します（「サブエージェントタイプの選択」を参照）
Task を次のように設定します："選択した差分を全体的にレビューします。全体像に注目してください。技術的なアプローチの一貫性、アーキテクチャのレイヤー、ロジックの配置（最下位レイヤー）、DRY 違反、YAGNI/KISS、関数の複雑さを確認します。領域：{Phase 0.7 のカテゴリ} — このカテゴリに応じた領域知識を適用してください。"
Target Files を "use the selected diff source from Phase 1" に設定します
レポートのパスを plans/reports/code-review-changes-round{N}-{date}.md に設定します

サブエージェントの応答後：

サブエージェントのレポートを読みます
指摘をメインレポートの ## Round {N} Findings (Fresh Sub-Agent) として統合します。選別または上書きはしないでください
指摘がある場合： ここでは修正せず、Phase 3 を完了としてマークし、Phase 6 の why-review 検証に進みます
指摘がない場合： クリーンな全体レビューのパスとして Phase 4 の最終化に進みます
最終判定には、この実行で行われたすべてのレビューの指摘を反映する必要があります

以下のチェックはサブエージェントが実施しますが、Phase 4 で検証できます。

クリーンコードと過剰な設計のチェック：

MUST ATTENTION YAGNI： 将来の仮定上の問題を解決するコードになっていませんか？未使用のパラメーターや、先走ったインターフェースはありませんか？
MUST ATTENTION KISS： 解決策が不必要に複雑ではありませんか？同じ要件を満たしつつ、もっとシンプルにできませんか？
MUST ATTENTION 関数の複雑さ： メソッドが長すぎませんか？ネストが深すぎませんか？複数の責務を担っていませんか？
MUST ATTENTION 可読性： 新しいチームメンバーが、実装全体を読まなくても理解できますか？

ドキュメントの陳腐化チェック（必須）：

変更されたファイルごとに、関連するドキュメントを特定します：

機能ドキュメント、アーキテクチャリファレンス、モジュール／サービスのルートにある README、API ドキュメント、テスト仕様、セットアップガイドを検索します
変更された成果物と内容が一致しなくなったドキュメントがあれば指摘します
ドキュメント化すべき新機能や新コンポーネントについて、ドキュメントが不足していれば指摘します
レポートで指摘する際は、古くなった具体的なセクションと変更内容を明記します。まだ修正しないでください。Phase 7 で $docs-update を実行する、またはドキュメントを編集する前に、Phase 6 でその指摘を検証する必要があります。

仕様との乖離の判定（動作が変更された場合は必須）： SYNC:spec-drift-adjudication を適用します。動作に関わる変更ごとに、docs/specs/ にある正規の機能仕様と比較し、乖離があれば CODE-WRONG（変更が意図された仕様ルール／AC／不変条件に違反している → BLOCKING の指摘とし、コード／テストを修正）、SPEC-STALE（意図的な動作変更を仕様が反映していない → $spec [update] + $spec [mode=tests] [update] に回す）、AMBIGUOUS（どちらかを編集する前にユーザーへ直接質問する）、または SPEC-SILENT（コードでは正しく不変条件を適用しているものの、仕様の成果物に記載がない → $spec [update] + $spec [mode=tests] で §4 BR／§3 AC と §8 TC を追加し、さらにそれを保護するテストを追加する）に分類します。変更された動作ごとに判定を記録します（乖離がなければ Spec in sync）。コード／テストが通るという理由だけで乖離を解消扱いにしてはいけません。これは、バグ修正後の「仕様が間違っていたか？」という確認を双方向に一般化したもので、バグ修正後だけでなく、動作を変更するレビューすべてで実施します。指摘事項をここで報告し、Phase 6 で検証して、Phase 7 で修正します（CODE-WRONG の修正は修正ループに回し、SPEC-STALE と SPEC-SILENT の修正は $docs-update より前に正規の仕様更新担当に回します）。

正確性とバグ検出： SYNC:bug-detection を適用します — null 安全性、境界値、エラー処理、リソースのクリーンアップ、並行処理。

テスト仕様の検証： SYNC:test-spec-verification を適用します — 仕様を特定し、カバレッジを検証して、不足があれば指摘します。

統合テストの同期： SYNC:integration-test-sync-check を適用します — 不足しているテストを、ユーザーへの直接の質問を通じて明らかにします。

翻訳の同期： SYNC:translation-sync-check を適用します — 多言語対応の UI テキストを変更する場合、翻訳の更新、またはユーザーによる明示的なリスク受容を必須とします。

Phase 3.5：Code-Simplifier による品質最適化（コードファイルが変更された場合は必須）

目的： 正確性のレビューでは変更が正しく動作することを確認します。このゲートでは、変更されたコードが読みやすく、一貫性があり、変更しやすい状態に保たれることを確認します。バグ検出（Phases 2-3）と簡素化の最適化は、異なる観点からの確認です。どちらも実施してください。明瞭さ／一貫性／保守性の改善を担う正規の担当は $code-simplifier です。そのため、このスキルは同じ処理を重複させず、同機能に委ねます。

開始条件：

差分にソースコードまたはコードに関連するファイル（.cs、.ts、.tsx、.html、.scss、.css、テスト、スクリプト、コードとして扱うビルド／設定ファイル）が含まれる場合に実行します。
ドキュメントのみ／Markdown のみの差分ではスキップします。次のように記録します：Skipped Phase 3.5 — no code files in diff.

手順：

[Review Phase 3.5] タスクを in_progress に設定します。
$code-simplifier を実行し、変更されたコードファイルのみを対象にします（Phase 1 の差分ソース — 作業ツリー、ステージ済みファイル、ブランチ、またはコミット範囲 — を渡して、コードベース全体ではなく、関連する変更ファイルだけを改善するようにします）。再利用、DRY、KISS/YAGNI、命名、不要コード、抽象度／レイヤー配置、読みやすさについて簡素化の余地を洗い出すよう指示します。
提案を記録し、自動適用はしません。 レビューのコンテキストでは、$code-simplifier は レポート モードで実行します。提案をそれぞれ file:line の根拠と1行の理由とともに、メインレポートの ## Code-Simplifier Optimization Findings にまとめます。これらは指摘事項であり、編集ではありません。
[Review Phase 3.5] タスクを completed に設定します。 パイプラインへの統合： Phase 3.5 の指摘事項は通常の指摘事項です。Phase 4 で集約し、Phase 6 で検証します（$why-review --validate-findings は、誤検知や変更コストを高める簡略化を除外します）。検証済みの指摘事項のみを Phase 7 で修正します。Phase 6 で提案が検証される前に、$code-simplifier に作業ツリーを変更させてはいけません。

親ワークフローとの境界： このスキルが $workflow-review-changes 内のステップ 1 として呼び出された場合も、Phase 3.5 は実行してください（レポート用の指摘事項を生成するレビュー観点です）。ただし、ここでは修正しないでください。適用は、親ワークフローの $code-simplifier によるセルフレビューと $feature-implement による修正サイクルが担当します。指摘事項を記録し、レポートを親ワークフローのステップ 2 に渡してください。

Phase 3.7：統合テストレビューテストカバレッジゲート（動作に関わるコードが変更された場合は必須）

目的： Phase 2〜3 では変更内容が記述どおりに正しいことを確認します。このゲートでは、変更がテストでカバーされ、仕様化されていることを確認します。7 つのゲートからなるテスト品質監査の正式な担当は $integration-test-review です。Gate 7（変更カバレッジ）では、差分に含まれる動作変更のある本番コードの各ファイルを、対応するテスト（統合テストを優先し、単体テストへのフォールバックには明示的な根拠が必要）と仕様の TC に対応付けます。このスキルは同じロジックを重複させず、$integration-test-review に委譲します。SYNC:integration-test-sync-check は軽量なファイルのペアリングチェックとして引き続き使用します。このゲートではさらに踏み込み、変更セット全体にわたって、アサーションの品質、データ状態の検証、再現性、仕様↔テスト↔コードの双方向の整合性を確認します。

開始条件：

差分に、ハンドラー、コマンド、クエリ、サービス、エンティティ、イベントコンシューマー、コントローラー、バックグラウンドジョブ、フロントエンドロジックなど、動作に関わるソースコードが含まれる場合に実行します。
ドキュメントのみ／Markdown のみ／スタイル変更のアセットのみの差分ではスキップします。次のように記録します：Skipped Phase 3.7 — no behavior-bearing code in diff.

手順：

[Review Phase 3.7] タスクを in_progress に設定します。
Phase 1 の差分ソース（作業ツリー、ステージ済み、ブランチ、またはコミット範囲）を対象に $integration-test-review を呼び出し、変更セット全体を監査させます。変更された本番コードとテストファイルの両方を対象とし、テストファイルだけに限定してはいけません。7 つの品質ゲートをすべて実行し、Gate 7 のカバレッジ対応表を作成して、仕様の TC を双方向に照合します。
結果を取り込み、修正は自動で行わないでください。 出力をメインレポートの ## Integration-Test-Review Findings の下に統合します。各ゲートの判定、カバレッジ対応表、すべての GAP／SPEC-GAP／正当な理由のない COVERED-UNIT を指摘事項として含めます（GAP の最低重大度は HIGH、認証／金銭／データ整合性に関わる経路では CRITICAL）。
[Review Phase 3.7] タスクを completed に設定します。

パイプラインへの統合： Phase 3.7 の指摘事項は通常の指摘事項です。Phase 4 で集約し、Phase 6 で検証して、Phase 7 で修正します。GAP の修正では $integration-test を使用して不足しているテストを作成します。SPEC-GAP の修正では $spec [mode=tests] [update] を実行します。その後、Phase 7 の再開時に、新しいテストを含む更新済みの差分全体を対象として、カバレッジを再監査します。

親ワークフローとの境界： このスキルが $workflow-review-changes 内のステップ 1 として呼び出された場合、Phase 3.7 をローカルでは実行しないでください。7 つのゲートによる監査とカバレッジ対応付けは、親ワークフロー専用の $integration-test-review ステップが担当します。次のように記録します：Phase 3.7 deferred to parent workflow $integration-test-review step.（軽量なペアリングチェックである SYNC:integration-test-sync-check は、引き続きローカルで適用します。）

Phase 4：最終レビュー結果の生成

最終セクションをレポートに追加します（必ず対応すること — 以下のすべてのセクションを含めてください）。

全体評価（全体像の要約）
重大な問題（マージ前に必ず修正）
優先度の高い項目（修正を推奨）
アーキテクチャに関する推奨事項
ドキュメントの陳腐化（古くなったドキュメントと変更内容を列挙するか、「ドキュメントの更新は不要」と記載）
仕様との乖離に関する判定（動作が変わるファイルごとに、CODE-WRONG／SPEC-STALE／AMBIGUOUS／SPEC-SILENT／Spec in syncと、修正先を記載するか、「動作変更なし — 該当なし」と記載）
二重フィードバック台帳（必須 — 下記参照。動作変更がない場合は「動作変更なし — 該当なし」と記載）
良かった点
提案するコミットメッセージ（変更内容に基づく）

二重フィードバック台帳（動作に関するすべての指摘で必須）。 動作上のギャップが見つかった場合、仕様とテストの両方にフィードバックを反映する必要があります。コードを修正するだけでは不十分です。上記の仕様との乖離に関する判定行と、フェーズ3.7のゲート7のカバレッジ行は、それぞれ一方の軸しか対象としていません。この台帳で「両方を更新する」という要件をひとつにまとめ、どちらかが見落とされないようにします。動作に関する指摘ごとに、2つのセルを持つ行を1つ出力します。

指摘（file:line）仕様へのフィードバックテストへのフィードバック
{引用箇所} {§8の仕様／機能仕様に必要な更新 — 例：$spec [update]の後に$spec [mode=tests]、またはN/A（CODE-WRONG — 仕様はすでに正しい）} {必要なTC／回帰テスト — 例：$spec [mode=tests]による新しい§8の回帰TC、または$integration-testによる対象の統合テスト}

いずれか一方の軸のセルが空欄なら不合格です。 単独の「N/A」は認められません。N/Aには必ず理由を併記してください（例：N/A — CODE-WRONG：正規仕様にはすでに正しい動作が記載されているため、仕様の編集は不要です。回帰TCのみ必要です）。

CODE-WRONGの指摘 → 仕様へのフィードバックは通常、N/A — 仕様は正しいです。テストへのフィードバックは必須です（SYNC:spec-drift-adjudicationに従い、回帰TCを先に追加します）。

SPEC-STALEの指摘 → 両方のセルにN/A以外を記載します。仕様へのフィードバック＝$spec [update]の後に$spec [mode=tests]。テストへのフィードバック＝新規または更新するTCと、それを保護するテスト。

SPEC-SILENTの指摘（仕様に記載されていない不変条件をコードが正しく適用している）→ 両方のセルにN/A以外を記載します。仕様へのフィードバック＝不足している§4のBR／§3のAC（該当する場合は§5の不変条件も）と§8のTCを、$spec [update]および$spec [mode=tests]で追加。テストへのフィードバック＝新たに明記した不変条件を保護する新しいプロパティテスト／回帰テスト。不変条件をコードだけ、またはテストだけに残すことなく、見つかった不変条件を確実に記録することが最も重要です。

カバレッジ対象だが古くなったTC（$integration-test-reviewによってゲート7でSPEC-GAPと判定されたもの。ゲート7では、存在するものの現在の動作を説明しなくなったTCは、カバレッジを満たす行ではなくSPEC-GAPに分類されます）：仕様へのフィードバック＝$spec [mode=tests] [update]で古くなった§8のTCを修正。テストへのフィードバック＝修正後のTCに合わせて保護テストを更新。

この台帳は通常の指摘項目一式として扱います。フェーズ4でここに集約し、フェーズ6で検証します（$why-review --validate-findingsにより、動作変更ごとに両方の軸が含まれていることを確認します）。必要な仕様／テストの対応はフェーズ7で実施します。フェーズ7までに軸が空欄のままの台帳行がある場合、レビューは未完了です。

フェーズ 5：ドキュメント更新のトリアージ（条件付き）

フェーズ 4 のドキュメント陳腐化チェックで古くなったドキュメントが特定された場合：

影響を受けるドキュメントと、提案する同期／更新方法をレビュー報告書に記録します
古くなったドキュメントの各項目を、フェーズ 6 の検出事項検証ペイロードに追加します
まだ $docs-update は呼び出さないでください。古くなったドキュメントに関する検出事項は、$why-review --validate-findings がそれらについて CLEAN を返した後に限り、フェーズ 7 で修正します
フェーズ 7 で後からドキュメントを修正した場合、次の再帰的な $review-changes の呼び出しでは、フェーズ 0 から更新済みドキュメントを再レビューする必要があります

フェーズ 5 では、レビューで FLAGGED とされたドキュメントのみをトリアージします。 ここで何かが FLAGGED とされたかどうかにかかわらず、必須のフェーズ 8 の最終 $docs-update ゲートは、レビューが収束して CLEAN になった時点で実行されます。このゲートでは、トリアージで見落とした可能性のある影響ドキュメントを独立して検出します。フェーズ 5 は条件付きですが、フェーズ 8 は無条件です。

可読性チェックリスト（必ず注意して評価）

承認する前に、成果物が読みやすく、保守しやすく、理解しやすいことを確認します。

スキーマの可視性 — 関数がデータ構造を計算しますか？読者がコードを追わずに済むよう、コメントに出力の形式が示されていますか？
自明でないデータフロー — データが複数の手順を経て変換されますか？パイプラインを説明する簡潔なコメントがありますか？
自己文書化されたシグネチャ — パラメーターから役割が分かりますか？未使用のパラメーターにフラグを立てます
マジック値 — 説明のない数値／文字列は、名前付き定数にするか、インラインで根拠を示します
命名の明確さ — 実装を読まなくても、変数や関数から意図が分かりますか？

レビューチェックリスト

1. アーキテクチャへの準拠（必ず注意）

プロジェクトのレイヤー／モジュール境界に従っています（docs/project-config.json または同等のものを確認）
境界が定義されている箇所で、モジュール／サービスをまたいだデータへの直接アクセスがありません
ロジックが最も適切な下位レイヤーに配置されています（オーケストレーター／上位レイヤーのクラスに置かれていません）

2. コード品質とクリーンコード（必ず注意）

単一責任の原則 — 各関数／クラスは 1 つのことだけを行います
コードの重複がありません（DRY）— 類似コードを grep で検索し、3 回以上出現する場合は抽出します
プロジェクトのパターンに沿った適切なエラー処理が行われています
マジックナンバー／文字列がありません（名前付き定数に抽出します）
すべての関数に型注釈があります（言語で必要な場合）
早期リターン／ガード節が使用されています
YAGNI — 憶測に基づく機能、未使用のパラメーター、時期尚早な抽象化がありません
KISS — 要件を満たす最もシンプルな解決策です
既存のコードベースの規約に従っています（3 件以上の例を grep で確認します）

2.5. 命名規約（必ず注意）

名前から意図が分かります（HOW ではなく WHAT）
汎用的ではなく具体的な名前を使用します（data ではなく orderRecords）
ブール値には状態を示す動詞を接頭辞として付けます（isActive、hasPermission、canEdit）
暗号的な略語を使用しません

3. プロジェクト固有のパターン（必ず注意）

違反を指摘する前に、プロジェクトのパターン／規約に関するリファレンスドキュメントを読みます
パターン違反と結論づける前に、既存の例を 3 件以上確認します
プロジェクトのパターンからの逸脱を指摘する場合は、既存パターンを示す証拠（file:line）を提示します

4. セキュリティ（必ず注意）

認証情報、トークン、シークレットがハードコードされていません
すべてのエントリーポイントで適切な認可チェックが行われています
システム境界（ユーザー入力、外部 API、メッセージペイロード）で入力検証が行われています
インジェクションのリスク（SQL、コマンド、テンプレートなど）がありません

5. パフォーマンス（必ず注意）

O(n) または O(1) で可能な処理に O(n²) の計算量を使用していません（ルックアップ構造を使用します）
N+1 クエリパターンがありません（反復処理の前に関連データをまとめて読み込みます）
すべてのリストクエリにページネーションがあります（上限のない結果セットを取得しません）
独立して実行できる操作は並列化されています（無理に逐次実行していません）
async／await が正しく使用されています（非同期コンテキストでブロッキングしていません）
クエリパターンに適切なインデックスがあります

6. よくある問題（必ず注意）

未使用のインポートや変数
本番環境に残すべきでないデバッグ／ログ出力
設定にすべき値のハードコード
async／await の不足、または Promise の処理漏れ
例外処理の誤り、または欠落
境界での検証漏れ

6.5 バグ修正のデバッガートレースゲート（要注意）

バグ修正、検証失敗、古い／誤った最終出力、リグレッション、または動作を変更する修正では、必須の証拠が不足している場合、レビューを不合格とします。

Debugger Trace: End -> Start に、観測された最終状態と、最終的なリーダー／クエリ／レンダラー／アサーションが記載されている
リーダー → ストレージ／プロジェクション／キャッシュ → 書き込み側 → コンシューマー／ハンドラー／ジョブ → プロデューサー／発生元の順に、逆方向の追跡が証拠で裏付けられている
最終状態を書き込む可能性のあるすべてのフィーダーパスが列挙されているか、明示的に不明とされている
仮説マトリクスで、根本原因が「主因」「寄与要因」「除外済み」「潜在的」「不明」に分類されている
症状が発生している箇所を既定で選ぶのではなく、最も下位にある共通の責任レイヤーとして、修正を担当するレイヤーが妥当化されている
前方向への収束の証明と、リグレッションテスト／証明の対応付けにより、最終的な症状が残存しない理由が示されている

7. ドキュメントの陳腐化（要注意）

変更したファイルごとに、関連するドキュメント（機能ドキュメント、アーキテクチャの参照資料、README）を特定する
ロジックを変更した場合 → 該当する機能／モジュールのドキュメントが引き続き正確であることを確認する
ツール類（スクリプト、設定、CI）を変更した場合 → セットアップ／スタートガイドのドキュメントが引き続き正確であることを確認する
新しい機能／コンポーネントを追加した場合 → 対応するドキュメントがない場合は指摘する
テスト仕様が変更後の現在の動作を反映していることを確認する
API の変更が該当する API ドキュメントまたは仕様に反映されていることを確認する
仕様との乖離の判定（SYNC:spec-drift-adjudication）：動作を変更するファイルごとに、正規の Feature Spec からの乖離が、CODE-WRONG（変更に欠陥がある — ブロッキング。コード／テストを修正）、SPEC-STALE（変更は意図されたもの — 先に $spec [update] で仕様を更新）、AMBIGUOUS（意図した動作が不明 — どちらかを編集する前にユーザーへ直接確認）、または SPEC-SILENT（仕様の成果物に記載されていない不変条件をコードが正しく強制している — §4 BR／§3 AC + §8 TC + ガードテストを追加して補完）のいずれに該当するかを判断する。どちらが正規の情報源かを明示せずに、乖離を一方向の「古いドキュメント」として指摘してはなりません。動作と仕様の乖離が未判定の場合は不合格です。文書化されていないものの強制されている不変条件を記録しない場合も、同様に不合格です。

8. M1-M6 準拠ゲート — コードと仕様の乖離（ブロッキング、必ず注意）

契約： .claude/skills/shared/sdd-artifact-contract.md → 「AI-SDD Mandates (M1-M6)」を参照してください。このレビューでは、この変更によって変更された、または同期されるべき仕様／機能ドキュメント／PBI／ストーリー／テスト仕様すべてに対して、M6 を適用します。各チェックは次の観点で行ってください。この変更によって、M1/M2 の文章への漏出が発生したか、論理 ID のマッピング（M3）が壊れたか、AC／期待結果に曖昧さ（M4）が生じたか。 FAIL の場合は、違反した義務 ID と、変更されたファイルおよび行を明記してください。M1-M5 の違反が導入されたのに合格とする場合、このレビュー自体に不備があります。

キャリアは M1/M2 の適用対象外です。ソース識別子は [Source: ...]、**Evidence**、**IntegrationTest** フィールド、YAML フロントマター、```mermaid ``` ブロック内では正しいままにしてください。文章の漏出として指摘するのは、仕様／ドキュメントの説明文にあるものに限ります。禁止する説明文トークンの一覧：docs/project-reference/spec-principles.md §3.2。このゲートの対象は変更された成果物ファイル（docs/specs/**、差分内の PBI／ストーリー／テスト仕様ファイル）に限定してください。そのような成果物に変更がない場合は、1 行の注記を付けて SKIP としてください。

M1 — 説明文に新たな技術情報を漏出させない。 差分によって、フレームワーク／製品、言語固有の型、製品／デザインパターンのクラス名が、仕様／ドキュメントの説明文、見出し、AC テキストに追加された場合は FAIL です（禁止リストは spec-principles.md §3.2）。変更されたファイル、行、トークンを示してください。
M2 — 説明文に新たなソースコードを記載しない。 業務上の操作ではなく、名詞として使われるクラス／メソッド／ファイルパス／名前空間で要件を表現している場合は FAIL です。ソース識別子を記載できるのはエビデンス用キャリア内のみです。変更された行を示してください。
M3 — 論理 ID のマッピングを維持する。 要件／ルール／TC に論理 ID（FR-/BR-/OP-/TC-）を付けずに追加した場合、論理 ID を削除した場合、論理 ID を [Source:] エビデンスより下位に置いた場合、スタックをまたいで使用できる抽象アンカー（[Source: namespace/service/id]）ではなく物理コードの座標またはリポジトリルートからのパスを記載した場合、あるいは [Source:] の抽象アンカーエビデンスを削除した場合は FAIL です（エビデンスは必須であり、論理 ID に次ぐ位置に維持する必要があります。コードを移動しただけではアンカーは変更しません。物理座標はプロベナンスのサイドカーにのみ記載します）。
M4 — 新たな AC の曖昧さを生じさせない。 AC／期待結果が曖昧（「適切に処理する」「通常どおり処理する」「必要に応じて」など）である場合、適合すると主張しながら異なる 2 通りの方法で実装可能である場合、または観測可能な完了状態／明示されたエラー条件がない場合は FAIL です。
M5 — 仕様を再構築可能な状態に保つ。 新しいコードを読まなければ仕様／ドキュメントを理解できなくなる場合（コードベースについての知識がゼロのチームが、成果物だけをもとに別のスタックで再実装できなくなる場合）は FAIL です。ファイルと不足している詳細を示してください。

いずれかの項目が失敗した場合、判定は FAIL です。違反した義務 ID と変更ファイル／行の引用を、Critical Issues または High Priority セクションにそれぞれ列挙してください。

出力形式

次の形式でフィードバックを記載してください。

概要： 全体的な評価の要約

重大な問題：（コミット前に必ず修正）

問題 1：説明と推奨する修正

優先度高：（修正を推奨）

問題 1：説明

提案：（あると望ましい）

提案 1

ドキュメントの古さ：（更新が必要な可能性があるドキュメント）

ドキュメント 1：古くなっている内容とその理由
No doc updates needed — 変更されたファイルに対応するドキュメントがない場合

仕様との乖離の判定：（動作を変更する変更のみ — SYNC:spec-drift-adjudication に従う）

<behavior/file> → CODE-WRONG | SPEC-STALE | AMBIGUOUS | SPEC-SILENT — 判定と修正先（$spec [update]、回帰 TC、ユーザーへの直接質問、または enrich-spec：§4 BR／§3 AC ＋ §8 TC ＋ガードテストを追加）
Spec in sync — 変更された動作が正規の Feature Spec と一致する場合
No behavior change — N/A — 差分がドキュメント／ツール／スタイルのみの場合

デバッガートレースの不足：（バグ修正／動作変更のみ）

Trace complete — 必要なトレース、フィーダーパス、仮説マトリクス、担当者、フォワードプルーフが揃っている場合
不足 1：不足または不十分なトレースの証拠と、それによって PASS が妨げられる理由

目標達成度：（PASS 判定の前に必ず実施 — goal-contract-satisfaction-loop プロトコルに従って有効な Goal Contract を確認します。有効な計画は goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md です。存在しない場合は、No active goal — skipped: {one-line reason} と記録します）

成功基準	証拠	状態
{saved criterion}	{file:line, command output, report path}	PASS/FAIL/BLOCKED

必須の基準が 1 つでも FAIL の場合、総合 PASS は BLOCKED です。コード品質に問題がないレビューでも、保存された目標を達成できていなければ PASS にはなりません。
BLOCKED の場合、ユーザー向けのエスカレーション理由をマトリクスの行と目標ファイルに記録する必要があります。
証拠の参照先を示してください。目標の内容を言い換えたり、秘密情報や機密性の高いペイロードをマトリクスや目標ファイルにコピーしたりしないでください。
判定後、目標ファイルを更新してください。Iteration Log エントリーを追記し、Goal Satisfaction マトリクスを同期します。

良かった点：

適切に行われたこと

推奨するコミットメッセージ：

type(scope): description

- Detail 1
- Detail 2

システマティックレビューのプロトコル（変更ファイルが 10 個以上の場合）

フェーズ 1 で変更ファイルが 10 個以上見つかった場合は、以下に定義する システマティックレビューのバッチ処理 プロトコル（マップ・リデュース：サイズ上限付きバッチ処理＋階層的な統合）を適用します。

ワークフローに関する推奨事項

必須 — 例外なし： すでにワークフロー内にいない場合は、ユーザーに直接質問してください。タスクの複雑さを判断したり、「簡単だから省略してよい」と判断したりしないでください。判断するのはユーザーです。

workflow-review-changes ワークフローを有効化する（推奨）— .claude/workflows.json の正規ワークフローを実行します。このワークフローでは、このスキル、指摘事項の検証、並列レビュアー、code-simplifier によるセルフレビュー、修正計画のサイクル、完全な再レビューのやり直し、ドキュメント、引き継ぎを順に実施します。

$review-changes を直接実行する — このスキルを単独で実行します。

アーキテクチャ境界の確認

変更されたファイルごとに、禁止レイヤーからのインポートがないことを確認してください。

ルールを読む — docs/project-config.json の architectureRules.layerBoundaries を確認します。
レイヤーを特定する — 変更された各ファイルのパスを、各ルールの paths glob パターンと照合します。
インポートをスキャンする — ファイル内のインポート文を grep します。
違反を確認する — インポートパスに cannotImportFrom に列挙されたレイヤー名が含まれている場合は、違反です。
フレームワークを除外する — architectureRules.excludePatterns のいずれかのパターンに一致するファイルはスキップします。
違反があれば BLOCK — 重大な問題として次のように報告します。"BLOCKED: {layer} layer file {filePath} imports from {forbiddenLayer} layer ({importStatement})"

project-config.json に architectureRules がない場合は、何も出力せずにスキップします。

フェーズ 6：Why-Review の指摘事項の検証ゲート（指摘事項の修正前に必須）

目的： 修正を行う前に、自身の調査結果を検証します。すべての指摘が正しく、証拠（file:line）に裏付けられ、妥当で、規約に沿っていることを確認します。コードやドキュメントを編集する前に、誤検知、重大度の過大評価、見落とした改善点を把握します。

必須： 指摘がある場合は、必ず todo タスクを実行します。タスクトラッキングに [Review Phase 6] Why-review findings validation gate として登録してください（上記の Phase タスクリストにはすでに登録されています）。このゲートに合格するか、明示的にブロック状態になるまで、修正、ドキュメントの更新、コミット、引き継ぎを行わないでください。

トリガー： 指摘が1件でもある場合（Critical、High、Medium、Low のいずれも）。報告の判定が無条件の PASS で、指摘が文字どおりゼロの場合に限り、スキップできます。

無条件で呼び出すこと： 指摘が1件でもある場合、修正、ドキュメントの更新、コミット、引き継ぎの前に、スキル呼び出しを通じて $why-review スキルを必ず呼び出してください。インラインでの代替手段はありません。引用された file:line を手動で読み直すこと、頭の中で再確認すること、指摘を「すでに検証済み」と宣言することは、いずれも該当しません。このゲートに合格する唯一の方法は、実際に $why-review --validate-findings スキルを呼び出し、判定結果を得ることです。

親ワークフローとの境界： このスキルが $workflow-review-changes 内のステップ1として呼び出された場合、この Phase 6 をローカルで実行しないでください。レビュー報告を作成したら停止し、親ワークフローのステップ2に引き渡します。親ワークフローが、並列レビュアーの実行や修正の前に $why-review --validate-findings を実行します。

手順（再実行回数に上限のあるループ）：

plans/reports/{skill}-{date}-{slug}.md にある自身の最終版レポートを読みます
スキル呼び出しを通じて $why-review スキルを呼び出します（ターミナルの --validate-findings モード。同じメインエージェントのセッション内で実行し、サブエージェントを起動せず、再帰もしません）。「同じセッション」とは、why-review スキルがこの会話内で実行されることを意味します。スキルの呼び出しの代わりに、自分でインラインの再読を行ってはいけません。スキルを実際に実行する必要があります。次の引数を渡します：--validate-findings plans/reports/{skill}-{date}-{slug}.md — 各指摘について、(a) file:line の証拠が存在し、正確であること、(b) 指摘が正しいこと（引用されたコードをたどって再確認すること）、(c) 重大度が妥当で過大評価されていないこと、(d) プロジェクトのベストプラクティス／規約に沿っていることを検証します。却下された解釈については最も強い根拠を示し、レビューで見落とされた指摘や改善の機会があれば明らかにします
why-review が返した検証結果のパスを読みます。想定されるパスは plans/reports/why-review-validate-{date}.md です
why-review の判定を分類します：
- CLEAN — すべての指摘が正しく、証拠に裏付けられ、妥当で、ベストプラクティスに沿っていることが確認され、新たな指摘事項や改善の機会も見つからない場合 → 自身のレポートに ## Why-Review Validation の項目を追加し、「N 件すべての指摘を実際のコードに照らして再検証済み。変更なし。」と記録します。ゲートに合格です。N > 0 の場合は、直ちに Phase 7 に進みます。
- HAS ISSUES — why-review が指摘の重大度を下げる、または指摘を削除する場合、証拠の欠落や不正確さを指摘する場合、新たな指摘事項や改善の機会を明らかにする場合 → ステップ5に進みます。
調整： 自身の最終版レポートを更新します。重大度を見直し、誤検知を削除し、判明した指摘や改善点を追加して、変更内容とその理由を記載した ## Why-Review Validation Notes セクションを追加します。
更新したレポートに対して $why-review --validate-findings を再実行します（ステップ2に戻ります）。レポートを変更した場合に限り、再検証が必要です。各検証はターミナルで行われ（検証モードは再帰しません）、ループの管理と上限の適用はこの手順で行います。why-review の判定が CLEAN になるまで、または**再実行上限の2回（合計3回の検証）**に達するまで繰り返します。
上限に達しても CLEAN にならない場合： 未解決の項目を ## Why-Review Validation — Unresolved に記録し、ループを黙って続けるのではなく、ユーザーに直接質問して対応を求めます。

スキップ条件（スキップする場合は、明確な理由を記録してください）：

判定が無条件の PASS で、指摘が 0 件の場合 →「スキップ — 検証する指摘はありません」と記録し、Phase 7 は実行しないでください
$why-review 自体がアクティブなスキルコンテキストの場合 → 再帰させないでください。why-review は独自の末尾にある --validate-findings モードで再検証します（「Findings Validation Gate」を参照）

これが必要な理由： AI のレポートには、確証バイアス、誤検知、重大度の過大評価が引き継がれることがあります。検証によって編集前に指摘を確証し、レポート変更後に再検証することで、修正済みの指摘が再確認されないままになる問題を解消します。

Phase 7：再帰的な自動修正＋完全な再レビューのループ（検証済みの指摘が残っている場合は必須）

目的： 修正によってレビュー対象が変わります。次の確認では、古いレビュー状態から続行するのではなく、Phase 0 から $review-changes を完全に新規実行する必要があります。

実行条件： Phase 6 が CLEAN を返し、検証済みレポートに 1 件以上の指摘、弱点、古いドキュメント項目、テスト不足項目、または必須の改善項目が残っている場合。

親ワークフローの境界： このスキルが $workflow-review-changes 内のステップ 1 として呼び出された場合、ここから自動修正したり $review-changes を再実行したりしないでください。親ワークフローのステップ 10～15 で、$plan、$plan-review、$plan-validate、$why-review、$feature-implement、および完全な再スタートゲートを管理します。

プロトコル：

編集前に、この修正サイクル用の新しいタスクを作成します。検証済みの指摘ごとに 1 タスク、対象を絞った検証用に 1 タスク、$review-changes の再開用に 1 タスクを作成します。
検証済みの指摘を、それを所有するレイヤーで自動修正します。古いドキュメントについては、検証後に $docs-update を実行するか、正本となるドキュメントのみを編集します。テスト／仕様については、派生ダッシュボードより先に正本となる成果物を更新します。
修正対象を絞った検証を実行します。該当するものに応じて、テスト、lint、ドキュメント／仕様の同期、SDD、グラフ、または設定チェックを行います。
レビューレポートに ## Fix Cycle {N} を追記します。修正した指摘、変更したファイル、検証コマンドと結果、および理由付きの未解決項目を記録します。
同じメインエージェントのセッションで、完全な現在のレビュー対象に対して $review-changes を再実行します。
- 全 Phase 用の新しいタスクリストを作成します
- Phase 0 の影響範囲、Phase 0.3 のリスク検出、Phase 0.7 のサーフェス分類、Phase 1 の差分収集、および後続の Phase を再実行します
- 元の変更と Phase 7 の修正を含む、変更されたすべてのファイルを最初から読み直します
- 前回のレポートは過去のコンテキストとしてのみ扱い、以前の指摘を正しい情報として再利用しないでください
1 回の $review-changes 実行で無条件の PASS となり、指摘が 0 件で、Phase 6 が「検証する指摘はありません」としてスキップされるまで、Phase 0 → Phase 7 を繰り返します。

停止条件：

同じ検証済みの指摘が進展の兆候なく完全なレビューで 3 回繰り返された場合は、ループを止め、続行せずにユーザーへ判断を求めます。
プロダクトやオーナーの判断なしに安全に自動修正できない指摘がある場合は、ブロッカーを記録してユーザーに確認します。
必要な検証ツールまたはサブスキルが利用できない場合は、プロトコルを変更する前に停止して確認を求めます。

譲れないルール：

$why-review --validate-findings で現在の指摘セットが確認される前に、指摘を修正してはなりません。
修正後に $review-changes のプロトコル全体を Phase 0 から再実行せず、レビューをクリーンと判定してはなりません。
修正後に修正したファイルだけをレビューしてはなりません。修正が以前の変更と相互作用する可能性があるため、現在の差分全体をレビューしてください。
再開後に古い todo タスクを再利用してはなりません。再帰的なレビューの実行ごとに、すべての Phase をあらためて分解してください。
出力形式の Goal Satisfaction マトリックスですべての必須保存基準が PASS（またはユーザー向けのエスカレーション理由を伴う BLOCKED）と示されない限り、無条件の PASS を宣言してはなりません。必須基準の FAIL は、この修正ループで検証する指摘です。

フェーズ 8：必須の最終ドキュメント更新ゲート（必須 — レビューループが収束して問題がなくなった後に必ず実行）

目的： 変更によって古いドキュメントが残らないようにします。 フェーズ 5〜7 では、レビューで指摘された問題に該当するドキュメントのみを修正します。この最後のゲートでは、必ず $docs-update を実行し、影響を受けたドキュメントのうち、観点別レビューで見つからなかったものも実際の変更と整合させます。コードレビューで問題なしと判定されても、ドキュメントが最新であるとは限りません。

トリガー： レビューが収束した状態、つまり $review-changes を一通り実行して指摘事項がゼロとなり、検証済みの修正がすべて適用された状態です。このゲートはスタンドアロンモードでは必ず実行します。古さに関する指摘がある場合に限って実行するものではありません。

親ワークフローとの境界： このスキルが $workflow-review-changes 内のステップ 1 として呼び出された場合は、フェーズ 8 をローカルで実行しないでください。親ワークフロー独自の $docs-update ステップ（$feature-implement と再起動ゲートの後）が最終的なドキュメント同期を担当します。Phase 8 deferred to parent workflow $docs-update step. と記録してください。

プロトコル：

[Review Phase 8] タスクを in_progress に設定します。
変更セット全体（フェーズ 1 の差分ソースにフェーズ 7 の修正を加えたもの）を対象に $docs-update を呼び出します。変更内容から影響を受けるドキュメント（機能ドキュメント、アーキテクチャの参照資料、README、API ドキュメント、テスト仕様、セットアップ／はじめにのガイド）を検出させます。
フェーズ 4 の仕様ドリフト判定（SYNC:spec-drift-adjudication）で SPEC-STALE 判定があった場合（正規の機能仕様が意図された動作を反映していない場合。バグ修正後に仕様がバグを正しい動作として記載しているケースも含む）、まず $spec [update] を実行してから $docs-update を実行します。先に仕様を意図された動作に修正してください。$docs-update に、壊れた動作や置き換えられた動作を正式なものとして記録させてはいけません。CODE-WRONG 判定は仕様編集ではありません。フェーズ 7 のコード修正ループですでに修正済みです。SPEC-SILENT 判定、つまりコードですでに強制されているものの、どの仕様成果物にも記載されていない不変条件は、エンリッチメントです。$docs-update の前に $spec [update]（§4 BR／§3 AC を追加）と $spec [mode=tests]（§8 TC を追加）を実行し、保護するテストが存在することを確認します。見つかった不変条件を未記載のままにしてはいけません。
適用したドキュメント更新（または 影響を受けるドキュメントはありません — 変更された N 個のファイルと関連ドキュメントを確認済み）を、レビュー報告書の ## Phase 8 Docs-Update に記録します。
[Review Phase 8] タスクを completed に設定します。

終了保証： フェーズ 8 では、編集を 2 種類に区別します。ドキュメントの文章編集（新しい仕様ルールを追加しない、説明文や参照資料のテキスト）は、コードの動作が変わっていないため、ループを再起動しません。ただし、M1〜M6 の仕様ドリフトチェック（レビューチェックリスト §8）と最終の読み返しの対象です。これにより終了性が保たれます。仕様内容の編集（SPEC-SILENT の不変条件を §3／§4／§8 に追加する、または記載された意図を変更する SPEC-STALE の修正など、新たに仕様ルールを記述する編集）は、強化された仕様に照らして、該当モジュール全体（仕様＋テスト＋コード）を対象とした、範囲を限定した再レビューを 1 回だけ実施します。これにより、新たに記述されたルールがコードで実際に強制され、テストで保護されていることを確認し、さらに隠れたルールがないか調べます。この範囲限定パスは、新たに検証された指摘事項が見つからない限り、そこで終了します（見つかった場合は通常のループに入ります）。範囲限定パスはモジュール単位で、エンリッチメントごとに最大 1 回だけ実行され、フェーズ 0 からの全面的な再起動は行わないため、終了性は保証されます。問題なしで範囲限定パスが完了すれば、スキルも終了します。これにより、エンリッチメントを「最後に 1 回だけ実行され、再確認されない」方式から、「実行後に収束パスを 1 回設ける」方式に変え、レビューとドキュメント更新がいつまでも繰り返される事態を防ぎます。

必須： フェーズ 8 を実行するか、親ワークフローに明示的に委ねるまでは、レビューを完了と宣言したり、引き継いだりしないでください。ドキュメント更新を省略したままレビューに合格しても、レビューは未完了です。

次のステップ

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

"$code-review (Recommended)" — コード品質のより詳細なレビュー
"$watzup" — セッションを締めくくり、すべての変更をレビュー
"Skip, continue manually" — ユーザーが判断

AI エージェント完全性ゲート（譲れない要件）

完了 ≠ 正しさ。 作業を完了したと報告する前に、必ず証明してください。

削除した名前をすべて grep する。 抽出、名前変更、削除の対象となったファイルが N 個なら、すべてのファイル形式を対象に grep し、参照が残っていないことを確認します。

変更前に理由を確認する。 既存の値は、意図的なものだと判明するまでは意図的なものとして扱います。根拠を追跡せずに「修正」しないでください。

すべての出力を検証する。 ビルドが 1 つ通っても、すべてのビルドが通ったことにはなりません。影響を受けるスタックをすべて確認してください。

パターンとの適合性を評価する。 近くにあるコードをコピーする場合は、前提条件が一致していることを確認してください。同じスコープ、ライフタイム、基底クラス、制約である必要があります。

新しい成果物は接続された成果物にする。 何かを作成した場合は、それが登録され、インポートされ、すべてのコンシューマーから到達可能であることを証明してください。

単独実行時の流れ

ワークフロー外から呼び出された場合（つまり、ユーザーが$review-changesを直接実行した場合）：

review-changes (you are here)
  │
  ├─ Phase 3.5: Code-simplifier optimization (INTERNAL — $code-simplifier over changed code files, report mode)
  │    → Simplification findings feed Phase 6 validation → Phase 7 fix (skip docs-only diffs)
  │
  ├─ Phase 3.7: Integration-test-review coverage gate (INTERNAL — $integration-test-review over the FULL diff, 7 gates)
  │    → Gate 7 maps every behavior-changing production file to a covering test (integration-first) + spec TC
  │    → GAP/SPEC-GAP verdicts feed Phase 6 validation → Phase 7 fix
  │    → GAP fix = WRITE the missing test via $integration-test; SPEC-GAP fix = $spec [mode=tests] [update] (skip docs-only diffs)
  │
  ├─ Follow-on quality checks (review-architecture → code-review → performance)
  │
  ├─ Phase 5: Documentation Staleness Triage
  │    → If stale docs detected: [REQUIRED] include as finding for Phase 6 validation
  │    → If validated in Phase 6: [REQUIRED] fix in Phase 7 via $docs-update or canonical doc edit
  │    → Then recursively restart $review-changes from Phase 0
  │
  ├─ Integration test check (SYNC:integration-test-sync-check):
  │    → If logic changes touch tested areas: [REQUIRED] → $integration-test [from-changes]
  │    → Then: $integration-test-review → $integration-test-verify
  │
  ├─ Translation sync check (SYNC:translation-sync-check):
  │    → If multilingual UI text changes lack locale updates: [REQUIRED] ask the user directly + explicit decision
  │
  ├─ Spec drift adjudication (SYNC:spec-drift-adjudication) — ALL behavior-changing reviews:
  │    For every behavior-bearing change diverging from the canonical Feature Spec, classify:
  │    → CODE-WRONG (change violates an intended spec rule/AC/invariant) → [REQUIRED] BLOCKING finding; fix code/test (regression TC first)
  │    → SPEC-STALE (intentional new behavior the spec no longer reflects) → [REQUIRED] $spec [update] BEFORE $docs-update, then $spec [mode=tests] [update]
  │    → AMBIGUOUS → [REQUIRED] ask the user directly (or canonical spec owner) before editing either side
  │    → SPEC-SILENT (code enforces a correct invariant the spec never states) → [REQUIRED] enrich: $spec [update] add §4 BR/§3 AC + $spec [mode=tests] add §8 TC, then guarding test
  │    Bugfix sub-case: if post-bugfix AND spec documents the bug as expected behavior → SPEC-STALE; never let $docs-update codify broken behavior.
  │    Never normalize drift just because code/tests are green.
  │
  ├─ Phase 6 + Phase 7 recursive loop
  │    → If ANY findings exist: $why-review --validate-findings
  │    → If validated findings remain: auto-fix, verify, then restart $review-changes from Phase 0
  │    → Repeat until a full review invocation has zero findings
  │
  ├─ Phase 8: [MANDATORY FINAL after zero findings] → $docs-update over the full changeset
  │    → ALWAYS runs (unconditional) — syncs every impacted doc so none stay stale
  │    → docs PROSE edits (no new spec rule); M1-M6 check + read-back, NO full code re-review (guarantees termination)
  │    → SPEC-CONTENT edits (a newly written spec rule — SPEC-SILENT promoted to §3/§4/§8, or a SPEC-STALE correction changing documented intent) → exactly ONE bounded, module-scoped re-review of the affected module's package (spec + tests + code) to confirm the new rule is enforced in code + guarded by a test; that single pass terminates unless it itself yields a new validated finding (then normal loop). At most once per enrichment, never a full Phase-0 restart.
  │    → A passing review with skipped docs-update is an INCOMPLETE review
  │
  └─ [RECOMMENDED after Phase 8] → $watzup
        Summary of all review findings, doc changes, and test coverage status.

【重大 — 最重要の3つのルール】

必ず最初にフェーズ0のグラフによる影響範囲を確認してください — 絶対に省略しないでください。レビュー全体の順序を決めるために必要です。

指摘事項が見つかったら、検証 → 修正 → 最初からやり直しを行います。 $why-review --validate-findings を実行し、検証済みの指摘事項を修正してから、すべての指摘事項がゼロになるまで、フェーズ0から $review-changes を再実行してください。

開始前に、すべてのフェーズのタスク追跡を必ず行ってください。 テストの不足は、黙って記録するのではなく、ユーザーに直接質問して明らかにする必要があります。

【重要】 開始前にタスク追跡を使用して、ファイルを読むタスクも含め、すべての作業を小さなタスクに分割してください。長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合は、スキップするかどうかを AI が必ずユーザーに尋ねてください。 体系的なレビューのバッチ処理（map-reduce） — 変更セットが大きい場合、ファイルを1つずつレビューしてはいけません。サイズ上限付きのバッチに分割し、バッチごとに専用のサブエージェントを並列で起動してから、結果を統合します。これにより、ファイル数が増えても網羅性を保ちながら、各コンテキスト（各バッチエージェントとオーケストレーター）の負荷を制限できます。

段階的なトリガー（競合するしきい値ではなく、順序に沿ってエスカレーションします）：

変更ファイルが10件未満 → ファイルごとに順次レビューします（デフォルト。バッチ処理なし）。

変更ファイルが10件以上 → 体系的な並列モードに切り替えます。"Detected {N} changed files. Switching to systematic parallel review protocol." と通知します。その後、分類 → サイズ上限付きバッチ処理 → フラットな統合を行います。

カテゴリが6を超える、またはファイルが40件を超える → さらに階層型の統合レイヤー（以下を参照）を追加します。段階2の内容はすべて適用されます。

ステップ1 — 分類。 変更ファイルを、プロジェクトの実際の構造に基づく論理カテゴリにグループ化します（無理に分類しません）。カテゴリは 関心軸 です。以下の例を参考にしつつ、リポジトリに合う分類を導き出します。

カテゴリタイプグループ化の例
エージェント／ツール AI スクリプト、フック、スキル定義、ワークフロー設定、リンティングルール
ルート設定／ドキュメントルート README、プロジェクト設定、CI/CD パイプライン設定
リファレンスドキュメントアーキテクチャドキュメント、パターンのリファレンス、セットアップガイド
機能／ドメインドキュメントビジネス機能のドキュメント、仕様ファイル、ADR
バックエンドロジックサービス／ハンドラー／コントローラーのソース（プロジェクト構造から推測）
フロントエンドロジック UI コンポーネント／状態管理／API のソース（プロジェクト構造から推測）
データ／スキーママイグレーション、スキーマファイル、シードデータ
テスト単体テスト、統合テスト、E2E テストのファイル
インフラストラクチャ Docker、k8s、CI/CD、クラウドのマニフェスト

ステップ2 — サイズ上限付きバッチ処理。 8ファイル以下、または差分行数2,000行以下のいずれかに達するまでを1バッチとし、バッチごとにサブエージェントを1つ割り当てます。カテゴリは引き続き関心軸として扱いますが、上限を超えるカテゴリは複数のサイズ上限付きバッチに分割します（バックエンドファイルが30件なら4バッチ）。「多数のファイル」に安全に対応するのはカテゴリ上限ではなくサイズ上限です。カテゴリだけに上限を設けると、巨大なカテゴリによって1つのエージェントのコンテキストがあふれる可能性があります。

ステップ2a — バッチごとのサブエージェントの種類（バッチの主要な関心事に合わせます）：

コードロジック（あらゆるスタック） → code-reviewer

セキュリティに関わる変更 → security-auditor

パフォーマンスが重要な処理経路 → performance-optimizer

ドキュメント、計画、仕様、設定、インフラ → general-purpose

各バッチサブエージェントには、ファイルの全リスト、主要な思考モデルとしての SYNC:category-review-thinking（固定のチェックリストではなく、第一原理から各カテゴリの懸念事項を導き出します。利用するスキルにそのブロックが含まれていない場合は、カテゴリ優先の思考を直接適用します）、関心事に関連するプロジェクトのリファレンスドキュメント（*patterns*、*conventions*、*style-guide* を使って検索）、相互参照の検証指示（件数、表、リンク）を渡します。すべてのバッチエージェントは並列に実行し、調査結果を plans/reports/ に書き込みます（SYNC:task-tracking-external-report に従います）。統合担当はメモリではなく、ディスクから報告書を読み込みます。

ステップ3 — 統合。

フラットな統合（段階2、カテゴリが6以下、かつファイルが40件以下）： オーケストレーターは各バッチの報告書を収集し、バッチ間で件数／表／契約を相互参照し、カテゴリをまたいだ場合にのみ見つかる欠落（コードには機能があるのにドキュメントに記載がない、新しい API エンドポイントにクライアント側の呼び出しがないなど）を検出し、分類された包括的な報告書1つに統合します。

階層型の統合（段階3、カテゴリが6を超える、またはファイルが40件を超える）： 中間レイヤーを挿入します。各関心事に統合担当エージェントを1つ割り当て、その関心事に属するバッチ報告書だけを読み込ませ、関心事ごとの統合結果を1つ作成します。オーケストレーターは、生のバッチ報告書ではなく、**関心事ごとの統合結果（約5件）**を読み込みます。これにより、統合担当のコンテキストはファイル数ではなく関心事の数に比例します。

関心事間の相互作用の確認（段階3では必須 — 統合レイヤーの死角を補います）： 関心事ごとに分離した統合では、2つの関心事と2つのバッチにまたがる相互作用（データレイヤー／バッチ7の汚染されたソース → API／バッチ3のシンクなど）が抜け落ちる可能性があります。そのため、(a) 各関心事の統合担当は、別の関心事と結びつく可能性のある、触れたエンティティ／シンボル／契約（共有 DTO、イベント名、テーブル名／コレクション名、エクスポートされたシンボルなど）を明記した 「関心事間の相互作用候補」 リストを必ず出力します。(b) オーケストレーターは結論を出す前に、バッチ内だけでなく、すべての関心事ごとの統合結果に含まれる候補リストを対象として、ステップ3の相互参照／欠落確認を必ず実施します。この確認を行わない場合、このレイヤーは対象とする大規模な差分で、コンテキストを制限する代わりに網羅性を犠牲にしてしまいます。

ステップ4 — 全体評価。 すべての調査結果を統合したうえで、統一された意図としての全体的な一貫性、カテゴリ間の同期（ドキュメントはコードと一致しているか、契約は呼び出し元と一致しているか）、カテゴリ間の相互作用に伴うリスク領域、変更された成果物に必要なドキュメント／仕様の更新漏れを評価します。

黙って省略しないでください。 上限によってサンプリングが必要になった場合、または予算の都合でバッチを除外する場合は、除外／サンプリングした範囲を必ず明示してください。網羅範囲に制限があるのに、網羅的に確認したかのように見せてはいけません。 終端から始めるデバッガートレース — 複雑なバグ、検証の失敗、リグレッションの修正、動作を変えるコード、または不明瞭なコードフローに取り組む場合は、修正を提案する前に、観測された最終状態から始めて逆方向にたどります。

フレーム 0：観測された最終状態 — ユーザーに見える出力、失敗したアサーション、ログ行、永続化された値、API レスポンス、レンダリングされた UI、または集計バケットを正確に特定します。それを生成したリーダー／クエリ／レンダラーを、file:line の根拠とともに記録します。

1 ホップずつ逆方向にたどる — 最終リーダー -> 投影／キャッシュ／ストレージ -> 書き込み元 -> コンシューマー／ハンドラー／ジョブ -> プロデューサー／呼び出し元 -> 元のトリガーの順に追跡します。各ホップで、入力、変換、出力、所有者、根拠を記録します。

すべての流入経路を列挙する — リトライ、非同期処理、キャッシュ、バックグラウンド処理、代替の UI／API 経路を含め、最終経路に書き込む可能性のある上流のプロデューサー／呼び出し元／イベント／ジョブをすべて見つけます。各経路を、検証済み、除外、または未確認として示します。

仮説マトリクスを作成する — 考えられる原因ごとに、裏付ける根拠、反証する根拠、再現／検証方法、影響範囲、ステータス（primary、contributing、ruled out、latent）を記載します。競合する原因が明示的に解決されるか、範囲が限定されるまでは修正しません。

修正を担うレイヤーを選ぶ — 不変条件の所有者と、下流のすべてのコンシューマーを保護する最も低い共通箇所を特定します。不変条件の所有者でない限り、症状が現れる箇所での修正は認めません。

前方向の収束を証明する — 修正を選んだ後、開始点 -> 終了点を再度たどり、修正された状態が観測された最終出力にどう到達するかを示します。各根本原因を修正箇所に、各修正箇所をテスト／証明に対応付けます。

以下を完了するまで作業はブロックされます： 最終状態の特定 · 逆方向トレースの記述 · すべての流入経路の列挙 · 仮説マトリクスの完成 · 修正を担うレイヤーの妥当性の説明 · テストに対応付けた前方向の収束証明。

絶対にしてはいけないこと： 最初に疑わしいコード経路から調査を始めること。複数のプロデューサーを 1 つの「フロー」にまとめること。読み取りモデルを検証せずに、重複する症状を重複レコードとして扱うこと。除外した仮説を飛ばすこと。

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

次の場合に使用します： 複雑な問題の分解 · 修正が必要な適応的な計画 · 軌道修正を伴う分析 · 不明瞭、または変化し続けるスコープ · 多段階の解決策 · 仮説に基づくデバッグ · 分野横断的なトレードオフの評価。

形式（明示モード — 思考過程を表示）：

Thought N/M: [aspect] — 思考ごとに1つの側面を扱い、前提や不確実性を示します

Thought N/M [REVISION of Thought K]: ... — 以前の推論が無効になった場合に使用します。Original / Why revised / Impact を示します

Thought N/M [BRANCH A from Thought K]: ... — 別の選択肢を検討し、判断の根拠を示して収束させます

Thought N/M [HYPOTHESIS]: ... に続けて [VERIFICATION]: ... — 実行前に検証します

Thought N/N [FINAL] — 検証済みで、重要な側面にすべて対処し、確信度が80%を超える場合にのみ使用します

必須の締めくくり： 確信度を％で示す · 前提を列挙する · 未解決の疑問を明らかにする · 具体的な次のアクションを示す。

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

暗黙モード： マーカーを付けると回答が煩雑になる場合は、表示マーカーを使わずに内部で手法を適用します（推論が精度向上に役立つ定型作業など）。

詳細： $sequential-thinking スキル（.claude/skills/sequential-thinking/SKILL.md）では、実例（API 設計、デバッグ、アーキテクチャ）、高度なテクニック（スパイラル型の改善、仮説検証、収束）、メタ戦略（不確実性への対処、修正の連鎖）を確認できます。

まずコードを理解する — 厳守事項：既存のコードを読むまで、コードの作成、計画、修正を行わないでください。

類似するパターンを3つ以上検索し（grep／glob）、file:line 形式で根拠を示します

対象領域の既存ファイルを読み、構造、基底クラス、規約を理解します

.code-graph/graph.db が存在する場合は、python .claude/scripts/code_graph trace <file> --direction both --json を実行します

connections または callers_of で依存関係を把握し、対象に依存するものを確認します

重要なタスク（3ファイル以上）では、調査内容を .ai/workspace/analysis/ に記録します

実装前に分析ファイルを読み直します。記憶だけを頼りに作業してはいけません。 — 理由：長いコンテキストではファイルから意識が逸れていきます。ファイルが真実の源です

既存のパターンが機能する場合、新しいパターンを決して作りません。既存のパターンに正確に合わせるか、逸脱する理由を記録します。 — 理由：パターンの不統一はコードベースを分断し、将来の読者すべての作業を遅らせます

次を完了するまで作業を開始できません： - [ ] 対象ファイルを読む - [ ] 3つ以上のパターンを検索する - [ ] グラフをトレースする（graph.db が存在する場合） - [ ] 根拠をもとに前提を検証する 設計パターンの品質 — すべてのコード変更で優先的に確認します。

OOP による DRY： 目的、命名パターン、またはライフサイクルが同じクラス／モジュールを特定します。プロジェクトの言語／フレームワークに関する知識を活用し、慣用的な抽象化（基底クラス、ミックスイン、トレイト、プロトコル、デコレーター）を判断します。類似するパターンが 3 つ以上ある場合は、共通の抽象化を抽出します。

適切な責務： ロジックは最も低い層に置きます（エンティティ > ドメインサービス > アプリケーションサービス > コントローラー）。コントローラーにビジネスロジックを置いてはいけません。

SOLID： 単一責任（変更理由は 1 つ）。オープン・クローズド（変更せず拡張する）。リスコフの置換（サブタイプは置換可能）。インターフェース分離（小さなインターフェース）。依存性逆転（抽象に依存する）。

抽出／移動／名前変更の後： 対象範囲全体を grep して、参照先がなくなった箇所がないか確認します。見落としは一切許容しません。

YAGNI の基準： パターンを推奨するのは、同じものが 3 回以上存在する場合に限ります。将来使うかもしれないという理由で抽出してはいけません。

指摘すべきアンチパターン： ゴッドオブジェクト、コピー＆ペーストによる継承、循環依存、リーキーアブストラクション。

設計品質に対する逐次的な注意 — すべての懸念を一度に扱うのではなく、品質の各観点を一度に 1 つずつ順番に確認します（逐次的なパス）。— 理由：注意が分散すると、1 つの観点に集中したパスなら検出できる違反を見落とします。

該当する観点を特定する — コードの言語、ドメイン、パターンに基づき、適用する品質の観点を判断します。DRY、SOLID 原則（SRP／OCP／LSP／ISP／DIP）、OOP の慣用表現、凝集度／結合度、GRASP、デメテルの法則、CQRS の不変条件などが該当します。観点のリストは固定ではありません。コードが実際に何をしているかから導き出してください。

各観点について、集中して個別に確認する — 各観点に対して、順番に 1 つずつ集中して確認します。各パスで複数の懸念を混在させてはいけません。

基準：類似パターンが 3 つ以上ある場合は抽出が必須 — 任意の提案ではありません。対応が必要な必須の構造修正として指摘してください。

同種の違反が 2 件以上ある場合は構造上の問題 — 個々の事例を列挙するのではなく、アーキテクチャ上の解決が必要な「パターンの問題」として報告してください。 複雑さの防止（Ousterhout） — 必須です。コードは変更コストで評価します。1つのビジネス上の変更は、1つのコード変更に対応するべきです。レビューでは、次のすべてを指摘してください。

変更の増幅 — 小さなビジネス上の変更で3か所を超える編集が必要になる場合、構造上の欠陥です。もっともらしい将来の変更（バリアントの追加、フィールドの追加、認可の追加）について、編集箇所を数えます。3か所を超える場合は却下します。

認知負荷 — 安全に変更するために、読み手が過剰なコンテキストを把握しておく必要がある状態です。深い継承、長いパラメーターリスト、ブール値の罠、暗黙的な順序依存を指摘します。

エントリーポイント間の横断的な重複 — ロギング、エラー処理、バリデーション、認証、トランザクションが、コントローラー／ハンドラー／ルートごとに再実装されている状態です。ミドルウェア／インターセプター／フィルター／デコレーター／アスペクトに引き上げます。

実装技術の漏出 — リポジトリが IQueryable／QuerySet／Criteria／生のカーソル／ORM エンティティを呼び出し元に返している状態です。完成した結果と、意図が伝わるメソッド（Query() ではなく GetActiveVipUsers()）を返します。

型による分岐の散在 — 列挙型／識別子に対する switch／if チェーンが複数箇所にある状態です。新しいバリアントの追加は新しいファイルで行い、N か所の編集を発生させないようにします。境界にある単一のファクトリー／レジストリーでの switch は許容できますが、分岐の散在は却下します。

貧血モデル — ドメインオブジェクトがゲッター／セッターしか持たず、ロジックがサービスに漂流している状態です。不変条件や振る舞いはオブジェクトに移します（order.Status = ... ではなく order.Checkout()）。

プリミティブ型偏重 — 口座番号、メールアドレス、金額、割合、日付範囲に生の string／int／decimal を使い、すべての入力箇所で再検証している状態です。コンストラクターで一度だけ検証する値オブジェクト／レコード／構造体でラップします。

横断的関心事のインライン化 — 認可／テナント分離／監査／サニタイズを、すべてのハンドラーの先頭に手書きしている状態です。宣言的なマーカー（@RequirePermission("Order.Delete")）で意図を示し、中央で一度だけ適用します。

浅いモジュール — 大きなインターフェース（公開メソッドが多い、フラグが多い、コンストラクターパラメーターが多い）で、ロジックの少ない小さなクラスをラップしている状態です。小さなインターフェースの背後に多くの実装を隠せるとき、モジュールは深いと言えます。インターフェースの習得コストが実装の習得コストとほぼ同じなら、インライン化します。

繰り返されるコンポーネント／ハンドラーのライフサイクルに基底クラスがない — 3つ以上のフォーム／CRUD ハンドラー／リストビューで、読み込み／変更状態／送信／ページネーションを再実装している状態です。基底クラス／フック／コンポーザブル／ミックスイン／トレイトに抽出します。

抽象化が早すぎる／遅すぎる — 3回ルールに従います。1回目はそのまま書きます。2回目で重複に気づきます。3回目で抽出します。実際の違いが現れる前に汎用フレームワークを作らず、4回目までコピー＆ペーストを続けないでください。

埋め込みユーティリティーロジックがヘルパーに抽出されていない — インラインのページネーションループ（while (hasMore) { skip += take; ... }）、場当たり的な日時計算、文字列の解析／書式設定、コレクションの分割、リトライ／バックオフループ、URL／クエリ文字列の構築などです。アルゴリズムが自明でなく、かつスタック全体で汎用的（ビジネス固有ではない）なら、util／helper／extensions に抽出し、利用側からは1行で呼び出せるようにします。インラインで重複させると、バグが入り込む範囲も重複します。

ロジックが誤った（上位の）レイヤーにある — 呼び出し先へ移す — データを所有する呼び出し先ではなく、呼び出し元にビジネスロジック／導出ロジックが書かれている状態です。基本方針：コントローラーのコードはアプリケーションサービスにあるべきです。アプリケーションサービスのコードはドメインサービスまたはエンティティにあるべきです。コンポーネントのコードはビューモデル／ストア／サービスにあるべきです。呼び出し元が呼び出し先のデータ形状を調べて何かを計算しているなら、意図が伝わる呼び出し先のメソッドに計算を移します。責務を持つ最下位のレイヤーを選びます（Entity > Domain Service > App Service > Controller · Model/VM > Store > Component）。上位レイヤーに配置すると、兄弟となる呼び出し元が同じ処理を必要とした際に、ロジックが重複します。

ルールは所有者が持つ — 最初に書くときに抽出する — ある型のデータから導出、正規化、検証、または計算するロジックを呼び出し元にインラインで書く場合は、所有する型に移します。1か所でしか使われていなくても抽出します。きっかけは重複ではなく、責務の誤りです。兄弟となる呼び出し元は必ず現れます。インラインのコピーはコンパイルエラーにもならず、検索できる名前もないまま、気づかれずに乖離していきます。よくある問題箇所： バックエンド — アプリケーション層のハンドラー／コマンド／クエリ／サービス／コントローラーにインラインで書かれた、ドメインエンティティ／値オブジェクト／ドメインサービスが担うべきルール。フロントエンド — コンポーネントにインラインで書かれた、モデル／ストア／ビューモデル／API サービスが担うべき導出／書式設定／バリデーション。修正方法： 所有する型に、静的またはインスタンスのメソッドとしてルールを一度だけ命名し、呼び出し元はその名前で呼び出します。将来別のバリアントが必要になったら、所有者に名前付きメソッドをもう1つ追加し、近似した処理をインラインで書くことはしません。まず責務を正しくし、再利用はその結果として実現します。

抽出先 — 名前を付けたルールの配置先：

ルールの形状配置先
エンティティ自身のデータに対する純粋関数エンティティの静的メソッド
エンティティの状態を変更／保護する振る舞いエンティティのインスタンスメソッド
プリミティブ値が常に満たす不変条件値オブジェクトのコンストラクター
DI（リポジトリ／設定／時計）が必要 DI に登録するヘルパークラス
型をまたいで再利用されるドメイン非依存アルゴリズムユーティリティー／拡張メソッド
純粋な形状変換／射影変換 DTO マッピング

コミット前の編集箇所テスト（答えが「多数」なら却下）：

変更シナリオ変更箇所
新しいバリアントの追加（顧客タイプ、決済方法）新しいファイル1つ
HTTP エラーレスポンス形式の変更ミドルウェア／フィルター1つ
永続化されるすべてのエンティティへのタイムスタンプフィールドの追加基底エンティティ／インターセプター1つ
新しいエンドポイントへの認可の追加宣言的マーカー1つ
データベース／ORM の切り替えデータ層のみ
ビジネス計算ルールの変更所有するエンティティのメソッド1つ
フォームへの読み込みインジケーターの追加基底コンポーネント／フック1つ
ドメインプリミティブへのバリデーションルールの追加値オブジェクトのコンストラクター1つ
ページネーション／リトライ／日時アルゴリズムの変更ヘルパー／ユーティリティー関数1つ
エンティティデータの導出処理の変更エンティティのメソッド1つ

運用上の指針：

まず呼び出し箇所を書きます。

もっともらしい将来の変更について、編集箇所を数えます。

コードを追加するより、削除することを優先します。

境界では前提を明示し、内部では詳細を隠します。

再利用前のスキャン — 自明でないコードブロックを書く前に、類似アルゴリズムを grep します（while.*skip、DateTime.*Add、split／join の連鎖、ページネーションループ、リトライループ）。既存のヘルパーが見つかったら呼び出します。見つからず、パターンがスタック全体で汎用的なら、2つ目の呼び出し元が現れる前にユーティリティーへ抽出します。

レイヤー配置テスト — 「明日、兄弟となる呼び出し元がこれを必要としたら、同じ処理をもう一度導出するだろうか？」と考えます。答えが「はい」なら、ロジックのレイヤーが間違っています。より下位へ移します。

将来の再利用に備える — レビュアーが、別の機能にも現れる可能性が高いブロック（ドメイン非依存アルゴリズム、共通のライフサイクル、繰り返される導出処理）に気づいた場合、純粋な YAGNI を理由に見過ごしてはいけません。今すぐ抽出する（簡単なら）か、2つ目の呼び出し元で気づかれないまま重複しないよう、正確な抽出先を記載した追跡可能な TODO を作成します。気づかれない重複が、デフォルトの失敗パターンです。

判断に迷ったら、「要件が変わったとき、何を変更する必要があるだろうか？」と問いかけます。

優れたコードの尺度は変更コストです。 最短であることでも、最も巧妙であることでも、最も抽象化されていることでもありません。コードのごく一部を読めば安全に変更でき、そのコストが最も低いことです。 検証済み指摘の修正＋完全な再レビューのループ — 再レビューはラウンド数ではなく、検証済みの指摘を修正するサイクルをきっかけに実施します。レビューの目的は、問題のない完全なレビューを終えるまで「レビュー → 指摘の検証 → 検証済みの指摘を修正 → 完全な再レビュー」を繰り返すことです。問題のないレビューでループは終了します。それ以上のラウンドは不要です。

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

ラウンド 1 の後の判断：

問題なし（PASS、指摘件数ゼロ） → レビューを終了します。確認のために新しいサブエージェントを起動してはいけません。

問題あり（FAIL、または指摘が 1 件以上） → まず、現在使用中のレビュースキルにある指摘検証ゲートを実行します。レビュースキルのデフォルトゲートは $why-review --validate-findings <report-path> です。検証済みの指摘のみを修正し、新しいタスク分解を行ってレビュー手順全体を最初からやり直します。

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

前のラウンドで見落とした横断的な懸念事項

変更したファイル間の相互作用に起因するバグ

規約からの逸脱（新しいコードと既存パターンとの不一致）

存在すべきなのに欠けている要素

前のラウンドで合理化され、見落とされた微妙なエッジケース

修正自体によって生じたリグレッション

ループの終了条件： 完全再レビューのたびに、同じ判断を繰り返します。問題がなければ終了し、問題があれば、指摘を検証して修正し、最初のレビュー段階からやり直します。完全なレビューで問題がゼロになるまで続けてください。同じ検証済みの指摘が進展なく 3 回の完全な呼び出しで繰り返される場合、または修正にプロダクト担当者やオーナーの入力が必要な場合は、ユーザーに直接質問してエスカレーションしてください。

ルール：

ラウンド 1 で問題がなければレビューは終了します。ラウンド 2 は必須ではありません。

検証されていない指摘を修正してはいけません。呼び出し元の検証ゲートを使用して、まず検証してください。

修正サイクル後の完全再レビューを省略してはいけません（修正のたびに、それ以前の判定は無効になります）。

ラウンドをまたいでサブエージェントを再利用してはいけません。サブエージェントを使用する反復では、そのたびに新しい Agent 呼び出しを行います。

メインエージェントはサブエージェントのレポートを読みますが、指摘事項を選別、再解釈、または覆してはいけません。

問題のないレビューを必須とする要件に代わる、恣意的なサブエージェントのラウンド上限を設けてはいけません。無限に繰り返すことを避ける場合に限り、進展のない同一指摘が 3 回繰り返されたときのブロッカー規則を使用してください。

再帰的な呼び出し回数と繰り返し発生するブロッカーを、会話コンテキスト内（セッション単位）で追跡してください。

最終判定には、実施したすべてのラウンドを反映させてください。

レポートには、実施したすべてのラウンド N≥2 について ## Round N Findings (Fresh Sub-Agent) を含めてください。 新しいコンテキストでの再レビュー — 該当する場合は分離されたサブエージェントを使ってレビュー全体を最初から再開し、修正後にオーケストレーターが確証バイアスに陥るのを防ぎます。

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

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

方法：

新しいレビュー全体の実行／タスク分解を開始します。そのプロトコルでエージェントが必要な場合は、新しい spawn_agent ツール呼び出しを実行します。コードレビューには code-reviewer agent_type を、計画／ドキュメント／成果物のレビューには general-purpose を使用します

必須のレビュー用プロトコルをすべてプロンプトに逐語的に挿入します。全リストとテンプレートについては SYNC:review-protocol-injection を参照してください。ファイルパスでプロトコルを参照してはいけません。ファイル読み込みの間接参照を挟むと、AI の遵守率が低下します（SYNC:shared-protocol-duplication-policy を参照）

サブエージェントは、自身のツール呼び出しを使って対象ファイルをすべて最初から読み直します。ファイルの内容をプロンプトに直接渡してはいけません

サブエージェントは、構造化レポートを plans/reports/{review-type}-round{N}-{date}.md に書き込みます

メインエージェントはレポートを読み、自身のレポートに指摘を反映します。指摘を覆したり取捨選択したりしてはいけません

ルール：

直前のレビュー全体で問題が見つからなかった場合は、新しいサブエージェントを起動しません（修正がなければ、新たに検証するものもありません）

修正サイクルの後にレビュー全体を再開することを決して省略してはいけません。修正が行われるたびに、以前の判定は無効になります

ラウンドをまたいでサブエージェントを再利用してはいけません。新しいラウンドごとに、新しい spawn_agent 呼び出しを実行します

レビュー全体を完了し、指摘がゼロになるまで続けます。同じブロッカーが進展なく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 agent_type を、計画／ドキュメント／成果物のレビューには general-purpose を選択してください
プロトコルセクションを言い換えたり、要約したり、省略したりしてはいけません
ファイルの内容をインラインで渡してはいけません。新しいコンテキストでレビューできるよう、サブエージェントが自身のツール呼び出しを使って読み込みます
ファイルパスやタグ名でプロトコルを参照してはいけません。本文はすでに上で埋め込まれています
プロトコル用のプレースホルダーマーカーを導入してはいけません。プロトコル本文は文字どおり展開された状態に保つ必要があります

ロジックと意図のレビュー — コードの動作が、変更の理由と一致していることを確認します。

変更意図の確認： 変更されたすべてのファイルが、明示された目的に必ず沿っている必要があります。無関係な変更はスコープクリープとして指摘します。

正常系のトレース： 変更されたコードを通る、成功シナリオ全体を1つたどります。

エラー系のトレース： 変更されたコードを通る、失敗またはエッジケースのシナリオを1つたどります。

受け入れ条件との対応付け： 計画のコンテキストがある場合、すべての受け入れ条件をコード変更に対応付けます。

テストで意図を検証： テスト／仕様の変更では、テストが保護対象のビジネスルールまたは不変条件に名前を付けており、その意図が破られた場合に失敗することを確認します。

マイグレーションのテスト除外： マイグレーションコードのテストは作成しないでください。スキーマ／データのマイグレーションは一度限りの実行パスであり、アプリケーションの中核ロジックではありません。

正常系とエラー系の両方のトレースを完了せずに、レビューを合格と判定してはいけません。

バグの検出 — すべてのレビューで、カテゴリー1～4を必ず確認してください。決して省略しないでください。

Null 安全性： パラメーター／戻り値が null になる可能性はありますか？ガードされていますか？オプショナルチェーンの抜け漏れはありませんか？.find() の戻り値は確認されていますか？

境界条件： 1つずれた境界（< と <= の違い）はありませんか？空のコレクションは処理されていますか？ゼロ／負の値や最大制限は考慮されていますか？

エラー処理： try-catch の範囲は適切ですか？例外が黙って握りつぶされていませんか？エラーの型は適切に特定されていますか？finally でクリーンアップしていますか？

リソース管理： 接続／ストリームは閉じられていますか？破棄時にサブスクリプションは解除されていますか？タイマーはクリアされていますか？メモリー使用量は制限されていますか？

並行処理（非同期処理がある場合）： await の付け忘れはありませんか？共有状態の競合状態はありませんか？古いクロージャーやリトライの集中はありませんか？

スタック固有の確認： ローカルコードから判明した、設定済みの言語／ランタイムの落とし穴とフレームワーク固有の失敗要因を確認します。

分類： CRITICAL（クラッシュ／破損）→ FAIL | HIGH（誤った動作）→ FAIL | MEDIUM（エッジケース）→ WARN | LOW（防御的対応）→ INFO

テスト仕様の検証 — 変更されたコードをテスト仕様に対応付けます。

既存のドキュメント、テストケースファイル、BDD フィーチャーファイル、または仕様フォルダーから、プロジェクトのテスト／仕様の形式を特定します。

変更されたコードパスはすべて、対応するテストケース／仕様に必ず対応付けます（対応するものがない場合は「テストケースが必要」と指摘します）。

新しい関数／エンドポイント／ハンドラー → テスト仕様の作成を指摘します。

マイグレーションファイルは TC／テストの作成対象外です。スキーマ／データのマイグレーションは一度限りの実行パスであり、アプリケーションの中核ロジックではありません。

仕様に証拠フィールドがある場合、実際のコード（古い参照ではなく file:line）を指していることを確認します。

意味のある各テストケースがビジネス上の意図／不変条件を示していることを確認します。実装の詳細をなぞるだけで、動作しか示していないテストケースは指摘します。

認証／データの変更がある場合、対応する認可とデータ状態のテストケースが存在することを確認します。

変更されたパスに仕様がない場合、その不足を記録し、プロジェクトのテスト仕様ワークフローを推奨します。

テストとの対応付けを決して省略しないでください。 テストされていないコードパスは、本番環境のバグの最大の原因です。 統合テスト同期チェック — 変更されたビジネスロジックファイルに対応するテストがあることを確認します。

変更されたファイルから ビジネスロジックファイル を特定します。対象は、ハンドラー、コマンド、クエリ、サービス、コントローラー、リゾルバー、イベントプロセッサーです。命名規則はスタックによって異なるため、プロジェクトの規約から推測してください（例：*Service.*、*Handler.*、*Controller.*、*Command.*、*Query.*、*Resolver.*）。マイグレーションファイルは除外します。スキーマやデータのマイグレーションは一度だけ実行される処理であり、アプリケーションの中核的なロジックではありません。

特定した各ファイルについて、対応するテストファイルを検索します。プロジェクト内の既存テストからテストの命名規則を推測してください（例：*.test.ts、*Tests.java、*_test.py、*.spec.js、*Tests.cs）。標準的なテストディレクトリ（tests/、spec/、__tests__/）や、隣接するテストプロジェクト／パッケージを確認します。

テストが存在する場合 → テストメソッドが変更された動作（新しいメソッド／パラメーター／ロジックパス）を網羅しているか確認します。

テストが存在しない場合 → 必須：ユーザーに直接質問します：「ビジネスロジックファイル {file} に統合テストがありません。続行する前に $integration-test を実行しますか。それとも、テストはすでに作成済みであることを確認しますか？」選択肢：「先に $integration-test を実行する」（推奨）|「テストはすでに作成／更新済み — 続行する」

重要度：高 — 変更されたビジネスロジックにテストがない場合は、必ずユーザーに提示してください。黙ってフラグを立てて続行してはいけません。

テストカバレッジがないビジネスロジックの変更はすべて、ユーザーに直接質問して判断を求めてください。決して黙って見過ごしてはいけません。 — 理由：黙って見過ごすと、テストされていないビジネスロジックが本番環境にリリースされます。

翻訳同期チェック — 多言語対応 UI の変更に翻訳の更新が含まれていることを確認します。

プロジェクト設定から多言語モードを判定します：localization.enabled === true かつ supportedLocales.length > 1

拡張子／パスのパターン（.ts、.tsx、.html、.css、.scss および、設定されている場合は localization.uiPathPatterns）を使って、UI に関係するファイルの変更を検出します。

多言語対応 UI に変更がある場合、翻訳リソースに差分があることを確認します（設定されている場合は localization.translationFilePatterns を使用）。

翻訳の更新がない場合 → 必須：ユーザーに直接質問します：「多言語対応プロジェクトで UI テキストが変更されていますが、翻訳の更新が検出されませんでした。翻訳の同期を今すぐ実行しますか。それとも、リスクを明示的に受け入れて続行しますか？」選択肢：「先に翻訳の同期を実行する」（推奨）|「リスクを明示的に受け入れて続行する」

重要度：高 — 翻訳同期について明示的な判断を得ずに、多言語対応 UI のテキスト変更をそのまま通してはいけません。

黙って見過ごしてはいけません。多言語対応 UI のテキスト変更には、翻訳同期についての明示的な確認が必要です。 カテゴリレビューの思考法 — 変更されたファイルのあらゆるカテゴリをレビューするための思考フレームワークです。固定チェックリストではありません。ドメイン知識から懸念事項を導き出してください。以下の例は出発点にすぎません。このカテゴリに関するあなたの知識は、どのリストよりも豊富です。それを信頼してください。

ステップ 1 — カテゴリの役割を理解する。 システム全体において、このカテゴリはどのような責任を担っていますか？維持すべき不変条件は何ですか？利用側との契約（何が依存し、何を期待しているか）は何ですか？

ステップ 2 — このカテゴリに関するプロジェクトの規約を読む。 この領域に特化したリファレンスドキュメント、スタイルガイド、ADR、README を検索します。類似した既存ファイルを 3 つ以上 Grep し、命名規則、構造パターン、共通の基底クラスを抽出します。ドキュメントがない場合は、既存コードから経験的に規約を導き出します。

ステップ 3 — 第一原理から懸念事項を導き出す。 該当するものをすべて適用し、実際のカテゴリに応じてこのリストを拡張してください。

正確性： ロジックは意図に沿っていますか？正常系とエラー系の両方を追跡してください。

境界の契約： インターフェース／API／イベント／プロトコルを遵守していますか？暗黙の結合が導入されていませんか？

プロジェクトの規約： 新しいコードはステップ 2 で確認したパターンに従っていますか？思い込みではなく、証拠に基づいていますか？

セキュリティ： すべてのエントリーポイントで認証が強制されていますか？境界で入力が検証されていますか？差分にシークレットが含まれていませんか？

パフォーマンス： 上限のない処理はありませんか？N+1 パターンはありませんか？非同期コンテキスト内でブロッキング呼び出しをしていませんか？インデックスのないクエリはありませんか？

保守性： DRY ですか？単一責任を守っていますか？複雑さは妥当な範囲内ですか？名前から意図がわかりますか？

テストカバレッジ： 変更された経路はテストでカバーされていますか？変更後も既存のテストは有効ですか？

ドキュメント： 関連するドキュメント、仕様、README に変更が反映されていますか？

ステップ 4 — サブタスクを作成して実行する。 特定した懸念事項ごとに、追跡用のサブタスクを作成し、file:line の証拠を確認しながら対応し、完了としてマークします。証拠のない指摘はしないでください。

カテゴリの種類ごとの懸念事項の例（網羅的な一覧ではありません。ここにないことも、あなたの知識を信頼してください）。

サーバー側ロジック： ハンドラー／サービスの構造規約、検証レイヤーの配置、副作用の分離、サービス間境界の適用、データアクセスレイヤーの分離、エラー伝播の方針

クライアント側ロジック： コンポーネントのライフサイクル管理、リソースのクリーンアップ（サブスクリプション、リスナー、タイマー）、状態管理パターン、API 統合レイヤーの分離、リアクティブストリームの合成

データ／スキーマ： マイグレーションの可逆性（ロールバックスクリプト）、テーブル規模に対するロックの影響、バックフィルの冪等性、クエリパターンに対するインデックスの網羅性、デプロイ順序

設定： すべての環境に存在していますか？差分にシークレットが含まれていませんか？設定がない場合、アプリケーションは即座に失敗しますか（null のまま黙って処理しませんか）？セットアップガイドに記載されていますか？

インフラストラクチャ： 開発環境と本番環境の構成に差はありませんか？開発用の値（localhost、デバッグフラグ）がハードコードされていませんか？イメージ／依存関係のバージョンは固定されていますか？CI/CD のシークレット要件は文書化されていますか？

スタイル／アセット： プロジェクトの命名規則に従っていますか？デザイン変数／トークンを使用していますか（マジック値をハードコードしていませんか）？適切なスコープになっていますか（コンポーネントのスタイルからグローバルな副作用が生じませんか）？

ドキュメント： 正確ですか？リンクは有効ですか？例は現在のコード／動作に合っていますか？新しいシナリオを扱っていますか？

テスト： アサーションは具体的な結果を検証していますか（単に「例外が発生しない」だけではありませんか）？冪等ですか（N 回繰り返しても結果が変わりませんか）？正常系だけでなく、エッジケースもカバーしていますか？

セキュリティ関連成果物： すべてのコード経路がゲートに到達しますか？否定テスト（未認証の場合に拒否されるテスト）はありますか？適用制御と表示制御の両方が更新されていますか？

ビルド／ツール： ルールの変更は一貫して適用されますか？違反を黙って握りつぶす例外はありませんか？CI 実行時間への影響は文書化されていますか？ グラフを活用した調査 — .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倍少なくなります）。次に、詳細を確認するため --node-mode function を使用してください。

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

まず現在のタスクリストを取得します。一致するアクティブな親ワークフロー行が存在する場合は、nested=true を設定して parentTaskId を記録します。存在しない場合は、単独で実行します。

フェーズ作業を始める前に、宣言された各フェーズにつき1つのタスクを作成します。ネストされている場合は、件名に [N.M] $skill-name — phase を付けます。

ネストされている場合は、TaskUpdate(parentTaskId, addBlockedBy: [childIds]) を使って親タスクと関連付けます。

オーケストレーターは、子スキルまたはサブエージェントを呼び出す前に、子スキルのフェーズ一覧を事前に展開し、ワークフロー行を関連付ける必要があります。

作業前に子タスクを正確に1つ in_progress にし、証拠を記録した直後に completed にします。

すべての子タスクが完了するか、理由を明示してキャンセルされた後にのみ、親タスクを完了します。

次の条件が満たされるまでブロック： 現在のタスクリストを取得し、子フェーズを作成し、ネストされている場合は親と関連付け、最初の子タスクを in_progress にすること。

プロジェクト参照ドキュメントのゲート — タスク追跡の初期化後、対象／ソースファイルの読み取り、grep、編集、分析を行う前に実行します。プロジェクトのドキュメントは、汎用的なフレームワークの前提より優先されます。

対象範囲を特定します：ファイルの種類、対象領域、操作内容。

トリガーごとに必要なドキュメント：常に 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。

必要なドキュメントをすべて読みます。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 の実行を依頼し、自動実行はしないでください。

対象の作業を始める前に、次のように明示します：Reference docs read: ... | Not applicable: ...。

準備完了の条件： 対象範囲を評価し、必要なドキュメントを確認・閲覧するかセットアップルートを完了し、lessons.md を確認し、参照元を明記していること。 タスク追跡と外部レポートの永続化 — 実行前にこれを初期化し、その後、対象／ソースの作業に着手する前にプロジェクト参照ドキュメントのプリフェッチを実行してください。

対象ファイルの読み込み、grep、編集、分析を行う前に、小規模なタスクの内訳を作成してください。コンテキストを失った場合は、まず現在のタスクリストを確認してください。

作業前にタスクを1つ in_progress にし、根拠を得た直後に completed にしてください。遷移をまとめて行わないでください。

計画／レビュー作業では、最初の所見を得る前に plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md を作成してください。

ファイル／セクション／判断ごとに所見を追記し、最後にレポートファイルから内容をまとめてください。

最終出力には Full report: plans/reports/{filename} を記載してください。

以下が完了するまで作業は禁止です： タスクの内訳が作成されていること、計画／レビュー作業ではレポートパスが宣言されていること、次の所見に進む前に最初の所見が永続化されていること。

ソース／テストの乖離チェック。 コーディング、修正、デバッグ、調査、テスト、レビュー作業では、ソースの動作が変わった場合、影響を受けるユニット／統合／E2E テストを確認し、意図した動作に合わせてテストを変更すべきか、意図しないバグとしてソースを修正すべきかを根拠に基づいて判断してください。マイグレーションコードのテストは作成しないでください。スキーマ／データのマイグレーションは一度限りの実行パスであり、アプリケーションの中核ロジックではありません。

仕様の乖離の判定（コードの誤りか、仕様の古さか）。 変更された動作が正規の機能仕様（docs/specs/ 配下のビジネスルール、受け入れ基準、フロー、状態遷移、または §8 TC）と食い違う場合、どちらか一方を黙って選んではいけません。shared/sdd-artifact-contract.md → Drift Gates に従って判定してください。

検出 — 変更内容を仕様に記載された意図と比較します。食い違いがなければ、Spec in sync と記録して先に進みます。

食い違いを分類します。

CODE-WRONG — 仕様が意図した動作を正しく記述しており、変更がそれに反している → ブロッキング所見です。意図した動作に沿ってコード／テストを修正してください（まず回帰 TC を作成または調整します）。

SPEC-STALE — 変更後の動作が新たに意図された動作であり、仕様が古い／誤った動作を記載している → $spec [mode=update] で先に仕様を更新し、その後 $spec [mode=tests] と $spec [mode=sync] を同期してください。

AMBIGUOUS — 意図した動作が不明確 → いずれかを編集する前に、ユーザーへ直接質問するか、正規の仕様オーナーに確認してください。

SPEC-SILENT — コードが不変条件／動作を正しく強制しているものの、どの正規仕様アーティファクトにも（§3 AC、§4 BR、§5 invariant、§8 TC）記載されていない → 乖離ではなく、レビューで発見された未記載のルールです。不変条件の抽出パス（$spec [mode=sync] direction=harvest → spec/references/sync.md）を使って仕様を充実させてください。常に真であること（強制箇所が2つ以上、または拒否ガードがあること）を証明し、全称量化された性質として表現したうえで、ルールを §4（または §3／§5）および §8 TC に追加してください（$spec [update] と $spec [mode=tests] を使用）。さらに、そのルールを保護するテストを追加してください。発見された不変条件がコードだけ（またはテストだけ）に残されている状態は不完全です。これは、誰も書き留めていなかったルールを捉える最も価値の高い作業です。

コード／テストがグリーンというだけの理由で、乖離を正当化してはいけません。グリーンの状態そのものが乖離を反映している可能性があります。現在どちらがパスしているかではなく、正規の意図に合わせて整合させてください。

仕様との乖離を判定しないまま終える動作変更を伴うレビュー／実装は不完全です。未記載だが強制されている不変条件を仕様に取り込まず（§4／§8 に記載せず）に残すことも、同様に不完全です。 AI によるミスの防止 — あらゆるタスクで避けるべき失敗パターン：

コンテキストが変わったらファイルを読み直してください。 コンテキストの圧縮、中断後の再開、長時間にわたる作業により、記憶が古くなっている可能性があります。作業に取りかかる前に、現在のファイルを確認してください。 生成した内容をソースの根拠と照合してください。 AI は API、名前、主張、ドキュメントの事実について、幻覚を起こすことがあります。ドキュメントに記載したり参照したりする前に、関連するソースを確認してください。 削除や名前変更の前に、下流の参照を確認してください。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元に古い情報が残る可能性があります。まず参照先を洗い出してください。 編集後は影響の連鎖全体をたどってください。 定義を変更すると、派生する出力や利用者を見落とすことがあります。完了と判断する前に、影響を受ける連鎖をたどってください。 最初の出力だけでなく、影響を受ける出力をすべて確認してください。 1 つのチェックが成功しても、すべてのチェックが成功したことにはなりません。変更の影響を受ける可能性のある出力面をすべて検証してください。 既存の値には意図があると考え、変更する前に理由を確認してください。 定数、上限、フラグ、文言、パターンを変更する前に、周辺のコンテキストと履歴を確認してください。 曖昧さがあれば、黙って決めず、行動する前に明らかにしてください。 複数の解釈が妥当な場合は、明確に質問するか、リスクを示したうえで前提を明記してください。 共有ガイダンスは、それを受け取る役割に関連したものにしてください。 汎用ガイダンスは、それを受け取るすべてのスキルやエージェントに役立つものである必要があります。コード固有の要件は、コード固有のプロトコルだけに記載してください。

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

重大度対応定義
CRITICAL マージをブロック実行時のサイレントな失敗、データ破損、検証の回避、セキュリティ上の欠陥
HIGH 必ず修正誤った動作、不変条件の欠落、アーキテクチャ違反
MEDIUM 修正を推奨設計上の負債、保守性、将来バグになる可能性
LOW 修正するとよい規約、ドキュメント、軽微な明確さ

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

0-2 の基準スコアリング（例：production-readiness-review）：0 = CRITICAL/HIGH（基準を満たさず、本番運用の準備を妨げる）、1 = MEDIUM（一部のみ満たしており、修正を推奨）、2 = 合格（指摘なし）。

2 軸スコアリング（例：performance-review、影響度 × 発生可能性）：結果のセルを最も近い段階に対応付けてください。影響度が高く、発生可能性も高い → CRITICAL/HIGH、影響度が低い、または発生可能性が低い → MEDIUM/LOW。

指摘の段階によってゲートが決まります。CRITICAL/HIGH は、PASS とする前に解決するか、オーナーが明示的に受け入れる必要があります。MEDIUM/LOW は、追跡対象のフォローアップを残して出荷できます。

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

必須・重要 すべての主張について、根拠となる file:line を示してください。確信度が 80% を超える場合に行動し、60% 未満の場合は推奨してはいけません。

重要・必須 OOP による DRY、適切な責務レイヤー、SOLID を確認してください。移動後に参照切れがないか Grep で確認してください。

重要・必須 複雑さの増大を防いでください。ビジネス上の変更 1 件につき、コード変更は 1 件にします。変更の増幅（将来の変更に編集箇所が 3 か所を超える）、散在する型切り替え、貧血モデル、プリミティブ型への執着、抽象化を通じた技術詳細の漏出、浅いモジュール、抽出されていないユーティリティロジック（ページング／日時／文字列／リトライ → ヘルパー）、誤った上位レイヤーにあるロジック（呼び出し先／エンティティ／VM へ移動）を指摘してください。単なる YAGNI を理由に、気付かれない重複を正当化してはいけません。

重要・必須 graph.db が存在する場合は、主要なファイルに対してグラフコマンドを少なくとも 1 つ実行してください。パターン：grep → trace → verify。

重要・必須 コードの動作が変更理由と一致していることを確認してください。正常系とエラー系の両方の経路をたどってください。 要厳守 すべてのレビューで、null 安全性、境界、エラー処理、リソース管理を確認してください。

要厳守 変更されたコードパスをテストケースに対応付けてください。テストされていないパスを指摘してください。

要厳守 変更されたロジックファイルに対応するテストがあるか確認してください。テストが不足している場合は、助言にとどめず、ユーザーに直接質問して明らかにしてください。これは必須です。

要厳守 多言語対応の UI テキストを変更した場合は、翻訳も更新されているか確認してください。更新されていない場合は、ユーザーに直接質問して明示的な判断を求めてください。

厳守批判的かつ段階的に考えてください。すべての主張に、適切な追跡可能な根拠（リポジトリ／コードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または成果物のセクション）を示してください。実行に移す際は確信度を80%超とし、60%未満なら推奨しないでください。ハルシネーションを防ぐため、推測を事実として提示せず、不確実な点は率直に認め、独立して相互検証し、自分の確信度にも懐疑的でいてください。

厳守 sequential-thinking を適用してください。$sequential-thinking スキルに従い、複数ステップでは Thought N/M、REVISION／BRANCH／HYPOTHESIS マーカー、より具体的な確信度％を使用してください。

厳守 AI のミス防止策を適用してください。生成した内容を根拠と照合して検証し、削除や名前変更の前に下流の参照を追跡し、影響を受けるすべての出力を検証してください。コンテキスト喪失後はファイルを読み直し、曖昧な点は実行前に明らかにしてください。

必須対象作業に着手する前にタスク追跡を開始してください。タスクは一度に1つずつ進行させてください。
必須 plans/reports/ に計画とレビュー結果を段階的に保存し、ディスク上の内容をもとにまとめてください。
必須タスク追跡の開始後、対象作業に着手する前に、必要なプロジェクト参照ドキュメントを読み、Reference docs read: ... と記載してください。
必須常に lessons.md を含めてください。プロジェクトの規約は一般的な既定値より優先されます。
必須プロジェクト設定、ルートの指示ファイル、または必要な参照ドキュメントが存在しない、あるいは古くなっている場合は、通常のプロジェクト固有の作業に入る前に、$project-init または対象を絞った下位レベルの手順を自動実行してください。

要厳守 デバッガーのトレースを通過すること：重大なバグ修正、調査、レビューでは、観測された最終出力から始めて、reader → storage/projection → writer → consumer/job → producer/trigger の順に逆向きにたどってください。修正前に、すべての入力経路と仮説を列挙してください。トレース、仮説マトリクス、修正を担うレイヤー、前向きの収束証明がそろうまで、作業はブロックされます。

必須親ワークフローの項目だけでは子フェーズの追跡の代わりになりません。入れ子になっている場合はフェーズを展開し、親との関連付けを行ってください。
必須オーケストレーターは呼び出し前に子スキルのフェーズを展開してください。[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 ファイルにはシークレットを絶対に保存しないでください。
必須変更セットが大きい場合は、サイズ上限（8ファイル以下、または差分2000行以下）に従ってバッチ分けし、各バッチに並列サブエージェントを1つ割り当ててください。多数のファイルを1つずつレビューしてはいけません。
必須カテゴリが6を超える、またはファイル数が40を超える場合は、階層的な統合レイヤーを追加してください。各懸念事項の統合担当者は、懸念事項間の相互作用候補を出し、オーケストレーターは結論を出す前に懸念事項間の検証を行ってください。
必須検出事項を影響度に応じて Critical／High／Medium／Low に分類してください。修正されるか責任者が受け入れるまで、Critical／High は PASS を阻止します。
必須スコアベースのスキル（SRE 0～2、パフォーマンスの2軸）は、別の重大度用語を設けず、同じ4段階に対応付けてください。
必須ファイルの言語、ディレクトリの意味、変更内容からレビューカテゴリを導き出し、カテゴリごとにサブタスクを作成します。
必須各カテゴリの確認事項を、file:line の根拠に基づいて原則から導き出します。固定チェックリストは使用しません。

最後に確認する事項

重要・必ず注意する目標： レビューしたすべての変更に欠陥がなく、根拠に裏付けられ、規約に準拠し、引き渡し前に必要なテストやドキュメントと同期していることを確認します。コードファイルに変更がある場合は、コードが引き続き変更しやすいことも証明します。

重要・必ず注意すること — 適用中のプロトコル（このスキルに含まれる SYNC/shared ブロックの簡潔な要約です。各行は上記の正式な本文を示す案内であり、必ず正式なブロック全体を遵守してください。この要約だけを根拠に行動してはいけません）：

体系的なバッチ処理： ファイルが10個以上の場合 → サイズ上限を設けた並列バッチで処理します。
デバッガートレース： バグ／修正 → End から Start への逆方向トレースを必ず行います。
批判的思考： すべての主張を追跡し、確信度が80％を超えてから行動します。
逐次思考： 複数のステップでは、マーカー付きの Thought N/M を使用します。
まずコードを理解する： grep を3回以上行い、変更前にコードを読みます。
デザインパターンの品質： DRY／SOLID を守り、適切な責任レイヤーを選びます。
複雑さの防止： ビジネス上の変更1件につき、コード変更は1件にします。
二重ラウンドトリップレビュー： 検証 → 修正 → 問題がなくなるまで完全な再レビューを行います。
新しいコンテキストでのレビュー： 修正後、記憶を持たない新しいサブエージェントでレビューします。
レビュー用プロトコルの注入： 11個のプロトコルをサブエージェントへのプロンプトにそのまま埋め込みます。
ロジックと意図のレビュー： コードが実行する内容と変更の理由が一致していることを確認します。
バグ検出： null、境界値、エラー処理、リソースのクリーンアップを確認します。
テスト仕様の検証： 変更されたパスをテストケースに対応付けます。
統合テストの同期： 不足しているテストは、ユーザーへの直接の質問を通じて明らかにします。
翻訳の同期： 多言語 UI テキストを変更した場合は、翻訳も更新します。
カテゴリ別レビューの検討： ファイルと変更内容からカテゴリを導き出します。
グラフを活用した調査： 主要ファイルのグラフトレースを実行します。
ネストされたタスクの作成： 子フェーズを展開し、親タスクに紐付けます。
プロジェクトの参照ドキュメント： lessons.md を含む必要なドキュメントを読みます。
タスクの追跡と報告： タスクを初期化し、調査結果を段階的に保存します。
ソース／テストの乖離： 動作を変更した場合は、影響を受けるテストを調整します。
仕様の乖離： CODE-WRONG／SPEC-STALE／AMBIGUOUS／SPEC-SILENT に分類し、適切な修正先に回します。
AI の誤り防止： 生成内容を根拠と照合し、下流の参照を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後は読み直し、曖昧さを明らかにします。
重大度の基準： 影響に基づいて Critical／High／Medium／Low に分類します。

[CRITICAL — TOP 3 RULES REPEATED]

必ず注意：フェーズ0のグラフによる影響範囲の分析を最初に行います — 絶対に省略しません。レビュー全体の優先順位を決定します。

必ず注意：指摘事項は、現在の所有権の境界に従います。 単独モードではフェーズ6の検証 → フェーズ7の修正 → $review-changes の最初からの再実行を行います。$workflow-review-changes 内では、レポートを作成した時点で終了し、指摘事項を親のステップ2に引き渡します。その後、親のステップ10～15で計画／feature-implement／再実行を担当します。

必ず注意：開始前に、すべてのフェーズのタスクを追跡します。 テストの不足は、必ずユーザーへの直接の質問を通じて明らかにします。

必須ネストされたタスク展開の契約 — ワークフロー内から呼び出された場合も、タスク追跡を使って内部フェーズを必ず展開し、[N.M] $review-changes — phase のプレフィックスと TaskUpdate(parentTaskId, addBlockedBy: [childIds]) による関連付けを行ってください。ワークフローの行はコンテナであり、内部フェーズの代わりにはなりません。
必須作業を始める前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください
必須直接ユーザーに質問して判断を確認してください — 決して自動で決めないでください
必須作業品質を検証するための最終レビュー ToDo タスクを追加してください
必須作業を始める前に、プロジェクト固有のリファレンス文書を見つけて読み込んでください
必須フェーズ 0 のグラフ影響範囲分析を最初のステップにしてください — 決して省略しないでください
必須修正前にすべての指摘を検証してください。スタンドアロンモードでは $why-review --validate-findings を呼び出し、親モードの $workflow-review-changes ではレポートの作成後に停止し、検証を親のステップ 2 に委ねてください
必須スタンドアロンモードでは、検証済みの指摘を修正した後、フェーズ 0 から新しいタスク分解で $review-changes を再帰的に呼び出し、修正したファイルだけでなく現在の差分全体をレビューしてください。親モードでは、親のステップ 10～15 が修正計画、feature-implement、全体の再レビューを担当します
必須 1 回のレビュー呼び出し全体で指摘がゼロになるまで、検証 → 修正 → 全体の再レビューを続けてください。スタンドアロンモードではそのループをローカルで実行し、親モードでは指摘を $workflow-review-changes に報告してループを委ねてください
必須すべてのレビューでドキュメントの陳腐化を確認してください — 自動修正しない場合も、古くなったドキュメントを指摘してください
必須レビュー／修正ループで指摘がゼロになったら、フェーズ 8 の最終 $docs-update ゲートを実行してください — クリーンな判定でも常に実行し、例外なく省略しないでください（$workflow-review-changes 内では、親の docs-update ステップに委ねる場合のみ保留できます）。理由：コードレビューに合格しても、docs-update が実際の変更に照らして影響を受けるすべてのドキュメントを整合させるまでは、ドキュメントの陳腐化は解消されません。docs-update を省略したままのクリーンレビューは未完了です
必須差分にコードファイルが含まれる場合は、フェーズ 3.5 Code-Simplifier Optimization ゲートを実行してください。変更されたコードファイルに対して $code-simplifier を（レポートモードで）呼び出し、明瞭さ／一貫性／保守性に関する指摘をレポートに記録して、フェーズ 6 の検証 → フェーズ 7 の修正に回してください。ドキュメントのみの差分の場合に限り省略し、その理由を記録してください。理由：正確性レビューは動作することを証明し、simplifier ゲートは変更コストの低さを証明します。このゲートは明確な注意喚起がなければ、気づかれないまま省略されてしまいます
必須差分に動作を伴うコードが含まれる場合は、フェーズ 3.7 Integration-Test-Review Coverage ゲートを実行してください。変更セット全体（本番コードとテスト）に対して $integration-test-review を呼び出してください。Gate 7 では、すべての動作変更について、対応するテスト（まず統合テストを検討し、ユニットテストにフォールバックする場合は理由を説明）と仕様の TC を対応付ける必要があります。また、すべての GAP／SPEC-GAP をフェーズ 6 の検証 → フェーズ 7 の修正に回してください（GAP の修正では不足しているテストを作成します）。ドキュメントのみの差分の場合に限り省略し、その理由を記録してください。また、$workflow-review-changes 内では、親が専用の $integration-test-review ステップを実行するため、そちらに委ねてください。理由：見た目上は正しい変更でも、対応するテストがなかったり仕様が古かったりすると、保護されない動作がリリースされます。ファイル名の対応関係だけではカバレッジは証明できません
必須変更されたビジネスロジックに対するテストが不足している場合は、必ず直接ユーザーに質問して確認してください — 黙って記録するだけではいけません
必須スタンドアロンモードでは、指摘が1 件でもある場合、フェーズ 6 Why-Review 指摘検証ゲートを実行してください。スキル呼び出しを通じて $why-review スキルを --validate-findings 付きで呼び出します（ターミナルモード、同じセッション内での実際のスキル呼び出しが必要です。自分で該当箇所を読み直したり、インラインで手動検証したりしても、このゲートを満たしません）。最初の指摘を記録した時点で、タスク追跡に [Review Phase 6] Why-review findings validation gate — invoke $why-review を登録し、忘れないようにしてください。すべての指摘が正確で、証拠に裏付けられ、妥当であり、ベストプラクティスに沿っていることを検証してください。指摘の問題や改善機会が見つかった場合に限り再実施してください（再実施は最大 2 回。その後は直接ユーザーに質問してエスカレーションします）。その後、フェーズ 7 で検証済みの指摘を修正し、このスキルを再開してください。$workflow-review-changes 内では、フェーズ 6／7 をローカルで実行せず、親のステップ 2 とステップ 10～15 に各ゲートを委ねてください
必須宣言されたステップの順序を守ってください — ユーザーの明示的な承認なしに、ステップを省略、並べ替え、統合してはいけません
必須省略したステップには必ず明確な理由を付け、完了したステップには簡潔な証拠を示してください
必須レポート主導で進めてください — 各ファイル／観点のレビューを行うたびに、すべての指摘を plans/reports/code-review-{date}-{slug}.md に順次書き込んでください。最後にまとめて書いてはいけません。理由：レポートは外部記憶であると同時に成果物でもあります。コンテキストにだけ保持された指摘は、コンパクション時に失われます
必須証拠ゲート — すべての主張、指摘、推奨事項は、file:line の証拠、または追跡可能な呼び出しチェーンと信頼度の評価で裏付けてください（80％超は対応、60～80％は先に検証、60％未満は推奨してはいけません）。憶測を出力することは禁止です。「証拠不十分」も有効な判定です。理由：裏付けのない指摘は作者の時間を浪費し、レポート全体への信頼を損ないます
必須指摘する前に規約を確認してください — パターン、命名、スタイルの違反を指摘する前に、既存の例を 3 件以上 grep してください。教科書上のルールよりコードベースの規約を優先してください。理由：プロジェクトで採用されていないルールに照らして指摘すると、誤検出が生じます
必須変更されたコードに YAGNI／KISS／DRY／Clean Code を適用してください — 先を見越しすぎた汎用化、不要な複雑さ、知識の重複を指摘してください。同様のパターンが 3 件以上ある場合は必ず抽出し、同種の違反が 2 件以上ある場合は個別の細かな指摘ではなく、構造的な指摘にしてください。理由：これらは「変更しやすさ」という成功指標を日々の作業で実現するものです
必須動作を変更するレビューすべてで、Spec Drift Adjudication を実施してください（バグ修正後に限りません）。仕様との差異を CODE-WRONG／SPEC-STALE／AMBIGUOUS／SPEC-SILENT に分類し、必要な修正先に回してください（CODE-WRONG → コードを修正し、回帰 TC を追加。SPEC-STALE／SPEC-SILENT → $spec [update] と $spec [mode=tests] を実行。AMBIGUOUS → 直接ユーザーに質問）。差異がなければ Spec in sync と記録してください。理由：コードとテストに合格していても、仕様違反を気づかれないまま常態化させる可能性があります
必須二重フィードバック台帳を適用してください — 動作を変更する指摘はすべて、仕様とテストの両方に反映する必要があります。どちらかの軸の欄が空欄、または理由なしの「N/A」だけの場合は不合格です（N/A には必ず欄内に理由を記載してください）。理由：コードだけを修正すると、仕様かその TC が古いまま残り、次の変更で問題が再発します
必須バグ修正デバッガートレースゲート（§6.5） — バグ修正／回帰／検証失敗／出力の陳腐化／動作変更を伴う修正では、End→Start デバッガートレース、列挙された流入経路、仮説マトリクス、修正レイヤーの選定根拠、前方収束の証拠と回帰テストの証拠がすべて揃っていなければ、レビューを不合格にしてください。理由：トレースのない修正は症状が現れる箇所だけを直し、バグを再発させます
必須 Fresh-Context ゲート（フェーズ 3）はレビュー専用です — 指摘を追加することはできますが、修正も検証もしてはいけません。既知の指摘を再レビューしてはいけません。また、フェーズ 7 の再開だけを理由に実行してはいけません。指摘が 1 件でもあれば、直ちにフェーズ 6 に進めてください。理由：既知の指摘を再レビューすると、追加の情報を得られないままコンテキストを消費します
必須サブエージェントと統合時の指摘を、生のままメインレポートに取り込んでください — すべて読み、決して除外、緩和、上書きしないでください。理由：メインエージェントは自分のミスを合理化してしまいます。メモリを持たないサブエージェントは、まさにそのミスを見つけるために存在します
必須差分にフロントエンド／UI ファイルが含まれる場合、UI の観点は $review-changes が担当します — $review-ui を実行してください（同じ並列バッチ内の ui-ux-designer サブエージェントを優先します）。長いコンテンツのオーバーフロー、レスポンシブな flex サイズ調整、z-index の適切な運用、SCSS／BEM の品質を確認してください。フロントエンドファイルに変更がない場合に限り省略できます。理由：$review-ui は独立したワークフローのステップとして存在しないため、UI のレビューを省略すると、不具合が未レビューのままリリースされます
必須変更が触れる、または同期すべき仕様／機能ドキュメント／PBI／ストーリー／テスト仕様には、M1～M6 コード対仕様ドリフトゲート（§8、ブロッキング）を適用してください。技術情報の漏出（M1）／散文としてのソースコード（M2）／論理 ID の対応付けの破損（M3）／AC の曖昧さ（M4）／成果物だけでは仕様を再構築できないこと（M5）のいずれかを導入した場合は不合格です。不合格時は、違反した必須項目 ID と変更箇所の file:line を明示してください。情報源を示す [Source:]、**Evidence**、フロントマター、mermaid は対象外です。理由：M1～M5 の違反を変更によって導入したまま合格させると、レビュー自体に欠陥が生じます
必須アーキテクチャ境界チェック — 変更されたファイルごとに docs/project-config.json の architectureRules.layerBoundaries を読み、ファイルのレイヤーを特定し、そのインポートを grep してください。cannotImportFrom に指定されたレイヤーからのインポートがあれば、重大な問題としてブロックしてください。architectureRules が存在しない場合は何もせず省略してください。理由：レイヤー境界の違反は、ビルドを通って気づかれないままリリースされ、アーキテクチャを徐々に損ないます
必須作業完了を報告する前に AI エージェント完全性ゲートを実施してください — 削除された名前をすべて grep し（すべてのファイル種別で参照が残っていないこと）、既存値を変更する前に理由を確認し、影響を受けるすべての出力を検証し（1 件が成功しても、すべての成功を意味しません）、近くのコードをコピーする前にパターンが適切か評価し（同じスコープ／ライフタイム／基底クラス／制約であること）、新しい成果物がすべて適切に接続されていること（登録済み、インポート済み、到達可能）を証明してください。理由：完了は正しさを意味しません。検証されていない「完了」は未テストの仮説です
必須変更ファイルが 10 件以上の大規模な変更セットには、体系的レビューのバッチ処理を適用してください — カテゴリ分けを行い、バッチのサイズを 8 ファイル以下、または差分 2,000 行以下に制限し、各バッチに並列サブエージェントを 1 つずつ実行してから結果を統合してください。カテゴリが 6 を超えるかファイルが 40 件を超える場合は、横断的な懸念事項の相互作用を確認する階層的な統合レイヤーを追加してください。対象範囲を除外または抽出してレビューする場合は必ず明示してください — 多数のファイルを 1 件ずつレビューしてはいけません。また、範囲を絞ったカバレッジを完全なレビューと誤認させてはいけません。理由：大きな差分では、単一エージェントのコンテキストが気づかれないまま切り詰められ、未レビューのファイルが残る可能性があります

［末尾リマインダー — WHY-REVIEW の検出結果検証ゲートは必須です］

長いコンテキストでも確実に守られるよう、冒頭のリマインダーと同じルールを繰り返します。スタンドアロンモードで検出結果が1つでもあれば、修正、ドキュメント更新、コミット、引き継ぎの前に、必ず $why-review スキルを呼び出し（スキルの呼び出し、--validate-findings <report-path>）てください。インラインまたは手動での自己検証は、実際にスキルを呼び出すことの代わりにはなりません。最初の検出結果が出た時点で [Review Phase 6] ゲートをタスクとして追跡し、絶対に忘れないようにしてください。$workflow-review-changes 内では、親ステップ2に従ってください。

正当化への対策：

反論	再反論
"グラフの影響範囲を調べるには単純すぎる"	Phase 0 のグラフチェックでリスクの優先順位を決めます。実行するか、グラフを利用できないことを記録してください。
"問題が見つからなかったので、ドキュメントやテストは不要"	問題なしという判定でも、ドキュメントやテストを確認した、または明示的に関連なしと判断した証拠が必要です。
"問題は明らかなので、今すぐ修正する"	まず `$why-review` スキル（`--validate-findings`）を呼び出してください。これはインラインでの自己検証ではなく、実際のスキル呼び出しです。検証されていない問題は修正ではありません。
"自分でもう一度、該当箇所を確認した"	インラインで読み直しても Phase 6 の条件は満たしません。このゲートでは、判定を返す `$why-review` スキルの実際の呼び出しが必要です。
"修正したファイルだけ再確認する"	修正は先行する変更と相互作用する可能性があります。差分全体を対象に、Phase 0 から `$review-changes` をやり直してください。
"サブエージェントがすでにレビューした"	メインレポートには生の指摘を統合し、それらを覆したり、選別したりしてはいけません。
"プロジェクトの規約はすでに検索した"	`file:line` の例を3件以上示してください。証拠がなければ、検索していません。
"DRY／SOLIDの原則上、この抽象化が必要"	将来の変更コストを下げることを証明してください。そうでなければ、品質向上ではなく形式的な作業です。
"バグが見つからなかったので、簡素化の確認は不要"	バグの発見と簡素化は別です。変更したコードファイルを対象に、Phase 3.5 の `$code-simplifier` を必ず実行してください。
"テストファイルを変更していないので、テストレビューは不要"	レビュー対象はテストファイルではなく変更内容です。Phase 3.7 の Gate 7 では、すべての動作変更を、それを網羅するテストと仕様の TC に対応付けます。
"同じ名前のテストファイルがある"	ファイル名の対応は網羅性を意味しません。Phase 3.7 の `$integration-test-review` で、変更した動作がアサーションレベルで網羅されていることを証明してください。
"レビューで問題がなかったので、ドキュメントも問題ないはず"	コードに問題がなくても、ドキュメントが最新とは限りません。引き渡し前に Phase 8 の `$docs-update` による一括確認を実行してください。これは必須であり、条件付きではありません。
"動作は変わったが、仕様とテストは合格している"	合格していても同期が取れているとは限りません。仕様ドリフトの裁定と Dual-Feedback Ledger の両方を実行し、乖離を分類して、必要な仕様／テストの修正に割り振ってください。
"バグは修正したので、出荷する"	§6.5 の End→Start トレース、フィーダーの列挙、仮説マトリックス、回帰の証明がなければ、バグ修正レビューは FAIL です。
"十分に自信があるので、引用は不要"	確信度が80％未満なら、まず検証してください。`file:line` がなければ推測であり、出力は禁止されています。何をどのようにたどったかを明記してください。
"問題なく読めるし、正しそう"	「問題なさそう」は証拠ではありません。正しいと判断する前に、正常系を1つ、エラー系を1つたどり、該当行を引用してください。
"フロントエンドの小さな変更なので、UIレビューは不要"	UIに関する確認は `$review-changes` の対象です。差分にフロントエンドのファイルが1つでもあれば `$review-ui` を実行してください。別の工程として後回しにすることはできません。
"近くのコードがこうしているので、それをまねる"	最も近い例であっても、前提条件が一致するとは限りません。まねる前に、新しいコンテキストでスコープ、ライフタイム、基底クラス、制約が同じであることを証明してください。
"仕様の説明文にクラス名があるだけなので、問題ない"	仕様の説明文に技術やソースコード由来の内容を記載すると、§8 により M1／M2 FAIL となります。適用除外はキャリアのみです。要件 ID と変更した `file:line` を示してください。
"インポートがコンパイルできるので、レイヤーに問題はない"	コンパイルできても許可されているとは限りません。`architectureRules.layerBoundaries` を確認してください。`cannotImportFrom` 違反はスタイル上の軽微な問題ではなく、BLOCKING Critical です。
"ファイルが多いので、全部読めばよい"	大きな差分では、1つのコンテキストが通知なく途切れることがあります。10ファイル以上の場合は、サイズ上限付きで並列バッチ処理してから集約し、対象から除外／抽出した範囲があれば明示してください。
[TASK-PLANNING] 作業に取り掛かる前に、スコープを小さな TODO タスクに分割してください。`in_progress` は常に 1 つに保ち、最後にレビューの TODO を追加してください。

最後にもう一度 — 成功の指標は「変更しやすさ」です。 すべての指摘、テスト、リファクタリング、抽象化について、次の 1 つの問いに答えてください。これによって次の変更がより低コストになるか、それとも高コストになるか？ 将来の変更コストを下げないのであれば、採用しないでください。結合、隠れた状態、重複した知識、意図の不明瞭さこそが真の敵です。具体的に指摘してください。

重要・必ず注意 .code-graph/graph.db が存在する場合、グラフによる影響範囲の分析を最初に実行してください。 重要・必ず注意 すべての主張には file:line による証拠が必要です。古くなったドキュメントやテストに関する判断には、すべて根拠が必要です。 重要・必ず注意目標： レビューしたすべての変更に不具合がなく、証拠に裏付けられ、規約に沿い、引き継ぎ前に必要なテスト／ドキュメントと同期していることを確認してください。コードファイルが変更された場合は、コードの変更しやすさも証明してください。

Hookless Prompt Protocol Mirror (自動同期)

ソース：.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 ツールで実行できます。

検出： プロンプトが明示的なスラッシュ形式のスキル／ワークフローコマンドで始まる場合は、直接実行してください。そうでない場合は、ワークフローカタログとスキル一覧に照らしてプロンプトを確認してください。
分析： 最適な選択肢を決定してください。直接実行する、スキルを呼び出す、標準ワークフローを開始する、またはカスタム手順を組み合わせます。
自動選択： 最適な選択肢を自分で選んでください。直接実行、スキル、標準ワークフロー、カスタムワークフローのどれにするか、ユーザーに選択を求めないでください。
開始： ワークフローを選択した場合は $start-workflow <workflowId> を呼び出してください。スキルを選択した場合はそのスキルを呼び出してください。カスタムワークフローの場合はカスタム手順を順に実行し、直接実行の場合はタスクに着手してください。
タスク作成： 選択した経路に複数の手順がある場合は、実行前にすべてのワークフロー／スキル／カスタム手順についてタスクを記録してください。
実行： コンテキストの指示にある ワークフローの手順進行と並列フェーズ のルールに従って進めてください。進行はモデル主導です。サブエージェントの完了はインライン呼び出しと同様に手順を進めます。並列フェーズのグループは全員の戻りを待つバリアです。すべてのメンバーが戻るまで進めず、決して直列化しないでください。

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

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

SYNC:ai-sdd-artifact-contract

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

再利用可能な AI-SDD の原則は .claude に置き、リポジトリ固有のパス、コマンド、担当者、製品、形式はプロジェクト設定または参照ドキュメントに記載します。

サイクルを維持します：spec -> plan -> tasks -> implement -> verify -> update spec/docs。

すべての要件または不変条件を、判断、タスク、TC／テスト、ソースの根拠、ドキュメント／仕様の更新まで追跡します。

コードから仕様への抽出は、正規の仕様オーナーが承認するまでは参照専用として扱います。

同期されたコンテキストがあれば、サポート対象の AI ツールで計画、実装、レビュー、検証を行えます。複数のツールを使うかどうかは任意です。

まず .claude のソースを更新してから、生成されたミラーを同期します。.agents、.codex、AGENTS.md を手動で編集しないでください。— 理由：ミラーは生成された成果物であり、次回の同期時に手動編集内容が上書きされます

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 のミスと教訓を分析する」を追加します。

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

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

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

コンテキスト圧縮後はファイルを読み直してください。 編集するには、同じコンテキスト内で事前に Read を実行している必要があります。圧縮すると読み取り状態は消去されます。編集前に読み直してください。
一括置換の後は古い用語を grep で検索してください。 AI は検索と置換ですべて置き換えられたと過信します。一括編集の後は、ドキュメント／設定／カタログに見落としがないか、リポジトリ全体を grep で検索してください。
削除する前に下流の参照を確認してください。 削除によってドキュメントやコードの不整合が連鎖的に発生します。削除前に、参照しているファイルを洗い出してください。
記憶を失った後は、新しく作成する前に既存の状態を確認してください。 圧縮すると、それまでの作業の記憶が消えます。再開するには現在の状態を確認してください。決して何も考えずに重複作成しないでください。
AI が生成した内容は実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、grep で存在を確認してください。
編集後は依存関係を最後までたどってください。 定義を変更しても、下流の利用箇所を見落とすことがあります。依存関係を最後までたどってください。
名前を変更する場合は、利用側のすべてのファイル形式を grep で検索してください。 一部のファイル形式では参照切れが黙って無視され、コンパイルエラーも発生しません。コード、テンプレート、設定、生成ファイルを検索してください。
正しさを検証する際は、コードパスをすべてたどってください。 コードが存在することと、実行されることは同じではありません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップもたどってください。
ソースの変更に合わせて、正規データを埋め込んでいるドキュメントも更新してください。 ワークフロー、スキーマ、設定などの派生データをインラインで記載しているドキュメントは、気づかないうちに古くなります。ソースとともに、埋め込み先のドキュメントもすべて更新してください。
コンテキスト復旧後は、サブエージェントの結果を検証してください。 親エージェントのコンテキストが圧縮されている間に、バックグラウンドのエージェントが完了していることがあります。完了したと思い込まず、出力を grep で確認してください。
対象リスト全体とサブエージェントへの割り当てを照合してください。 カテゴリごとに並行してサブエージェントを動かすと、境界にある項目が漏れることがあります。作業を進める前に、割り当ての和集合を対象リストと照合してください。
サブエージェントが引き継ぐ知識は、そのエージェントの .md 定義からのみ得られます。組み込みの Explore ではなく、カスタムのエージェントタイプを使用してください。ツールを導入するには、権限、知識、強制力（番号付きのワークフロー手順）が必要です。
サブエージェントの調査結果は、最後にまとめてではなく、随時保存してください。 長時間稼働するサブエージェントは最終書き込み前に制限に達し、調査結果が失われることがあります。報告ファイルにセクションごとに追記するよう指示してください。
デバッグでは修正する前に「誰の責任か」を確認してください。 呼び出し元（データが誤っている）と呼び出し先（処理が誤っている）をたどってください。責任のあるレイヤーで修正し、症状が現れている箇所だけを修正しないでください。
抽出／リファクタリング後は、削除した名前をすべて grep で検索してください。 主なファイルで作業が「完了」していても、ほかのファイルがきれいになっているとは限りません。完了とする前に、削除したシンボルごとに対象範囲全体を grep で検索してください。
既存の値には意図があると考え、変更する前に理由を確認してください。 「誤り」とパターンマッチで判断すると、背景を見落とします。定数、上限値、フラグを変更する前に、コメント、git blame、周辺コードを確認してください。
最初の出力だけでなく、影響を受ける出力をすべて検証してください。 1 つのビルドが成功しても、すべて成功したとは限りません。複数のスタック（バックエンド／フロントエンド／テスト／ドキュメント）にまたがる変更では、出力をすべて検証してください。
近くにあるパターンをコピーする前に、適合性を評価してください。 最も近い例が、同じ前提条件を満たすとは限りません。新しいコンテキストで、同じ制約、基底クラス、スコープ、ライフタイムが適用されるか確認してください。
デバッグは全体像を優先し、目の前の原因に飛びつかないでください。 最初に思いついたもっともらしい原因へ、いきなり掘り下げてはいけません。すべての前提条件（設定、環境変数、パス、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）行が大きい場合 — プロジェクションによって比例して削減できます。投資対効果では、プロジェクションより行数の削減が優れています。
ドメイン概念を汎用／共有／インフラのレイヤーに持ち込まないでください。 再利用可能なレイヤー（共有ライブラリ、フレームワーク、インフラモジュール）が、利用側固有のドメイン概念（テナント／顧客／製品 ID、ビジネスエンティティ、機能ルール）を参照してはいけません。こうした依存が入り込んでもコンパイルや実行は成功するため、レビューをすり抜け、知らないうちに「再利用可能」なレイヤーが特定の利用側に結合されます。共有型にはドメイン概念を含めず、サブクラス化／コンポジションを通じてドメインのフィールドやロジックを利用側に配置してください。— 理由：ある利用側のドメインに結合したレイヤーは、もはや再利用可能ではありません。

Markdown 対応

ログインしてコメント

基本情報

作者: duc01226
リポジトリ: duc01226/easyplatform
カテゴリ: テスト・品質
インストール数: 48
GitHub スター: 12

問題を報告

スキル	関連性	呼び出すタイミング
`$docs-update`	必須の最終ゲート（Phase 8） — レビュー／修正ループが収束した後の最終的なドキュメント同期。指摘された陳腐化に対する主要な修正経路でもあります	Phase 8でレビューがクリーンになったら必ず実行（単独の場合）— 無条件です。また、検証済みの陳腐化の指摘に対してPhase 7で実行します。`$workflow-review-changes`では親に委ねられます。
`$spec-index`	派生インデックス — Feature Specsからバケットの`INDEX.md`／ERDを再生成します（情報源としては使用しません）	Specsの変更後、ナビゲーション補助を更新するために実行します — Specsの修正には使用しません
`$spec [update]`	正式なSpec更新ツール — 機能ドキュメントの§1-8（唯一の信頼できる情報源）を修正します	docs-updateから内部的に呼び出されます。対象を絞った更新では直接呼び出し、Specに誤りがあるシナリオを検出した場合はdocs-updateの前に呼び出します
`$spec [mode=tests] [update]`	テストSpec更新ツール — テストケースが古くなっている可能性がある場合に呼び出します	docs-updateから内部的に呼び出されます。対象を絞ったテストケースの更新では直接呼び出します
`$integration-test-review`	必須のカバレッジゲート（Phase 3.7） — 7つのゲートによるテスト品質監査と、ゲート7の変更カバレッジ対応付け（すべての動作変更 → 対応するテスト＋Spec TC）	動作に関わるコードが変更された場合、Phase 3.7で必ず実行します（単独の場合）。`$workflow-review-changes`では親の専用ステップに委ねられます。ドキュメントのみの差分ではスキップします
`$review-ui`	UI／フロントエンド品質ゲート — オーバーフロー、レスポンシブなフレックス、z-index、SCSS/BEM	このスキルが担当します — 差分にフロントエンド／UIファイルが含まれる場合、UIの観点として内部的に呼び出されます（ui-ux-designerサブエージェント）。個別のワークフローステップではありません
`$code-simplifier`	品質最適化の観点 — 明瞭さ／一貫性／保守性を高める簡素化	このスキルが担当します — 差分にコードファイルが含まれる場合、Phase 3.5でレポートモードとして内部的に呼び出されます。指摘事項はPhase 6の検証からPhase 7の修正へと進みます
`$code-review`	コード品質 — 変更されたコードの詳細なレビュー	review-changesの品質チェックに続いて必ず実行します

カテゴリタイプ	グループ化の例
エージェント／ツール	AI スクリプト、フック、スキル定義、ワークフロー設定、リンティングルール
ルート設定／ドキュメント	ルート README、プロジェクト設定、CI/CD パイプライン設定
リファレンスドキュメント	アーキテクチャドキュメント、パターンのリファレンス、セットアップガイド
機能／ドメインドキュメント	ビジネス機能のドキュメント、仕様ファイル、ADR
バックエンドロジック	サービス／ハンドラー／コントローラーのソース（プロジェクト構造から推測）
フロントエンドロジック	UI コンポーネント／状態管理／API のソース（プロジェクト構造から推測）
データ／スキーマ	マイグレーション、スキーマファイル、シードデータ
テスト	単体テスト、統合テスト、E2E テストのファイル
インフラストラクチャ	Docker、k8s、CI/CD、クラウドのマニフェスト

ルールの形状	配置先
エンティティ自身のデータに対する純粋関数	エンティティの静的メソッド
エンティティの状態を変更／保護する振る舞い	エンティティのインスタンスメソッド
プリミティブ値が常に満たす不変条件	値オブジェクトのコンストラクター
DI（リポジトリ／設定／時計）が必要	DI に登録するヘルパークラス
型をまたいで再利用されるドメイン非依存アルゴリズム	ユーティリティー／拡張メソッド
純粋な形状変換／射影変換	DTO マッピング

変更シナリオ	変更箇所
新しいバリアントの追加（顧客タイプ、決済方法）	新しいファイル1つ
HTTP エラーレスポンス形式の変更	ミドルウェア／フィルター1つ
永続化されるすべてのエンティティへのタイムスタンプフィールドの追加	基底エンティティ／インターセプター1つ
新しいエンドポイントへの認可の追加	宣言的マーカー1つ
データベース／ORM の切り替え	データ層のみ
ビジネス計算ルールの変更	所有するエンティティのメソッド1つ
フォームへの読み込みインジケーターの追加	基底コンポーネント／フック1つ
ドメインプリミティブへのバリデーションルールの追加	値オブジェクトのコンストラクター1つ
ページネーション／リトライ／日時アルゴリズムの変更	ヘルパー／ユーティリティー関数1つ
エンティティデータの導出処理の変更	エンティティのメソッド1つ

タスク	最低限必要なグラフ操作
調査／スカウト	2〜3 個のエントリーファイルに対して `trace --direction both` を実行
修正／デバッグ	不具合のある関数に対して `callers_of` を実行し、さらに `tests_for` を実行
機能／拡張	変更対象のファイルに対して `connections` を実行
コードレビュー	変更された関数に対して `tests_for` を実行
影響範囲	`trace --direction downstream` を実行

重大度	対応	定義
CRITICAL	マージをブロック	実行時のサイレントな失敗、データ破損、検証の回避、セキュリティ上の欠陥
HIGH	必ず修正	誤った動作、不変条件の欠落、アーキテクチャ違反
MEDIUM	修正を推奨	設計上の負債、保守性、将来バグになる可能性
LOW	修正するとよい	規約、ドキュメント、軽微な明確さ