review-post-task

Codex の互換性に関する注記：

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

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

Codex では、Claude のフックによるドキュメント注入は行われません。 コーディング、計画、デバッグ、テスト、レビューの際は、次の振り分けに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

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

状況に応じて読むドキュメント：

• バックエンド／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
• 仕様／テストケースの計画、または TC マッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：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 ツールを利用できない場合は、同じステータス遷移を適用しながら、手順ごとの同等の計画トラッカーを作成して維持してください。

クイックサマリー

目標： タスク完了後にコードレビューを 2 パスで実施し、コミット前に問題を見つけます。

ワークフロー：

1. パス 1：ファイルごとのレビュー — 変更した各ファイルを個別にレビューします
2. パス 2：全体レビュー — アプローチ、アーキテクチャ、一貫性を全体的に評価します
3. 報告 — 重大な問題と推奨事項を要約します

主なルール：

• 品質を確保します。欠陥、バグ、更新漏れ、古い内容がないことを確認します
• コードとドキュメントの両方が十分に更新されているか確認します
• file:line 形式で参照箇所を示し、根拠に基づいた指摘を行います

コード変更を完了した後、必須の 2 パスレビューのプロトコルを実行してください。 対象：$ARGUMENTS

code-review スキルを有効にし、タスク完了後の 2 パスプロトコルに従ってワークフローを実行してください：

レビューの心構え（絶対遵守）

懐疑的な姿勢を保ってください。批判的思考と段階的な思考を適用してください。すべての主張について、根拠をたどり、確信度をパーセンテージで示してください（着想の確信度は80%を超える必要があります）。

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

第一原則 — 変更しやすさ

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

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

• 変更コストを高める「ベストプラクティス」は退けてください（時期尚早な抽象化、推測に基づく汎用化、漏れのある間接化、見返りのない形式主義）。
• 指摘では、真の敵を明示してください。結合、隠れた状態、重複した知識、意図の不明瞭さ、早すぎる段階で表面化した取り消し不能な決定です。
• 変更しやすいシンプルな設計は、変更しにくい洗練された設計に勝ります。

以下にある特定のルール、パターン、チェックリストを適用する前に、この視点を適用してください。下位のルールが変更コストを高める場合は、この原則を優先してください。

---

基本原則（すべて徹底すること）

YAGNI — 仮定上の将来の問題を解決するコード（未使用のパラメーター、推測に基づくインターフェース、時期尚早な抽象化）を指摘してください
KISS — 不必要に複雑な解決策を指摘してください。「もっとシンプルな方法はないか？」と問いかけてください
DRY — コードベース全体で類似コードや重複コードを grep してください。類似パターンが3つ以上ある場合は、抽出を指摘してください
クリーンコード — 読みやすさを巧妙さより優先してください。名前から意図が伝わるようにします。関数は1つのことだけを行います。深いネストは避けます（3階層以下）。メソッドは30行未満にします
規約に従う — パターン違反を指摘する前に、必ず既存の例を3つ以上 grep してください。コードベースの規約を優先します
欠陥なし・バグなし — ロジックの経路をたどってください。エッジケース（null、空、境界値）を検証してください。エラー処理を確認してください
根拠必須 — すべての主張に file:line の根拠または grep の結果を添えてください。推測は禁止です
ドキュメントの陳腐化 — 変更したファイルを関連ドキュメント（機能ドキュメント、テスト仕様、README）と照合してください。現在のコード変更を反映していない古いドキュメントや、更新が漏れているドキュメントを指摘してください

可読性チェックリスト（必ず評価すること）

承認する前に、コードが読みやすく、保守しやすく、理解しやすいことを確認してください。

