plan-validate

Codex 互換性に関する注意事項：

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

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

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

必ず読むもの：

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

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

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

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

すべてのドキュメントを無差別に読まないでください。まず docs-index-reference.md を確認し、関連するファイルだけを開いてください。

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

クイックサマリー

目標： 実装に入る前に、前提に基づくすべての計画上の判断と、維持が不可欠なすべての動作について、ユーザーへの確認を必須にします。前提を検証し、問題を明らかにする重要な質問をユーザーに行うことで、明示されていない前提がひそかにコードに反映されるのを防ぎます。

概要：

• 目的： 重要な質問を行うインタビューで完成した計画を検証し、前提に基づくすべての判断と、維持が不可欠なすべての動作について、実装前にユーザーの確認を得ます。明示されていない前提がひそかにコードに反映されることはありません。
• 主な手順（順番どおりに実行）： フェーズ 0 で計画の種類を判定 → 計画のパスを解決（$ARGUMENTS / ## Plan Context / 質問） → mode と questions の範囲を厳格な制約として読み込む → ステップ 1 で plan.md とすべての phase-*.md を読み、判断・前提・リスク・トレードオフを特定する → ステップ 2 で 8 つのカテゴリ（アーキテクチャ、前提、トレードオフ、リスク、スコープ、新しい技術／ライブラリ、テスト仕様、維持）からトピックを抽出する → ステップ 3 で質問を作成する（それぞれに具体的な選択肢を 2～4 個提示し、暗黙の判断を明らかにする） → ステップ 4 でユーザーに直接質問してインタビューする（1 回につき最大 4 問） → ステップ 5 で回答を記録する → 実装／計画の修正／スキップを提案する。
• フェーズ 0 ですべての優先度を決定： 計画の種類（バグ修正／機能／移行／リファクタリング／その他）によって、質問するカテゴリを決定します。fix／bug／regression／broken／defect のキーワードが含まれる場合、維持に関する質問は必須となり、決してスキップしません。
• 出力は実際のインタビューであり、自分で回答するものではありません： ## Plan Context の questions の最小～最大数の範囲を守り、質問ごとに具体的な選択肢を 2～4 個提示します。維持に関する「Unsure」という回答は BLOCKED として扱い、$plan に誘導します。計画で新しい技術／パッケージを追加する場合は、その選択を受け入れる前に代替案を評価したかどうかを確認します。
• 結果は限定的に保存： plan.md に ## Validation Summary（確認済みの判断とアクション項目）のみを追加します。フェーズファイルは決して編集しません。最後にユーザーへ直接質問し、実装／計画の修正／スキップを提案します。

ワークフロー：

1. 計画の種類を判定 — 計画を分類（バグ修正／機能／移行／リファクタリング）して、質問カテゴリに重み付けします
2. 計画を読む — plan.md とフェーズファイルを解析して、判断・前提・リスクを特定します
3. トピックを抽出 — アーキテクチャ、前提、トレードオフ、リスク、スコープに関するキーワードを確認します
4. 質問を作成 — それぞれに具体的な選択肢を 2～4 個提示する質問を作成します
5. ユーザーにインタビュー — 設定された質問数の範囲に従って質問を提示します
6. 回答を記録 — plan.md に Validation Summary セクションを追加します

主なルール：

• ユーザーに直接質問することを必ず重視してください — ユーザーの代わりに自動で判断してはいけません。理由：前提に基づく選択はすべて、エージェントではなくユーザーが決定するものです。
• 実装に影響する実際の選択肢についてのみ質問してください — 判断を伴わない点について質問してはいけません。理由：不要な質問はインタビューの質問枠を消費し、信頼を損ないます。
• バグ修正の計画では、必ず維持に関する質問を行ってください（キーワード：fix、bug、regression、broken、defect）。理由：正しさを維持する不変条件が未検証のままだと、気付かれない回帰が発生します。
• plan.md の ## Validation Summary で結果を保存してください — フェーズファイルは決して変更しません。理由：フェーズファイルは計画の信頼できる情報源であり、検証は読み取り後に注記する工程です。

第一原則 — 変更しやすさ

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

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

• 変更コストを上げる「ベストプラクティス」は退けます（時期尚早な抽象化、 憶測に基づく汎用化、実装の詳細が漏れる間接化、効果のない形式主義など）。
• 調査結果では、実際の問題を明確に示します。密結合、隠れた状態、重複した知識、 不明確な意図、早すぎる段階で表面化した取り消せない決定。
• 変更しやすいシンプルな設計は、洗練されていても変更しにくい設計に勝ります。

