test

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 ツールが利用できない場合は、同じステータス遷移を反映した、同等のステップごとの計画トラッカーを作成し、維持してください。

クイックサマリー

目標： tester サブエージェントを使ってローカルでテストを実行し、サマリーレポートを分析することで、正確な読み取り専用の合否判定を行います。正確な件数、失敗したテスト名、レポートのパス、Goal Contract の証拠を提示し、修正を一切適用せずにユーザーが実際のテスト状況を把握できるようにします。

概要：

• 目的： 修正を一切適用せずに、正確な合否判定、正確な件数、失敗したテスト名、レポートのパスを提示し、ユーザーに実際のテスト状況を伝えます。
• 主な手順（順番どおりに実行）： (1) 委任 — 引数で指定されたテスト範囲を使って tester サブエージェントを起動します。テストコマンドを直接実行してはいけません。(2) 分析 — サブエージェントのサマリーレポートを確認し、失敗とその傾向を特定します。(3) 報告 — 合格／失敗の件数をまとめ、失敗したテストを明示し、レポートのパスを記載します。(4) 目標の証拠 — 有効な Goal Contract を特定し、検証の証拠を追記して、Goal Satisfaction マトリクスを更新します。
• 読み取り専用です。報告の時点で停止し、修正の実装を始めてはいけません。修正は $fix の担当であり、報告に修正作業を混在させると実際のテスト状況が隠れてしまうためです。
• 実行後、検証の証拠（コマンド、正確な件数、レポートのパス）を目標ファイルの Iteration Log に追記し、Goal Satisfaction マトリクスを更新します。有効な目標がない場合は、No active goal — evidence reported inline only. と記録します。機密性の高いフィクスチャーデータを目標ファイルにコピーしてはいけません。目標ファイルは永続的な合否記録であり、機密情報の保管場所ではないためです。

ワークフロー：

1. 委任 — 引数で指定されたテスト範囲を使って tester サブエージェントを起動します
2. 分析 — テスト結果を確認し、失敗とその傾向を特定します
3. 報告 — 合格／失敗の件数をまとめ、失敗したテストを明示します

主なルール：

• 読み取り専用です。修正は実装せず、結果のみを報告します
• 作業中に、カタログから関連するスキルを有効化します
• テストコマンドを直接実行せず、必ず tester サブエージェントを使います
• 断続的な失敗（ある実行では赤、別の実行では緑）は、まだプロダクトの欠陥ではありません。欠陥として報告する前に、同じ判定基準に従って $integration-test-verify が使う手順で判断します。(a) 非現実的なシナリオ／アクターのペースが過度に圧縮されている、(b) テストハーネスのトポロジーによる増幅（共有インフラ、ファンアウトするコンシューマー、スイートの並列実行、コールドスタート）、(c) 実際のプロダクトの競合状態、のいずれかを確認します。証拠を添えて判定を報告するか、失敗を未判定として報告します。1 回の赤判定だけを根拠に、プロダクトの欠陥として報告してはいけません

懐疑的な姿勢を保ち、批判的思考と順序立てた思考を用いてください。すべての主張に、追跡可能な証拠と確信度（Idea は 80% 超）を示す必要があります。

tester サブエージェントを使ってローカルでテストを実行し、サマリーレポートを分析します。

重要： 結果の報告時点で停止し、実装を始めてはいけません。 重要： スキルカタログを分析し、作業中にタスクに必要なスキルを有効化してください。

Goal Contract の証拠（テスト実行後）： goal-contract-satisfaction-loop プロトコルに従って、有効な Goal Contract を特定します（有効なプラン goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md）。存在する場合は、実行で検証した保存済み成功基準に対応づけて、検証の証拠（テストコマンド、正確な合格／失敗件数、レポートのパス）を目標ファイルの Iteration Log に追記し、該当する基準の Goal Satisfaction マトリクスの行を更新します（PASS／FAIL／BLOCKED）。有効な目標がない場合は、No active goal — evidence reported inline only. と記録します。機密性の高いフィクスチャーデータをそのまま目標ファイルにコピーしてはいけません。

---

第一原則 — 変更しやすさ

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

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

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

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

---

ワークフローの推奨

必須・重要・厳守 — 例外なし： すでにワークフローを利用していない場合、必ずユーザーに直接確認してください。タスクの複雑さを判断したり、「省略できるほど簡単だ」と決めつけたりしないでください。ワークフローを利用するかどうかを決めるのは、あなたではなくユーザーです。

1. testing ワークフローを有効化する（推奨） — テストする
2. $test を直接実行する — このスキルを単独で実行する