• スキーマの可視性 — 関数がデータ構造（オブジェクト、マップ、設定）を計算する場合、読み手がコードをたどらずに済むよう、コメントで出力の形を示してください
• 自明でないデータフロー — データが複数の段階（A → B → C）で変換される場合、簡潔なコメントで処理の流れを説明してください
• 自己説明的なシグネチャ — 関数のパラメーターで役割が分かるようにしてください。未使用のパラメーターは指摘してください
• マジック値 — 説明のない数値や文字列には、名前付き定数を使うか、インラインで理由を説明してください
• 明確な命名 — 変数名や関数名は、実装を読まなくても意図が伝わるようにしてください

プロトコル

パス 1： 変更内容を収集し（git diff）、プロジェクトのレビューチェックリストを適用します。

• バックエンド：プラットフォームリポジトリ、バリデーション、イベント、DTO
• バックエンド：データシーダーのシードデータ（マイグレーションではありません） — DB のリセット後もデータを保持する必要がある場合は、シーダーを使用します
• フロントエンド：基底クラス、ストア、untilDestroyed、BEM
• アーキテクチャ：レイヤーの配置、サービスの境界
• 規約： 類似パターンを 3 件以上 grep し、コードがコードベースの規約に従っていることを確認します
• 正確性： ロジックの経路をたどり、エッジケース（null、空、境界値）を確認します
• DRY： コードベース全体で重複または類似するコードを grep します
• YAGNI/KISS： 過剰な設計、不要な抽象化、推測に基づく機能を指摘します
• ドキュメントの陳腐化： 変更したファイルを docs/business-features/、テスト仕様、README と照合し、古くなったドキュメントを指摘します

[IMPORTANT] データベースパフォーマンスプロトコル（必須）：

1. ページング必須 — すべてのリスト／コレクションクエリで、必ずページネーションを使用します。すべてのレコードをメモリに読み込んではいけません。確認事項：Skip/Take またはカーソルベースのページングを使わない、上限のない GetAll()、ToList()、Find() がないこと。
2. インデックス必須 — すべてのクエリフィルターフィールド、外部キー、ソート列にデータベースインデックスを設定する必要があります。確認事項：エンティティ式がインデックスのフィールド順と一致していること、データベースコレクションにインデックス管理メソッドがあること、マイグレーションに WHERE／JOIN／ORDER BY 列のインデックスが含まれていること。

見つかった問題を修正します。

パス 2（必須 — 新しいサブエージェントによる第 2 ラウンド）：

プロトコル： SYNC:double-round-trip-review + SYNC:fresh-context-review + SYNC:review-protocol-injection（すべてこのファイル内にインラインで記載されています）。

SYNC:review-protocol-injection の上記テンプレートにある標準 Agent テンプレートを使用して、第 2 ラウンド用に新しい code-reviewer サブエージェントを起動します。このサブエージェントは、パス 1 の指摘事項や修正内容を一切把握していません。Agent 呼び出しのプロンプトを組み立てる際は、次の手順に従います。

1. SYNC:review-protocol-injection テンプレートの Agent 呼び出し形式をそのままコピーします
2. 次の 9 つの SYNC ブロックの本文全文を一言一句そのまま埋め込みます（すべてこのスキルファイルの上部にインラインで記載されています）：SYNC:evidence-based-reasoning、SYNC:bug-detection、SYNC:design-patterns-quality、SYNC:logic-and-intention-review、SYNC:test-spec-verification、SYNC:fix-layer-accountability、SYNC:rationalization-prevention、SYNC:graph-assisted-investigation、SYNC:understand-code-first
3. Task を "Review ALL uncommitted changes holistically. Focus on cross-cutting concerns, interaction bugs, convention drift, missing pieces, subtle edge cases (null/empty/boundary/off-by-one), over-engineering, naming inconsistencies, logic errors, test spec gaps." に設定します
4. Target Files を "run git diff to see all uncommitted changes" に設定します
5. レポートのパスを plans/reports/review-post-task-round{N}-{date}.md に設定します

サブエージェントの処理が完了したら、次の手順に従います。