以下の個別のルール、パターン、チェックリストを適用する前に、必ずこの視点で評価してください。下位のルールによって変更コストが上がる場合は、この原則を優先します。

---

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

質問を生成する前に計画の種類を分類します。これによって質問カテゴリの重み付けが決まります。

計画の種類	判定基準	必須の追加カテゴリ
Bugfix	タイトル／フロントマターに fix、bug、regression、broken、defect がある	Preservation（ブロッキング）
Feature	修正を示すキーワードがなく、新しい機能を追加する	Architecture、Assumptions、Test Specs
Migration	スキーマ変更、EF マイグレーション、データ移行	Risks、Preservation、Scope
Refactor	動作を変更せず、構造を変更または整理する	Preservation、Tradeoffs
Other	上記のいずれにも該当しない	Architecture、Scope

Bugfix の判定は必須です。タイトルまたはフロントマターに fix／bug／regression／broken／defect のキーワードがある場合、Preservation の質問を省略してはいけません。

計画の特定

1. $ARGUMENTS が指定されている → そのパスを使用します
2. ## Plan Context セクションを確認する → 有効な計画のパスを使用します
3. 計画が見つからない → パスを指定するか、先に $plan を実行するようユーザーに尋ねます

設定（注入されたコンテキストから取得）

## Plan Context セクションを確認します。

• mode — auto/prompt/off の動作
• questions — 3-8 のような範囲（最小数-最大数）

これらを厳守すべき制約として扱います。

ワークフロー

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

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

• plan.md — 概要とフェーズの一覧
• phase-*.md — すべてのフェーズファイル
• 確認項目：判断が必要な点、前提、リスク、トレードオフ

ステップ 2：質問のトピックを抽出する

カテゴリ	キーワード
Architecture	approach、pattern、design、structure、database、API
Assumptions	assume、expect、should、will、must、default
Tradeoffs	tradeoff、vs、alternative、option、choice、either/or
Risks	risk、might、could fail、dependency、blocker、concern
Scope	phase、MVP、future、out of scope、nice to have
New Tech/Lib	install、add package、new dependency、npm install、dotnet add、なじみのないフレームワーク名
Test Specs	TC-、test case、coverage、TDD、test specification
Preservation	タイトル／フロントマターの bugfix キーワードにより自動的に対象となる — Preservation Inventory セクションを調べる

ステップ 3：質問を生成する

形式ルール：

• 質問ごとに具体的な選択肢を 2〜4 個用意する
• 推奨する選択肢には末尾に「(Recommended)」を付ける
• 「Other」選択肢は自動で追加されます。追加しないでください
• 暗黙の決定事項を明確にする

例：

Category: Architecture
Question: "How should validation results be persisted?"
Options:
1. Save to plan.md frontmatter (Recommended) — updates existing plan
2. Create validation-answers.md — separate answers file
3. Don't persist — ephemeral validation only

Category: Assumptions
Question: "Plan assumes API rate limiting not needed. Correct?"
Options:
1. Yes, not needed for MVP
2. No, add basic rate limiting now (Recommended)
3. Defer to Phase 2

Category: Preservation (MANDATORY when title/frontmatter: fix, bug, regression, broken, defect)
Question: "List 2-3 inputs where CURRENT code is correct. Will fix change behavior on any?"
Options (multi-select):
1. "Current code correct on: {input A}. Fix preserves behavior." (Recommended)
2. "Current code correct on: {input B}. Fix CHANGES behavior because: {justification}"
3. "Current code has NO preserved-correctness inputs — every input was broken" (rare; requires confirmation)
4. "Unsure — need to investigate" (STOP: run $plan preservation analysis)

フォローアップルール：

• 選択肢 2 が選ばれた場合 → plan.md の Preservation Inventory で、新しい動作が意図されたものであることを示す Preservation TC を必ず引用する
• 選択肢 4 が選ばれた場合 → BLOCKED ステータスを返し、続行する前に $plan を推奨する
• 選択肢 3 が選ばれた場合 → ユーザーに直接フォローアップを質問する：「確認：現在のコードに保持対象の不変条件はありませんか？［はい、すべての入力で破損しています／いいえ、見落としがありました — 再調査してください］」

ステップ 4：ユーザーに質問する

ユーザーに直接質問してください。決して省略したり、自動で回答したりしないでください。

ルール：