---

次のステップ

このスキルの完了後は、必ず、重要事項として厳守し、例外なく、ユーザーに直接確認して、次の選択肢を提示してください。タスクが「簡単」または「明白」に見えるからといって省略しないでください。決めるのはユーザーです。

• 「$docs-update（推奨）」 — テスト合格後にドキュメントを更新する
• 「$fix」 — テストで修正が必要な失敗が見つかった場合
• 「$watzup」 — セッションをまとめ、変更内容をすべて確認する
• 「スキップして手動で続行」 — ユーザーが決定します

[IMPORTANT] 作業を始める前に、ファイルを読む作業も含め、すべての作業を細かいタスクに分割してタスク管理に登録してください。長いファイルによるコンテキストの喪失を防げます。簡単な作業であっても、スキップするかどうかを必ずユーザーに確認してください。

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関係、サービス間同期（タスクにビジネスエンティティ／モデルが関係する場合に読む）

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

エビデンスゲート： 必須・重要・厳守 — すべての主張、指摘、推奨には、file:line による証拠、または確信度（行動するには 80% 超、80% 以下は事前確認が必要）を示した追跡可能な根拠が必要です。

批判的思考の姿勢 — 批判的思考と順序立てた思考を適用してください。あらゆる主張には追跡可能な根拠が必要です。行動するには確信度が 80% を超えている必要があります。 ハルシネーション防止： 推測を事実として提示してはいけません。すべての主張の根拠を示し、不確実性は率直に認め、出力に誤りがないか自分で確認し、独立して相互参照し、自身の確信度にも懐疑的でいてください。根拠のない確信こそ、あらゆるハルシネーションの根源です。

エビデンスに基づく推論 — 推測は禁止です。あらゆる主張には根拠が必要です。

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

次の項目が完了するまで作業は停止： - [ ] 証拠となるファイルパス（file:line） - [ ] grep 検索を実施済み - [ ] 類似パターンを 3 件以上確認済み - [ ] 確信度を明示済み

根拠なしでは禁止： 「明らかに」「私はこう思います」「〜すべきです」「おそらく」「これが原因です」 未完了の場合 → 次を出力する："Insufficient evidence. Verified: [...]. Not verified: [...]." ソース／テストの不一致チェック。 コーディング、修正、デバッグ、調査、テスト、レビューの作業では、ソースの動作が変わったとき、影響を受ける単体テスト／統合テスト／E2E テストを確認し、意図した動作に合わせてテストを変更するべきか、それともソースの変更が意図しないバグなのかを、証拠に基づいて判断します。マイグレーションコードのテストは作成しないでください。スキーマ／データのマイグレーションは一度限りの実行パスであり、アプリケーションの中核ロジックではありません。

テスト失敗の責任判定 — テストが失敗した場合（または失敗をデバッグ／修正している場合）、行うべきことは、_ソースコードとテストコードのどちらに問題があるか_を判断することです。テストスイートを再び成功させることより、正しい判定を下すことが重要です。すべてのデバッグ／修正／テストスキルに同じように適用されます。