1. サブエージェントのレポートを読みます
2. 指摘事項を ## Round {N} Findings (Fresh Sub-Agent) としてメインレポートに統合します — 取捨選択したり、覆したりしてはいけません
3. FAIL の場合： 問題を修正してから、新しい第 N+1 ラウンドのサブエージェントを起動します（新しい Agent 呼び出しを行い、第 2 ラウンドのエージェントを再利用してはいけません）
4. 新しいラウンドは最大 3 回 — 3 ラウンド後も失敗する場合は、ユーザーに直接質問して対応を求めます
5. 最終判定には、すべてのラウンドの指摘事項を反映させます

最終レポート： タスクの説明、パス 1／2 の結果、変更内容の概要、修正した問題、残っている懸念事項。

統合に関する注意事項

• $cook、$fix、$code の後、ワークフローオーケストレーションによって自動的に実行されます
• $review-post-task で手動実行できます
• PR のレビューには、代わりに $code-review を使用します
• 複雑なレビューには、code-reviewer サブエージェントを使用します

---

系統的レビューのプロトコル（変更ファイルが 10 件以上の場合）

変更ファイルが多い場合（10 件以上）は、関心事ごとにファイルを分類し、カテゴリごとに code-reviewer サブエージェントを並列起動してから、指摘事項を統合した包括的なレポートを作成します。 4 ステップの完全なプロトコル（分類 → サブエージェントの並列実行 → 統合 → 総合評価）については、review-changes/SKILL.md §「Systematic Review Protocol」を参照してください。

---

AI エージェントの完全性ゲート（交渉不可）

完了 ≠ 正しさです。 作業完了を報告する前に、必ずその証拠を示してください。

1. 削除した名前をすべて grep します。 抽出、名前変更、削除が N 個のファイルに及んだ場合、すべてのファイル形式を対象に grep し、参照の残骸が 0 件であることを確認します。
2. 変更する前に理由を確認します。 既存の値は、意図的であることが否定されるまでは意図的なものです。根拠をたどらずに「修正」してはいけません。
3. すべての出力を検証します。 1 つのビルドが通っても、すべてのビルドが通るとは限りません。影響を受けるすべてのスタックを確認します。
4. パターンへの適合性を評価します。 近くのコードをコピーする場合は、前提条件が一致すること、つまりスコープ、ライフタイム、基底クラス、制約が同じであることを確認します。
5. 新しい成果物は、接続された成果物である必要があります。 何かを作成した場合、すべての利用側で登録、インポートされ、到達可能であることを証明します。

[IMPORTANT] 作業を始める前に、すべての作業を小さなタスクに分割してタスク管理に登録してください。各ファイルを読むタスクも含めます。これにより、長いファイルによるコンテキストの喪失を防ぎます。簡単な作業の場合は、スキップしてよいか、AI は必ずユーザーに注意を促して確認してください。

前提条件： 実行する前に、必ず注意して読んでください。

重要な目的： 品質を確保します。不備、バグ、更新漏れ、古い内容がないことを確認します。コードとドキュメントの両方を検証します。

必須・重要・要注意： 次に示すプロジェクト固有の参考ドキュメントを読むタスクを ToDo に計画してください。

• docs/project-reference/code-review-rules.md — アンチパターン、レビュー用チェックリスト、品質基準 （最初に読む）（関連する場合は直接読み、フックによって会話に挿入されたテキストに頼らないでください）
• docs/project-reference/integration-test-reference.md — 統合テストのパターン、フィクスチャのセットアップ、シーダーの規約、学んだ教訓（統合テストのレビューや作成の前に必ず読んでください）
• project-structure-reference.md — サービス一覧、ディレクトリツリー、規約

ファイルが見つからない場合は、プロジェクトのドキュメント、コーディング規約、アーキテクチャのドキュメントを検索してください。

OOP と DRY の徹底： 必須・重要・要注意 — 基底クラス、ジェネリック、ヘルパーに抽出すべき重複パターンを指摘してください。同じグループまたは接尾辞（例：*Entity、*Dto、*Service など）に属するクラスは、共通の基底クラスを継承する必要があります（今は空でも、将来の共通ロジックや子クラスでのオーバーライドに備えられます）。プロジェクトで、そのスタック向けのコードリンター／アナライザーが設定されていることを確認してください。

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

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