• ## Plan Context の質問数を使用する → Validation: mode=X, questions=MIN-MAX
• 関連する質問をまとめる（ツール呼び出しごとに最大 4 問）
• 焦点：前提、リスク、トレードオフ、アーキテクチャ
• 必ず注意：計画に新しい技術やパッケージが含まれる場合は、必ず次のように質問する：「計画では {lib} を使用します。代替案を評価しましたか？この選択を確認するか、さらに調査してください。」

ステップ 5：回答を記録する

plan.md に ## Validation Summary を追加します。

## Validation Summary

**Validated:** {date}
**Questions asked:** {count}

### Confirmed Decisions

- {decision 1}: {user choice}
- {decision 2}: {user choice}

### Action Items

- [ ] {changes needed based on answers}

フェーズファイルは決して変更しないでください。更新が必要な内容だけを記録してください。

出力

検証後：

• 質問した数
• 確認済みの主な決定事項
• 計画の修正対象として指摘された項目
• 推奨事項：実装に進むか、先に計画を修正するか

次のステップ

必ず注意 — 例外なし：完了後、ユーザーに直接質問して、次の選択肢を提示してください。

• 「$feature-implement (Recommended)」 — 検証済みの計画で実装を開始する
• 「$refine」 — 先に計画の PBI を改善する必要がある場合
• 「スキップして手動で続行」 — ユーザーが決定する

---

[BLOCKING] 必ず注意：ユーザーに直接質問して、ユーザーへのインタビューを実施してください。質問を 1 つ以上せずに完了すると、違反になります。

[IMPORTANT] 着手前に、タスク管理を使用してすべての作業を小さなタスクに分割してください。各ファイルを読むタスクも含めます。単純なタスクの場合、AI は必ず注意して、スキップするかどうかをユーザーに質問してください。

外部メモリ： 複雑または長時間にわたる作業では、調査結果と成果を plans/reports/ に記録してください。これにより、コンテキストの喪失を防げます。

エビデンスゲート： 必ず注意：すべての主張には file:line による証拠、または確信度（％）を含む追跡可能な証拠が必要です（80% 超なら実行、80% 未満なら先に検証）。

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

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

ブロック解除条件： 現在のタスクリストが完了し、子フェーズが作成され、ネストされている場合は親にリンクされ、最初の子タスクが in_progress に設定されていること。 タスク追跡と外部レポートの永続化 — 実行前にこれをセットアップし、その後、対象やソースに取り掛かる前にプロジェクト参照ドキュメントを事前取得してください。

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

作業開始の条件: タスクの内訳を作成済みであること。計画またはレビューの作業ではレポートのパスを宣言済みであること。次の調査結果を得る前に最初の調査結果を記録済みであること。

批判的思考の姿勢 — 批判的思考と段階的思考を実践してください。すべての主張には追跡可能な根拠を示し、確信度が 80% を超えてから行動してください。 幻覚の防止: 推測を事実として提示しないでください。すべての主張について出典を示し、不確実性は率直に認め、自分の出力に誤りがないか確認し、独立した情報源と照合し、自分の確信度にも懐疑的でいてください。根拠のない確信は、あらゆる幻覚の根源です。

段階的思考プロトコル — 複雑または曖昧な作業に対して、構造化された複数段階の推論を行います。一度の推論では安全に対応できない計画、レビュー、デバッグ、アイデアの洗練で使用してください。

使用する場面: 複雑な問題の分解・修正が必要な適応型計画・軌道修正を伴う分析・範囲が不明確または発展途上の作業・複数段階の解決策・仮説に基づくデバッグ・複数の領域にまたがるトレードオフの評価。

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

1. Thought N/M: [aspect] — 1 つの思考につき 1 つの側面を扱い、前提や不確実性を述べる
2. Thought N/M [REVISION of Thought K]: ... — 以前の推論が無効になった場合に使用し、Original / Why revised / Impact を述べる
3. Thought N/M [BRANCH A from Thought K]: ... — 別の可能性を検討し、判断の根拠を示して結論に収束させる
4. Thought N/M [HYPOTHESIS]: ... に続けて [VERIFICATION]: ... — 行動する前に検証する
5. Thought N/N [FINAL] — 検証済みで、重要な側面をすべて検討し、確信度が 80% を超えている場合にのみ使用する

必須の締めくくり: 確信度（%）を明記 · 前提を列挙 · 未解決の疑問を明らかにする · 具体的な次の行動を示す。

停止条件: 重要な判断の確信度が 80% 未満の場合は、ユーザーに直接確認してください。同じ思考を 3 回以上修正する場合は、問題を捉え直してください。分岐が 3 つを超える場合は、サブタスクに分割してください。