1. どちらにも手を加える前に暫定判定を下します。 確認できた証拠を SOURCE-WRONG、TEST-WRONG、TEST-NOT-OPTIMAL、ENVIRONMENT-BLOCKED、AMBIGUOUS のいずれかに分類してから、$debug-investigate を実行し、編集前に末端から始点までたどります。テストスイートを再び成功させることが目標ではありません。
2. 仕様とソースの両方に照らして検証します。 動作を対象とする上位 Feature Spec（例：docs/specs/** — §3 AC／§4 BR／§5 invariants／§8 TCs）がある場合、意図された動作を判断する基準としてそれに従い、製品ソースと失敗したテストの両方を照合します。仕様がない場合は、文書化された意図／受け入れ基準／呼び出し元の契約を基準とします。この証拠に基づいて、SOURCE と TEST のどちらに問題があるかを判断します。
3. 問題のある側を特定し、その根本原因を修正します。
   • SOURCE-WRONG — 製品コードが仕様の意図する動作または明確な不変条件に違反している → 担当レイヤーでソースを修正し、問題を検出したテストは維持または強化します。
   • TEST-WRONG — テストの古い、または誤ったアサーション、セットアップ、期待値が意図された動作と矛盾している → テストを根本から修正します。テストを成功させるためにアサーションを弱めたり、スキップを追加したり、タイムアウトを緩和したりすることは絶対にしないでください。
   • TEST-NOT-OPTIMAL — 意図された動作は妥当だが、テストの接続点、タイミング、アサーションのシグナルが不安定である → 不変条件を弱めずにテストを改善します。
   • ENVIRONMENT-BLOCKED — インフラストラクチャまたは外部状態により、ソースとテストのどちらに問題があるか判断できない → 診断情報を保持し、環境が正常になるまで変更を中断します。
   • AMBIGUOUS — 証拠または意図された動作から、どちらに問題があるか安全に判断できない → 編集する前にユーザーまたは正式な担当者に確認します。
   • 壊れたソースに合わせてテストを変更してはならず、壊れたテストに合わせてソースを変更してもいけません。（マイグレーションコードは除きます。スキーマ／データのマイグレーションは一度限りの実行パスであり、アプリケーションの中核ロジックではありません。）
4. 意図された動作が不明確な場合は、ユーザーに確認します。 動作を対象とする仕様がない場合、仕様に記述がない場合、またはどちらが正しいか仕様が曖昧な場合は、編集する前に作業を止め、ユーザーに直接確認するか、正式な仕様の担当者に相談します。テストを通すためだけに、黙ってソースまたはテストのどちらかを選んではいけません。

現在どちらが成功するかではなく、意図された動作に合わせます。テストが成功していても、そこにまさにバグが潜んでいることがあります。 実環境との忠実性ゲート — インテグレーションテスト／E2E テスト／システムテストの作成、レビュー、修正時には必ず適用してください。

テストは、システムが本番環境で実際に遭遇し得る状況を再現することで信頼を得ます。現実には決して起こり得ないシナリオは、成功しても何も証明せず、失敗すれば何時間もの時間を無駄にします。

1. セットアップを書く前に、忠実性について確認します。 「この一連の操作、タイミング、データは、本番環境で実際に発生し得るか？」 発生し得ない場合、テストの仕様が誤っています。修正するのはシナリオであり、アサーションではありません。
2. アクターの手順間に現実的な間隔を設けます。 本番環境で数秒、数分、数時間の間隔がある、別々のアクター操作を、同じミリ秒内に連続して実行してはいけません。間隔を圧縮すると、システムが耐えるよう設計されていない競合状態を人工的に生み出し、それを製品の不具合として報告することになります。
3. 根拠のない固定時間の待機ではなく、実際のシグナルを待ちます。 前の手順が完了したことを示す観測可能なもの（永続化された状態の変化、監査／バージョンの記録、キュー／ワーカーのアイドルマーカー、完了イベントなど）を見つけ、短い安定確認期間にわたって変化がなくなるまでポーリングします。固定時間の待機を使うのは、観測可能なものが存在しない場合に限り、その旨をコメントに記載します。
4. バリアは ARRANGE に置き、ASSERT には置きません。 前提条件を満たすまで待つのは忠実性のためです。アサーションのタイムアウトを延ばす、比較条件を緩める、失敗するアサーションの周囲に再試行を追加する、テストをスキップする、といった対応は問題の隠蔽です。テストを無理に成功させるために、こうした対応をしてはいけません。
5. テストハーネスによって増幅された問題と、実際に起こる問題を区別します。 テストの構成（共有インフラ、ファンアウトするコンシューマー、並列スイート、コールドスタート）によって、本番環境ではまれな競合がローカル環境で頻発することがあります。製品の不具合として報告する前に、そのトリガーが本番環境にも存在するか、発生する可能性はどの程度かを明記します。
6. 保護する不変条件を維持します。 忠実性を高めることで、テストが保護する範囲を狭めてはいけません。現実的なシナリオではルールを検証できなくなる場合、そのルールには、アサーションを弱めるのではなく、別の現実的なシナリオが必要です。
7. 意図的に不可能な状態をテストすることは認められますが、必ずその旨を明記します。 破損の修復、移行、フェイルセーフのテストでは、本番環境では到達しないはずの状態を意図的に作り出します。その状態に到達し得る理由（上流のバグ、不完全な書き込み、レガシーデータなど）をコメントに記載し、非現実的なセットアップと混同されないようにします。 AI のミス防止 — あらゆるタスクで避けるべき失敗パターン：

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

重要・必ず注意 すべての主張について、file:line 形式の根拠を示してください（確信度が80％を超える場合に実行）。証拠なしに推測してはいけません。

必ず注意 批判的かつ順序立てて考えてください。すべての主張に、適切に追跡した根拠が必要です（リポジトリやコードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または成果物のセクションを示してください）。実行する際の確信度は80％超とし、60％未満の場合は推奨してはいけません。幻覚防止：推測を事実として提示せず、不確実な点は率直に認め、独立した情報源で相互参照し、自身の確信度にも懐疑的でいてください。

必ず注意 AI のミス防止を適用してください。生成した内容を根拠と照合し、削除または名前変更の前に下流の参照をたどり、影響を受けるすべての出力を検証し、コンテキストを失った後はファイルを読み直し、作業に取りかかる前に曖昧さを明らかにしてください。

• 必須 作業の前に、有効な目標契約を解決してください（有効なプラン goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → 現在の依頼から作成）。編集の前に、保存済みの成功基準を読んでください。
• 必須 実行後に反復ごとの根拠を追記してください。PASS を報告する前に、目標達成マトリクス（PASS／FAIL／BLOCKED）を出力してください。検証済みの FAIL があればループし、進展がない状態やブロッカーが繰り返し発生した場合はエスカレーションしてください。目標ファイルに秘密情報を保存してはいけません。

Prompt-Enhance の締めくくりアンカー

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

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

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

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

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

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

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

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

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

最後に確認すること

重要：必ず注意する目標： 正確な読み取り専用の合否判定を提示してください。tester サブエージェント経由でテストを実行し、そのサマリーレポートを分析します。正確な件数、失敗したテスト名、レポートのパス、Goal Contract の根拠を提示し、修正を一切適用せずに、ユーザーが実際のテスト状況を把握できるようにしてください。

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

• 批判的思考： 批判的かつ段階的な思考を常に適用し、根拠をたどって証明し、確信度を 80% 超にしてください。
• 証拠： 主張ごとに必ず file:line を示してください。証拠なしに推測してはなりません。
• ソースとテストの乖離： ソースが変更された場合は、テストとソースのどちらが誤っているかを証拠に基づいて判断してください。決めつけてはなりません。
• 現実世界との整合性： 本番環境では決して発生し得ないシナリオは、成功を証明せず、失敗の責任を製品に帰属させる根拠にもなりません。断続的な失敗を製品の欠陥と判断する前に、テストハーネスによる増幅と現実に起こり得る事象を区別してください。
• AI の誤り防止： 生成した内容を証拠と照合して検証し、後続の参照をたどり、影響を受けるすべての出力を検証してください。コンテキストが失われた後は読み直し、曖昧さがあれば提示してください。 必須・重要・要注意 読み取り専用です。テストを実行し、成功／失敗件数、失敗したテスト名、レポートのパスを報告してください。ここでは修正を実装せず、報告した時点で停止してください。理由：修正は $fix の役割です。両方を混ぜると、テストの実際の状態がわからなくなります。 必須・重要・要注意 テストは必ず tester サブエージェント経由で実行してください。テストコマンドを直接実行してはいけません。理由：サブエージェントが実行を分離し、このスキルが分析するための正式な要約レポートを生成します。 必須・重要・要注意 実行後に有効な Goal Contract を確認してください。検証の証拠（テストコマンド、正確な成功／失敗件数、レポートのパス）をゴールファイルの Iteration Log に追記し、Goal Satisfaction マトリクスを更新してください。有効なゴールがない場合は No active goal — evidence reported inline only. と記録してください。生の機密フィクスチャデータをゴールファイルにコピーしてはいけません。理由：ゴールファイルは永続的な PASS／FAIL 台帳であり、秘密情報の保管場所ではありません。 必須・重要・要注意 失敗に関する主張にはすべて file:line 形式の証拠を示してください（確信度が80%を超える場合は対応し、80%未満の場合は先に検証してください）。どのテストが失敗したか、あるいはその理由を推測してはいけません。レポートを読んでください。理由：推測に基づく失敗判定は、ユーザーに誤った箇所を修正させることになります。 必須・重要・要注意 断続的な失敗は、製品の欠陥ではなく未判定として扱ってください。欠陥として報告する前に、証拠に基づいて（a）非現実的なシナリオ／アクターのペースが圧縮されている、（b）ハーネスのトポロジーによる増幅（共有インフラ、ファンアウトするコンシューマー、スイートの並列実行、コールドスタート）、（c）実際の製品の競合状態、のいずれかに分類してください。証拠がない場合は未判定として報告してください。理由：テストの忠実性に関する欠陥を製品の欠陥として報告すると、そもそも問題のなかったコードをチームが修正することになります。 必須・重要・要注意 テストとソースの関連性を主張する前に、類似するテストを3件以上 grep して、ローカルのパターンと照合してください。ソース／テストの乖離チェックも実施し、失敗したテストが意図された動作を検証しているのか、ソースにバグがあるのかを証拠に基づいて判断してください。理由：前提の食い違いにより、実際のバグが不安定なテストとして誤判定されるおそれがあります。 必須・重要・要注意 着手前にタスクトラッキングを使って作業を小さな ToDo タスクに分割してください。1件を in_progress にし、証拠がそろったらすぐに完了にしてください。作業品質を確認するための最終レビュー用 ToDo も追加してください。 必須・重要・要注意 ユーザーに直接質問して、実行ルート／判断を確認してください。ワークフロー実行と単独実行のどちらにするかを自動で決めてはいけません。 重要・要注意 着手前に CLAUDE.md を読んでください。

合理化の禁止：

言い逃れ	反論
「テストは明らかに成功するので、実行しなくてよい」	それでも tester 経由で実行してください。推測による判定は判定ではありません。実際の件数を報告してください。
「テストコマンドを直接実行できる」	絶対にしてはいけません。必ず tester サブエージェントに委任してください。直接実行すると、正式なレポートを経由しません。
「失敗は些細なものに見えるので、修正しておく」	報告した時点で停止してください。修正は $fix の役割です。このスキルは厳密に読み取り専用です。
「ゴールファイルがないので、証拠の記録は省略する」	No active goal — evidence reported inline only. と記録してください。Goal Contract の手順を黙って省略してはいけません。
「どのテストが失敗したか、わかっている」	file:line とレポートのパスを示してください。証拠がなければ主張してはいけません。
「一度失敗したので、製品のバグだ」	断続的な失敗は未判定です。証拠を示し、非現実的なシナリオとハーネスによる増幅を先に除外してください。

[IMPORTANT] 着手前にタスクの規模を分析し、多くの小さな ToDo タスクに体系的に分割してください。これは非常に重要です。 締めくくりのリマインダー — 成功の指標は「変更しやすさ」です。 すべての調査結果、テスト、リファクタリング、抽象化について、次の問いに答えなければなりません。これによって、次の変更は容易になりますか、それとも難しくなりますか？ 将来の変更コストを削減しないのであれば、却下してください。真の敵は、結合、隠れた状態、知識の重複、意図の不明確さです。その名を挙げて指摘してください。

重要・必ず注意 読み取り専用 — 合否を報告してください。ここでは決して修正しないでください（修正は $fix の担当です）。 重要・必ず注意 必ず tester サブエージェント経由で実行してください。失敗を報告する際は、すべて file:line とレポートパスを記載してください（確信度 >80%）。 重要・必ず注意 目標： 正確な読み取り専用の合否判定、正確な件数、失敗したテスト名、レポートパス、Goal Contract の根拠を提示してください。修正を行わずに実際のテスト状態をユーザーが把握できるようにします。

フックなしプロンプトプロトコルのミラー（自動同期）

ソース：.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. 実行： コンテキストの指示にあるワークフローステップの進行と並列フェーズのルールに従って進めます。ステップの進行はモデル主導です。サブエージェントの完了はインライン呼び出しと同様にステップを進めます。並列フェーズのグループでは全員の完了を待ち、全メンバーからの応答がそろうまで次へ進んではいけません。決して逐次実行に切り替えないでください。

Shared AI-SDD Protocol Markers

Source: .claude/skills/shared/sync-inline-versions.md

SYNC:ai-sdd-artifact-contract

AI-SDD Artifact Contract — 共有の仕様駆動開発ルールは、移植可能な状態を保ち、ソース側で管理します。

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] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、計画したすべてのステップについてタスク追跡を作成／更新し、各ステップの開始時／完了時に同期してください。

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

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

教訓を抽出する — 症状への対処ではなく、根本原因のみを対象にします。

1. 症状ではなく、失敗モード（推論や前提の誤り）を明示してください。「誤った列挙値を使った」ではなく、「ソースコードを読まずに API が存在すると仮定した」のようにします。
2. 汎用性を確認してください。この失敗モードは、3 つ以上のコンテキストやコードベースに当てはまりますか。当てはまらない場合は、もう 1 段階抽象化してください。
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、ビジネスエンティティ、機能ルール）を一切参照してはいけません。漏れがコンパイルされ、実行されると、再利用可能なはずの層が一つの利用側と結合していても、レビューで気づかれずに通過してしまいます。共有型からドメイン情報を排除し、サブクラス化／コンポジションを通じて、ドメインフィールド／ロジックを利用側へ移してください。理由：一つの利用側のドメインに結合した層は、もはや再利用可能ではありません。