ブロック解除の条件： 現在のタスクリストの完了、子フェーズの作成、ネストされている場合の親タスクとの関連付け、および最初の子タスクを in_progress にすること。 プロジェクト参照ドキュメントのゲート — タスク追跡の初期設定後、対象ファイル／ソースファイルの読み取り、grep、編集、分析を行う前に実行してください。プロジェクトのドキュメントは、一般的なフレームワークの前提より優先されます。

1. 対象範囲を特定します。ファイルの種類、ドメイン領域、操作内容を確認してください。
2. トリガーごとに必要なドキュメントを確認します。常に docs/project-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-docs-reference.md。アーキテクチャ／新しい領域では project-structure-reference.md。
3. 存在する必要なドキュメントをすべて読みます。存在しないドキュメントは該当なしとしてスキップしてください。[Injected: <path>] のような会話内のテキストを、現在のコンテキストにドキュメントが含まれている証拠として信頼しないでください。
4. 対象作業の前に、次の形式で明示します。Reference docs read: ... | Missing/not applicable: ...。

作業開始条件： 対象範囲の評価、必要なドキュメントの確認／読み取り、lessons.md の確認、引用の提示が完了していること。

タスク追跡と外部レポートの保存 — 実行前にこれを初期設定し、その後、対象／ソースの作業に入る前にプロジェクト参照ドキュメントを先行取得してください。

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

作業開始条件： タスク内訳が作成済みであること。計画／レビュー作業ではレポートのパスが宣言済みであること。次の指摘に進む前に、最初の指摘が保存されていること。

批判的思考の姿勢 — 批判的思考と逐次的思考を適用してください。すべての主張には追跡可能な根拠が必要です。行動に移す際の確信度は 80% を超えている必要があります。 幻覚防止： 推測を事実として示してはいけません。すべての主張に出典を示し、不確実性は率直に認め、出力の誤りを自己検証し、独立した情報源と照合し、自分の確信度にも懐疑的でいてください。根拠のない確信は、あらゆる幻覚の根源です。

根拠に基づく推論 — 憶測は禁止です。すべての主張に証拠が必要です。

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

作業開始条件： 証拠となるファイルパス（file:line）を提示済みであること。grep 検索を実施済みであること。類似パターンを 3 件以上確認済みであること。確信度を明示済みであること。

証拠なしでの使用禁止： 「明らかに」「私はこう思います」「～のはずです」「おそらく」「これは～が原因です」。

未完了の場合の出力： 「証拠が不十分です。確認済み：［...］。未確認：［...］。」 まずコードを理解する — 厳格な必須条件：既存のコードを読まずに、書く、計画する、修正することをしてはいけません。

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

以下が完了するまで作業は禁止： - [ ] 対象ファイルを読んだ - [ ] 3つ以上のパターンを検索した - [ ] グラフトレースを実行した（graph.db が存在する場合） - [ ] 仮定を根拠に基づいて検証した

設計パターンの品質 — コードを変更するたびに優先して確認します。

1. OOP による DRY： 目的、命名パターン、またはライフサイクルが同じクラス／モジュールを特定します。プロジェクトの言語／フレームワークに関する知識を活用し、慣用的な抽象化（基底クラス、ミックスイン、トレイト、プロトコル、デコレーター）を判断します。類似パターンが3つ以上ある場合は、共通の抽象化に切り出します。
2. 適切な責務： ロジックは最も低いレイヤーに配置します（エンティティ > ドメインサービス > アプリケーションサービス > コントローラー）。コントローラーにビジネスロジックを配置してはいけません。
3. SOLID： 単一責任の原則（変更理由は1つ）。開放／閉鎖の原則（変更せずに拡張する）。リスコフの置換原則（サブタイプは置換可能）。インターフェース分離の原則（小さなインターフェース）。依存性逆転の原則（抽象に依存する）。
4. 切り出し／移動／名前変更の後： 対象範囲全体を grep して、参照漏れがないことを確認します。見逃しは一切許容しません。
5. YAGNI の基準： 類似パターンが3つ以上存在しない限り、パターンを決して推奨してはいけません。将来の仮定上の用途のために切り出してはいけません。