暗黙モード: マーカーの追加で応答が煩雑になる場合は、方法論を内部で適用してください（推論によって正確さが高まる定型作業）。

詳細: 実例（API 設計、デバッグ、アーキテクチャ）、高度な技法（段階的な改善、仮説検証、収束）、メタ戦略（不確実性への対処、修正の連鎖）については、$sequential-thinking スキル（.claude/skills/sequential-thinking/SKILL.md）を参照してください。 プロジェクト参照ドキュメントのゲート — タスク追跡の初期設定後、対象ファイルやソースファイルの読み込み、grep、編集、分析を始める前に実行してください。プロジェクトのドキュメントは、汎用的なフレームワークの前提よりも優先されます。

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

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

まずコードを理解する — 厳格なゲート：既存のコードを読むまでは、記述、計画、修正をしてはいけません。

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

次の項目を完了するまで作業は禁止： - [ ] 対象ファイルを読了 - [ ] 3つ以上のパターンを grep - [ ] グラフをトレース（graph.db がある場合）- [ ] 根拠を示して前提を検証

計画の品質 — 計画のすべてのフェーズに、必ずテスト仕様を含めてください。

1. 各フェーズファイルに、TC-{FEATURE}-{NNN} ID を使った ## Test Specifications セクションを追加します
2. すべての機能要件を1つ以上の TC に対応付けます（または根拠を添えて明示的に TBD とします）
3. TC ID は TC-{FEATURE}-{NNN} 形式に従います。内容全体ではなく、ID を参照してください
4. 新しいワークフローステップを開始する前に、現在のタスクリストを呼び出し、フェーズファイルを読み直します
5. コンテキストの圧縮時には、まず現在のタスクリストを呼び出します。重複するタスクを作成してはいけません
6. 完了とする前に、フェーズごとに TC の充足を検証します（根拠は file:line 形式とし、TBD は不可です）

モード： TDD 優先 → 既存の TC を Evidence: TBD で参照します。実装優先 → TBD を使用し、後から $spec [mode=tests] で補完します。 サービス間チェック — マイクロサービス／イベント駆動型：調査、計画、仕様、機能ドキュメントを完了とする前に必ず実施してください。下流のコンシューマーが漏れると、気づかれないままリグレッションが発生します。

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

タッチポイントごとに： 所有サービス · メッセージ名 · コンシューマー · リスク（NONE／ADDITIVE／BREAKING）。

以下が完了するまでブロック： プロデューサーをスキャン · コンシューマーをスキャン · Saga を確認 · コントラクトをレビュー · 破壊的変更のリスクにフラグを立てる

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

コンテキストが変化したらファイルを読み直してください。 コンテキストの圧縮、再開、または長時間にわたる作業によって記憶が古くなることがあります。作業に取りかかる前に、現在のファイルを確認してください。 生成した内容をソースの根拠と照合してください。 AI は API、名前、主張、ドキュメントの事実を幻覚することがあります。記載または参照する前に、該当するソースを確認してください。 削除または名前変更の前に、下流の参照を確認してください。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元が古くなることがあります。まず参照箇所を把握してください。 編集後は影響の連鎖を最後までたどってください。 定義を変更すると、派生出力やコンシューマーへの影響を見落とすことがあります。完了を宣言する前に、影響を受ける連鎖を確認してください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 チェックが 1 つ成功しても、すべてのチェックが成功したとは限りません。変更の影響を受けるすべての出力面を検証してください。 既存の値は意図的なものと考え、変更または不具合として指摘する前に、なぜそうなっているのかを確認してください。 定数、上限値、フラグ、しきい値、文言、パターンを変更または報告する前に、周辺のコンテキストと履歴、呼び出し元の処理順序、同じ規約に従う 2 つ以上の兄弟呼び出し箇所を確認してください。「何を」だけを記載し「なぜ」を記載していないドキュメントは、根拠が欠けているのであって、ガードが欠けている証拠ではありません。 曖昧さは行動する前に明らかにし、黙って解釈を選ばないでください。 複数の妥当な解釈がある場合は、明示的に質問するか、リスクを添えて前提を示してください。 中間状態ではなく、システムが担保する結果を検証してください。 非同期処理を検証するときは、最終的なビジネス状態を確認してください。共有インフラが管理し、同時実行中の任意のプロセスが書き込める配信／再試行の記録状態を検証してはいけません。このようなチェックは単独実行では成功しますが、同じインフラを使う別の処理があると失敗することがあります。 共有ガイダンスは、対象となる役割に関連する内容にしてください。 共通ガイダンスは、それを受け取るすべてのスキルまたはエージェントに役立つものである必要があります。コード固有の義務は、コード固有のプロトコルにのみ記載してください。

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

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

重要：必ず注意してください 各フェーズの TC ID を含む ## Test Specifications を追加してください。新しいタスクを作成する前に、現在のタスクリストを呼び出してください。

重要：必ず注意してください マイクロサービス／イベント駆動型では、タスクの範囲内でプロデューサー、コンシューマー、Saga、コントラクトをスキャンしてください。タッチポイントごとに：所有者 · メッセージ · コンシューマー · リスク（NONE／ADDITIVE／BREAKING）。コンシューマーの漏れは、気づかれないリグレッションにつながります。 必ず注意 批判的思考と順を追った思考を適用してください。すべての主張には、適切な根拠を追跡できる形で示してください（リポジトリ／コードに関する主張には file:line、調査・製品・コンテンツ・ドキュメントに関する主張にはソース URL または成果物のセクション）。行動に移す際は確信度を 80％超とし、60％未満の場合は推奨しないでください。ハルシネーション防止：推測を事実として提示せず、不確実な点は率直に認め、独立して照合し、自分の確信度にも懐疑的でいてください。

必ず注意 順を追った思考を適用してください。複数ステップでは Thought N/M、REVISION／BRANCH／HYPOTHESIS のマーカーを使い、確信度を明記してください。$sequential-thinking スキルを参照してください。

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

• 必須 対象作業に取りかかる前に、タスク管理を開始してください。タスクは一度に 1 つずつ進行させてください。

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

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

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

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

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

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

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

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

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

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

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

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

重要・必ず注意 目標： 前提に依存するすべての計画上の判断と、保持が重要なすべての動作について、実装前にユーザーの明示的な確認を得てください。重要な質問でユーザーに聞き取りを行い、前提を検証して問題を明らかにすることで、明示されていない前提がコードに気づかれないまま入り込むのを防ぎます。

適用中のプロトコル（このスキルが含む SYNC／共有ブロックの簡潔な要約）：

• ネストされたタスクの作成： 子スキルでも、ユーザーに見えるフェーズタスクを作成してください。ネストされた場合は親タスクにリンクしてください。
• タスク追跡と外部レポート： まずタスクの内訳を作成し、調査結果を plans/reports/ に逐次保存してください。
• 批判的思考： 重要・必ず注意 批判的かつ順序立てて考え、根拠を示してください。行動に移すのは確信度が80%を超えてからです。
• 順序立てた思考： REVISION／BRANCH／HYPOTHESIS マーカーと、最後の確信度を含む、構造化された複数段階の Thought N/M を使用してください。
• プロジェクト参照ドキュメント： 対象作業に着手する前に、必須のプロジェクト参照ドキュメントを読み込んでください。必ず lessons.md も含めてください。
• まずコードを理解する： 重要・必ず注意 変更を加える前に、コードを読み、3つ以上のパターンを grep で検索してください。
• 計画の品質： 各フェーズに TC-{FEATURE}-{NNN} 形式の ID を使用した ## Test Specifications を含めてください。
• サービス横断チェック： プロデューサー、コンシューマー、サガ、コントラクトを調査し、破壊的変更のリスクに注意を促してください。
• AI の誤り防止： 生成した内容を根拠と照合し、下流の参照をたどり、影響を受けるすべての成果物を検証してください。コンテキストを失った後は再読し、曖昧さがあれば提示してください。 重要：必ず注意してください 主要な手順は順番どおりに実行してください — Phase 0 プランの種類を検出 → プランのパスを解決 → mode と questions の範囲を読み込む → Step 1 plan.md とすべての phase-*.md を読む（決定事項／前提／リスク／トレードオフに印を付ける） → Step 2 トピックを抽出する（8 カテゴリー） → Step 3 質問を作成する（各質問につき選択肢 2〜4 個） → Step 4 ユーザーに直接質問してヒアリングする（1 回につき最大 4 問） → Step 5 回答を記録する → 実装／洗練／スキップを提案する — 理由：パイプラインそのものが作業です。記憶を頼りに手順をまとめたり、スキップしたりしてはいけません