指摘すべきアンチパターン： 神オブジェクト、コピー＆ペーストによる継承、循環依存、漏れのある抽象化。

設計品質のための逐次的な注意 — すべての懸念を一度に見るのではなく、品質の観点を1つずつ順番に確認します。— 理由：注意を分散させると、1つに集中した確認なら見つけられる違反を見落とします。

1. 該当する観点を特定する — コードの言語、ドメイン、パターンに基づいて、DRY、SOLID の原則（SRP／OCP／LSP／ISP／DIP）、OOP の慣用表現、凝集度／結合度、GRASP、デメテルの法則、CQRS の不変条件など、適用する品質の観点を判断します。確認する項目は固定ではありません。コードが実際に何をしているかをもとに導き出します。
2. 観点ごとに集中して確認する — 各観点について、順番に1つずつ集中して確認します。確認のたびに複数の懸念を混在させてはいけません。
3. しきい値：類似パターンが3つ以上なら、必ず切り出す — 任意の提案ではありません。対応が必要な構造上の修正として指摘します。
4. 同種の違反が2つ以上なら、構造上の問題として扱う — 個別の事例を列挙するのではなく、アーキテクチャ上の解決が必要な「パターンの問題」として報告します。 修正を契機とする再レビューのループ — 再レビューはラウンド番号ではなく、修正サイクルを契機に実行します。レビューの目的は、問題が見つからなくなるまで「レビュー → 問題があれば修正 → 再レビュー」を繰り返すことです。問題のないレビューでループは終了します。それ以上のラウンドは不要です。

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

ラウンド 1 の後の判断：

• 問題が見つからない（PASS、指摘事項ゼロ） → レビューを終了します。確認のために新しいサブエージェントを起動してはいけません。
• 問題が見つかった（FAIL、または指摘事項が 1 件以上） → 問題を修正してから、新しいサブエージェントを起動し、ラウンド 2 の再レビューを行います。

新しいサブエージェントによる再レビュー（修正サイクルのたびに実施）： spawn_agent ツールを新たに呼び出してください。以前のエージェントを再利用してはいけません。サブエージェントは、以前のラウンドの記憶を一切持たずに、すべてのファイルを最初から読み直します。起動方法については SYNC:fresh-context-review を、標準のエージェントプロンプトテンプレートについては SYNC:review-protocol-injection を参照してください。新しいラウンドでは、次の点を必ず確認します。

• 前のラウンドで見落とされた、複数の箇所にまたがる懸念事項
• 変更されたファイル間の相互作用によるバグ
• 既存のパターンに対する規約の乖離（新しいコードと既存のパターンとの不一致）
• 存在すべきなのに欠けている要素
• 前のラウンドで正当化され、見過ごされた微妙なエッジケース
• 修正自体によって生じたリグレッション

ループの終了条件： 新しいラウンドのたびに、同じ判断を繰り返します。問題がなければ終了し、問題があれば修正して次の新しいラウンドに進みます。問題が 0 件になるまで、または 新しいサブエージェントによるラウンドを最大 3 回実施するまで続けます。上限に達したら、ユーザーに直接質問してエスカレーションします。

ルール：

• 問題のないラウンド 1 でレビューは終了します。ラウンド 2 は必須ではありません。
• 修正サイクルの後に、新しいサブエージェントによる再レビューを絶対に省略してはいけません（修正のたびに、以前の判定は無効になります）。
• ラウンドをまたいでサブエージェントを絶対に再利用してはいけません。反復のたびに、新しい Agent 呼び出しを実行します。
• メインエージェントはサブエージェントの報告を読みますが、指摘事項を選別、再解釈、または覆してはいけません。
• レビューあたり、新しいサブエージェントによるラウンドは最大 3 回です。それでも FAIL の場合は、ユーザーに直接質問してエスカレーションします（黙ってループを続けてはいけません）。
• 会話コンテキストでラウンド数を管理します（セッション単位）。
• 最終判定には、実施したすべてのラウンドを反映させます。

実施したラウンド N（N≥2）ごとに、レポートに ## Round N Findings (Fresh Sub-Agent) を含める必要があります。 新鮮なサブエージェントによるレビュー — 独立したサブエージェントを用いて、オーケストレーターの確証バイアスを排除します。

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

タイミング： 修正サイクルの後にのみ実施します。問題がゼロだったレビューラウンドでループを終了し、確認のためのサブエージェントを起動してはいけません。問題が見つかったレビューラウンドでは、修正後に新しいサブエージェントで再レビューします。

方法：

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

ルール：

• 前回のラウンドで問題がゼロだった場合は、新しいサブエージェントを省略します（修正がなければ、新たに検証するものもありません）。
• 修正サイクルの後に新しいサブエージェントを省略してはいけません。修正を行うと、以前の判定はすべて無効になります。
• ラウンドをまたいでサブエージェントを再利用してはいけません。新しいラウンドごとに、新たな spawn_agent 呼び出しを開始します。
• レビューあたりの新しいサブエージェントによるラウンドは最大3回です。それでも問題が解決しない場合は、ユーザーに直接質問してエスカレーションします。黙ってループしたり、以前のプロトコルにフォールバックしたりしてはいけません。
• 会話コンテキスト内で反復回数を追跡します（セッション内のみで管理し、永続ファイルは使用しません）。

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

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

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

• 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)