重要：必ず注意してください ユーザーに直接質問して、決定事項をユーザーと検証してください — 自動的に決定したり、自分で回答したりしてはいけません。質問が 1 件もないまま完了するのは、プロトコル違反です — 理由：前提を伴う選択の決定権はすべてエージェントではなくユーザーにあります 重要：必ず注意してください 質問を作成する前に、必ずプランの種類を検出してください（Phase 0）。バグ修正を示すキーワード（fix、bug、regression、broken、defect）があれば、Preservation の質問はスキップできない必須項目です — 理由：検出結果によって、該当するカテゴリーと Preservation のゲートが決まります 重要：必ず注意してください phase ファイルは絶対に変更しないでください。結果を保存するには、plan.md に ## Validation Summary（確認済みの決定事項＋アクション項目）だけを追加してください — 理由：phase ファイルはプランの信頼できる情報源であり、検証は読み取り後に注釈を加える作業です

• 必須・重要：必ず注意してください 開始前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください（読み込むファイルごとにタスクを作成することを含む）。コンテキストを失った場合は、まず現在のタスクリストを呼び出し、タスクを重複させないでください — 理由：コンパクション後に計画を立て直すのではなく、既存のタスクを再開してください
• 必須・重要：必ず注意してください ## Plan Context の questions の最小〜最大範囲と mode を、厳守すべき制約として遵守してください。質問ごとに具体的な選択肢を 2〜4 個提示し、最小数を下回らないでください — 理由：ヒアリングの上限数は設定されているものであり、その場で決めるものではありません
• 必須・重要：必ず注意してください Preservation の回答が「Unsure」の場合は BLOCKED として扱い、BLOCKED ステータスを返し、実装の前に $plan の Preservation 分析へ誘導してください — 理由：正しさを保つべき不変条件が検証されていないと、気付かれないままリグレッションが起きるリスクがあります
• 必須・重要：必ず注意してください プランに新しい技術やパッケージが導入される場合は、その選択を受け入れる前に、代替案を評価したかどうかを確認してください — 理由：評価されていない依存関係の選択は、将来の変更コストを高めます
• 必須・重要：必ず注意してください すべての主張について、確信度（%）を添えて file:line の根拠または追跡可能な証拠を示してください（80% 超なら実行、80% 未満なら先に検証）。推測を事実として提示するのではなく、不確実であることを認めてください — 理由：憶測は誤った検証質問につながります
• 必須・重要：必ず注意してください 質問の作成前に、既存のパターンを 3 つ以上検索し、プランと phase ファイルを読み込んでください — 汎用的なフレームワークの既定値より、コードベース内の慣習を優先してください — 理由：実際のコードに基づく質問は、存在しない決定事項ではなく、実際に決めるべきことを明らかにします
• 必須・重要：必ず注意してください 以下のルールを適用する前に、変更容易性の観点から検討してください — 将来の変更コストを高める決定（密結合、隠れた状態、知識の重複、意図の不明確さ、早すぎる不可逆な選択）に印を付けてください
• 必須・重要：必ず注意してください 作業の品質を確認する最終レビューのタスクを追加してください

正当化の抑止：

回避策	反論
「計画は単純なので、検証は省略する」	単純な計画にも暗黙の判断が含まれます。それでも適用してください。
「答えはもう分かっている」	ユーザーの回答を証拠として示してください。回答がなければ検証していません。
「今回、保全は関係ない」	タイトルに fix／bug／regression／broken／defect が含まれる場合は→必ず適用されます。
「フェーズ 0 は不要」	検出によって保全ゲートが決まります。絶対に省略しないでください。
「質問は少しだけにする」	Plan Context の questions 範囲を使用してください。最小値を下回らないでください。
「ユーザーの代わりに自分で回答する」	ユーザーに直接尋ねることが必須です。自分で回答すると検証になりません。
「新しいライブラリを使っても問題ない」	受け入れる前に、代替案を評価したかどうかを確認してください。
「フェーズファイルをその場で編集する」	絶対にしないでください。plan.md に ## Validation Summary だけを追加してください。

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

重要：必ず注意すること まず計画タイプを検出してください（フェーズ 0）。バグ修正を示すキーワードがある場合、保全は必須です。 重要：必ず注意すること ユーザーに直接尋ねて検証してください。絶対に自動で判断しないでください。 重要：必ず注意すること フェーズファイルは絶対に変更しないでください。plan.md に ## Validation Summary だけを追加してください。

---

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

Hookless Prompt Protocol Mirror (Auto-Synced)

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

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

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

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

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

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

SYNC:ai-sdd-artifact-contract

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

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

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

---

SYNC:ai-sdd-artifact-contract:reminder

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

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

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

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

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

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

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