### 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: JS: === vs ==, typeof null. C#: async void, missing using, LINQ deferred execution.
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)
- 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.
`
})

ルール

• テンプレート全体（埋め込み済みのプロトコルセクション10個を含む）をコピーします。
• Task／Round／Reference Docs／Target Files／Output セクションの {placeholders} のみを、コンテキストに応じて置き換えます。
• コードレビューには code-reviewer の agent_type を、計画／ドキュメント／成果物のレビューには general-purpose を選択します。
• プロトコルセクションを言い換えたり、要約したり、省略したりしてはいけません。
• ファイルの内容を直接渡してはいけません。サブエージェントが独自のツール呼び出しで読み込むことで、新しいコンテキストを確保します。
• プロトコルをファイルパスやタグ名で参照してはいけません。本文はすでに上記に埋め込まれています。
• プロトコル用のプレースホルダーマーカーを導入してはいけません。プロトコルは展開済みの内容をそのまま保持する必要があります。

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

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

1. 変更意図の確認： 変更されたすべてのファイルが、明示された目的に必ず関係している必要があります。無関係な変更はスコープクリープとして指摘します。
2. 正常系のトレース： 変更されたコードを通じて、成功シナリオを最初から最後まで1つ追跡します
3. エラー系のトレース： 変更されたコードを通じて、失敗またはエッジケースのシナリオを1つ追跡します
4. 受け入れ条件との対応付け： 計画のコンテキストがある場合、すべての受け入れ条件をコード変更に対応付けます
5. テストで意図を検証： テスト／仕様の変更については、テスト名が保護対象のビジネスルールまたは不変条件を示しており、その意図が損なわれた場合に失敗することを確認します。
6. マイグレーションテストの除外： マイグレーションコードのテストは作成しないでください。スキーマ／データのマイグレーションは一度限りの実行パスであり、アプリケーションの中核ロジックではありません。

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

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

1. null安全性： パラメーターや戻り値がnullになる可能性はありますか？ガードされていますか？オプショナルチェーンに漏れはありませんか？.find() の戻り値はチェックされていますか？
2. 境界条件： 1つずれた境界（< と <=）はありませんか？空のコレクションは処理されていますか？ゼロや負の値はどうですか？最大制限はありますか？
3. エラー処理： try-catchの範囲は適切ですか？例外が何も通知されずに握りつぶされていませんか？エラーの型は具体的ですか？finallyでクリーンアップしていますか？
4. リソース管理： 接続／ストリームは閉じられていますか？破棄時にサブスクリプションを解除していますか？タイマーはクリアされていますか？メモリー使用量は制限されていますか？
5. 並行処理（非同期の場合）： await の不足はありませんか？共有状態に対する競合状態はありませんか？古いクロージャーはありませんか？リトライの集中はありませんか？
6. スタック固有： JS：=== と ==、typeof null。C#：async void、using の不足、LINQの遅延実行。

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

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

1. 既存のドキュメント、テストケースファイル、BDDフィーチャーファイル、または仕様フォルダーから、プロジェクトのテスト／仕様形式を特定します。
2. 変更されたすべてのコードパスは、対応するテストケース／仕様に必ず対応付ける必要があります（対応するものがない場合は「テストケースが必要」と指摘します）
3. 新しい関数／エンドポイント／ハンドラー → テスト仕様の作成が必要であると指摘します
4. TC／テストの作成対象からマイグレーションファイルを除外します。スキーマ／データのマイグレーションは一度限りの実行パスであり、アプリケーションの中核ロジックではありません。
5. 仕様にエビデンスフィールドがある場合、実際のコードを参照していること（古い参照ではなく、file:line）を確認します
6. 意味のある各テストケースがビジネス上の意図／不変条件を示していることを確認します。実装の詳細をなぞるだけの、動作のみを記述したケースは指摘します。
7. 認証／データの変更については、対応する認可およびデータ状態のテストケースが存在することを確認します。
8. 変更されたパスに仕様が存在しない場合は、その不足を記録し、プロジェクトのテスト仕様ワークフローを推奨します。

テストへの対応付けを決して省略しないでください。 テストされていないコードパスは、本番環境のバグの最大の原因です。

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

削除する前に、下流の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードの古さが連鎖的に広がります。削除する前に、参照しているすべてのファイルを洗い出してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係の全体を追跡してください。 定義を変更すると、そこから派生する下流の変数や利用箇所を見落とすことがあります。必ず依存関係の全体を追跡してください。 正しさを検証する際は、すべてのコードパスを追跡してください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期終了、エラー分岐、条件によるスキップも必ず追跡してください。 デバッグ時は、修正する前に「責任があるのはどこか」を確認してください。 バグが呼び出し元（誤ったデータ）にあるのか、呼び出し先（誤った処理）にあるのかを追跡してください。責任のあるレイヤーで修正し、症状が現れた箇所だけを修正してはいけません。 既存の値は意図的なものと考え、変更する前に理由を確認してください。 定数、上限、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 複数のスタックに関わる変更では、影響を受けるすべての出力を検証する必要があります。チェックが1つ成功しても、すべて成功したことにはなりません。 全体を優先するデバッグ — 目先の対象に引きずられないでください。 障害を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。その後、コードレイヤーに関する仮説を立てる前に、それぞれを証拠と照合してください。 変更は最小限に — 差分テストを適用してください。 バグ修正では、変更した各行がそのバグに直接結び付いていなければなりません。隣接するコードのスタイル変更や改善はしないでください。機能強化タスクでは、改善を実装し、明示的に伝えてください。 コーディング前に曖昧さを明らかにしてください — 黙って解釈を選ばないでください。 依頼に複数の解釈がある場合は、それぞれの工数見積もりを提示して確認してください。全レコード対象、ファイルベース、またはより複雑な方法だと決めつけてはいけません。

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

重要：必ず注意 OOP による DRY、適切な責任レイヤー、SOLID を確認してください。移動後は、参照先がなくなった参照を grep で確認してください.

重要：必ず注意 レビューループを実行してください：レビュー → 問題があれば修正 → 新しいサブエージェントによる再レビュー。問題が見つからなかったラウンドでレビューは終了です.

重要：必ず注意 変更したファイルに対してグラフ影響分析を実行してください。差分を計算してください：影響対象 − 変更対象 = 古いまま残っている可能性のある対象.

重要：必ず注意 コードの動作が変更理由と一致することを検証してください。正常系とエラー経路を追跡してください.

重要：必ず注意 レビューのたびに、null 安全性、境界値、エラー処理、リソース管理を確認してください.

重要：必ず注意 変更したコードパスを TC-{FEATURE}-{NNN} に対応付けてください。テストされていないパスにはフラグを立ててください.

必ず注意 批判的思考を適用してください — すべての主張に追跡可能な証拠が必要です。行動に移す際の確信度は80%を超えていなければなりません。幻覚防止：推測を事実として提示してはいけません.

必ず注意 AI によるミスの防止策を適用してください — 全体を優先するデバッグ、責任のあるレイヤーでの修正、コーディング前の曖昧さの明示、コンパクション後のファイルの再読を徹底してください.

• 必須 対象作業に着手する前にタスク追跡を初期化してください。タスクは一度に1つずつ状態を遷移させてください。

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

• 必須 タスク追跡の初期化後、対象作業／ソース作業の前に、必須のプロジェクト参照ドキュメントを読み、Reference docs read: ... と記載してください。

• 必須 常に lessons.md を含めてください。プロジェクト規約は一般的な既定値より優先されます。

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

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

プロンプト改善の締めくくりの指針

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

締めくくりのリマインダー

重要：必ず注意してください 作業を始める前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください。 重要：必ず注意してください 新しいコードを作成する前に、コードベースで類似パターンを3つ以上検索してください。 重要：必ず注意してください 対応する確信度が80％を超える場合は、すべての主張に file:line の根拠を添えてください。 重要：必ず注意してください 作業の品質を検証するための最終レビューの ToDo タスクを追加してください。 重要：必ず注意してください レビューループを実行してください：レビュー → 問題があれば修正 → 新しいサブエージェントによる再レビュー。問題が見つからないラウンドがあれば、レビューを終了します。 必須・重要：必ず注意してください 作業を始める前に、次のファイルを読んでください。

[TASK-PLANNING] 作業を開始する前に、タスクの範囲を分析し、タスク追跡を使って体系的に小さな ToDo タスクとサブタスクに分割してください。

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

---

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

Hookless Prompt Protocol Mirror（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

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

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクト参照ドキュメントを開いてください。この共通コンテキストとローカルドキュメントを利用できる場合は、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップ構成のほうが適しているかどうかも評価します
3. 確認（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、かつローカルプロトコルで明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します
   • 質問："どのワークフローを有効にしますか？"
   • 選択肢 1："[最適なワークフロー] を有効にする（推奨）"
   • 選択肢 2："カスタムワークフローを有効にする：[step1 → step2 → ...]"（1 行で理由を記載）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順に実行します
5. タスクを作成： ワークフローのすべてのステップについてタスク追跡を行います
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動します。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意力に関する原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、指示の順守が長いコンテキストウィンドウでも保たれるよう、最も重要な 3 つのルールを冒頭と末尾の両方に配置します。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストで意図を検証： テストでは、現在の挙動をなぞるだけでなく、ビジネスルール／不変条件を保護し、保護対象の意図が損なわれた場合に失敗するようにします。

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

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

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

1. 症状ではなく、失敗モード（推論／前提の誤り）を特定します。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を検証します。この失敗モードは 3 つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を 1 段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを除き、どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
5. 再発判定：「この注意書きがなければ、今後のセッションで再発するか？」いいえの場合は $learn を省略します。
6. 自動修正判定：「$code-review／$code-simplifier／$security／$lint で検出できるか？」はいの場合は、代わりにレビュー用スキルを改善します。
7. 両方の判定を通過した場合： $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成／更新し、各ステップの開始時と完了時に内容を同期してください。