watzup

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

クイックサマリー

目標： 現在のブランチの変更をレビューし、影響と品質を要約して、変更サマリー、ドキュメント／仕様の陳腐化フラグ、根本原因から得た教訓、$understand レビュガイド（図、ユーザーストーリー、レビュー手順、テスト／デモの方法）を含む、根拠に基づいた完全な引き継ぎ情報を開発者に渡します。ファイルは一切変更せず、十分な情報を得たうえで次のステップを判断してもらいます。

要約：

• 読み取り専用の契約 — 現在のブランチのコミットをレビューして要約し、調査結果を指摘するだけにとどめます。指摘したドキュメント／仕様を編集、修正、実装、更新してはいけません。理由：watzup は引き継ぎであり、編集作業ではないためです。
• 主な手順（順番どおり）： (1) 最近のコミットをレビュー — 何が変更／追加／削除されたか。(2) 影響と品質を要約。(3) ドキュメント陳腐化ゲート — パスからドキュメントへの対応表。(4) 仕様駆動の健全性チェック — 機能仕様のルート → 仕様の陳腐化 → 機能ドキュメントの最新性（ビジネスコードが変更された場合のみ）。(5) 根本原因からの教訓の抽出 — ミスを明らかにし、症状ではなく障害モードを特定し、普遍的なルールにまとめて、ユーザーに確認する。(6) $understand による引き継ぎ — 完全なレビュガイドを作成。最後に必ず実施します。(7) ユーザーに次のステップを直接尋ねる。
• 明示するコスト： $understand による引き継ぎは、以前より詳細な成果物を作成します。図を導き出し、実際のテストケース ID を特定し、順序付きのレビュールートを作成するため、リポジトリをより広く読み、レポートも長くなります。これは、作業の振り返りだけでなく、作業へ進むためのルートを示す引き継ぎにするための意図的なコストです。あとから判明するのではなく、選択できるよう、ここに明記しています。
• 変更サマリーの後に必須となるゲートは 3 つです。ドキュメント陳腐化チェック、仕様駆動の健全性チェック（ビジネスコードのみ）、根本原因からの教訓の抽出です。変更が「小さく見える」ことを理由に、ゲートを省略してはいけません。
• 教訓を $learn に追加するのは、ユーザーの確認後のみです。「常にファイル X を確認する」といった表面的なメモはノイズであり、教訓ではありません。
• $understand による引き継ぎは最後に必ず行い、ユーザーへの次のステップの質問より前に実行しなければなりません。利用できない場合は停止して、ブロッカーを報告します。省略してはいけません。理由：開発者が作業を終えるときに必要なのは説明であり、生の差分ではないためです。

ワークフロー：

1. レビュー — 最近のコミットを分析します。変更、追加、削除されたものを確認します。
2. 要約 — 品質評価を含む、変更の詳細なサマリーを提示します。
3. ドキュメントチェック — 変更されたファイルと docs/ を照合し、陳腐化していないか確認します。
4. 教訓の抽出 — タスク中の AI のミスや問題を分析し、教訓として記録します。
5. Understand による引き継ぎ — 最後に必須タスクとして $understand を呼び出し、完了した作業についての完全なレビュガイドを開発者に提供します。全体像から始めて詳細へ進む、概要 → 手順 → 詳細 → 検証と異議申し立ての 4 部構成です。セクションの仕様は understand/SKILL.md の Step 4 に記載されており、ここでは再掲しません — このファイルにも複製すると、仕様が変更された際に気づかないまま古くなるためです。plans/reports/understand-*.md に書き込むか、そこに保存できる Git 除外ディレクトリがない場合はチャットで全文を提示し、チャット内でも要約します。

重要なルール：

• 読み取り専用です。調査結果を指摘するだけにとどめ、実装や修正は一切行いません。
• ドキュメント陳腐化チェックは必須です（以下の対応表を参照）。
• 教訓の分析は必須です（以下のセクションを参照）。
• 最終レビュータスクでは、ドキュメント陳腐化チェック、教訓の分析、最後の $understand による引き継ぎを必ず含めてください。
• watzup のサマリー、ドキュメント分析、ミスの分析が完了した後、最後の次のステップに関する質問をする前に、必ず $understand を呼び出してください。

懐疑的な姿勢を保ち、批判的思考と段階的な思考を適用してください。すべての主張には追跡可能な根拠と確信度を付けてください（確信度は 80% 以上にしてください）。

現在のブランチと直近のコミットをレビューしてください。 変更されたもの、追加されたもの、削除されたものを含め、すべての変更を詳しく要約してください。 変更全体の影響と品質を分析してください。

重要： レビューと要約のみを行い、実装は開始しないでください。

ドキュメントの古さチェック（必須）

変更の概要を示した後、git diff --name-only（ベースブランチまたは最近のコミットとの差分）を実行し、変更されたファイルと関連ドキュメントを照合します。

変更されたファイルのパターン	古さを確認するドキュメント
.claude/hooks/**	.claude/docs/hooks/README.md、.claude/docs/hooks/*.md のフック数テーブル
.claude/skills/**	.claude/docs/skills/README.md、スキル数／カタログのテーブル
.claude/workflows/**	CLAUDE.md のワークフローカタログテーブル、.claude/docs/ のワークフロー関連箇所
{configured-service-source-root}/**	変更されたサービスに対応する docs/specs/ のドキュメント（パスは docs/project-config.json を参照）
{configured-frontend-source-root}/**	docs/project-reference/frontend-patterns-reference.md、関連するビジネス機能のドキュメント
CLAUDE.md	.claude/docs/README.md（ナビゲーションハブとの同期を保つ必要があります）

次のいずれかを出力します：

• 更新が必要と思われるドキュメントを箇条書きで示し、古くなっている可能性のある内容を簡潔に記します（例：「フック数が31から32に変更」）。
• No doc updates needed — 変更されたファイルのパターンがドキュメントに該当しない場合。

watzup の実行中はドキュメントを編集しないでください。 指摘のみを行います。修正するかどうかはユーザーが判断します。

---

仕様駆動開発の健全性チェック（ビジネスコードの変更時は必須）

git diff --name-only にバックエンドサービスのソースパスまたはフロントエンドアプリ／ドメインのソースパス配下の変更が含まれる場合に、このチェックを実行します（プロジェクトの構成リファレンスまたは docs/project-config.json から具体的なパスを確認してください）。

ステップ 1 — 機能仕様のルートを確認

ls docs/specs/ 2>/dev/null

注： 結果は app-bucket 名です。特定の機能仕様を探すには、ls docs/specs/{app-bucket}/ を実行し、正式な README.{Feature}.md ファイル、派生したバケットインデックス／ERD を確認してください。

結果	対応
ディレクトリが存在しない、または空	⚠️ 注意："No Feature Specs found under docs/specs/. Consider running $workflow-code-to-spec (mode: init-full) to bootstrap spec-driven documentation for this codebase." と報告します。
機能仕様が存在する	ステップ 2 に進みます

ステップ 2 — 仕様の古さチェック（仕様バンドルが存在する場合のみ）

docs/specs/ 内の各仕様ファイルについて：

git log --since="30 days ago" --name-only -- docs/specs/ | head -10

結果	対応
過去30日間にコミットがなく、今回のセッションでビジネスコードが変更された	⚠️ 注意："Engineering spec bundle may be stale (no updates in >30 days). Consider running $workflow-code-to-spec (mode: audit) to verify freshness." と報告します。
最近のコミットが見つかった	✅ 仕様バンドルは保守されています

ステップ 3 — 機能ドキュメントの最新性チェック

git log --since="30 days ago" --name-only -- docs/specs/ | head -10

結果	アクション
過去 30 日間にコミットがなく、ビジネスコードに変更がある	⚠️ フラグ：「"Business feature docs may be stale. Consider running $docs-update to sync."」
最近のコミットが見つかった	✅ 機能ドキュメントはメンテナンスされています

該当するフラグのみ出力してください。ビジネスコードに変更がない場合は、このセクション全体を省略してください。

---

AI のミスと学びの分析（必須）

ドキュメントの最新性を確認した後、セッション全体を振り返り、AI のミスと学びを確認してください。

ステップ 1 — すべてのミスを洗い出す

セッション中に発生したすべてのエラーを列挙してください。それぞれについて、以下を記載してください。

• 何が起きたか（ビルド失敗、テスト失敗、誤った出力など、観察可能な症状）
• どこで起きたか（該当する場合はファイル名:行番号）

よくあるミスのカテゴリ：

• ソースを読まずに、API／型／列挙値が存在すると仮定した
• 要件を確認せず、インフラが利用可能だと仮定した
• 「コードが存在する」ことと「コードが実行される」ことを混同し、実行経路を追跡しなかった
• 新しいコンテキストにも同じ前提条件があるか検証せずに、パターンを使用した
• すべてのスタックで影響を受ける出力をすべて検証せずに、「完了」と報告した
• メソッド名、クラス名、ファイルパスを幻覚した

ステップ 2 — 根本原因から学びを抽出する（症状への対処ではない）

ミスごとに、次の 3 ステップで学びを抽出してください。

2a. 失敗モードを特定する — 症状ではなく、推論上の失敗を記述します。

症状（悪い教訓）	失敗モード（良い教訓）
「誤った列挙値を使用した」	「ソースに存在するか確認せず、推測した API を使ってコードを生成した」
「using の名前空間が誤っていた」	「プロジェクト固有の設定ファイルを先に読まずに、プロジェクトの構成を仮定した」
「CI でハッピーパスのアサーションが失敗した」	「ハンドラーが実行時に必要とするインフラを追跡せずに、アサーションを記述した」
「クエリに存在しないプロパティを設定した」	「基底クラスを読まずに、階層内のすべての型が同じインターフェースを共有すると仮定した」

2b. 適用範囲を見つける — 同じ失敗モードは、ほかにどこで起こり得るでしょうか？

失敗モードが特定のファイルやケースにしか当てはまらない場合は、一般化できるまで抽象度を 1 段階上げてください。良い教訓は、3 つ以上の異なるコンテキストに適用できます。

2c. 普遍的なルールとして記述する — プロジェクト固有の名前をすべて取り除きます。

• ファイルパス、このコードベース固有のクラス名、ツール名は含めない
• 言語の異なるまったく別のコードベースでも役立つアドバイスにする
• 複数のミスが同じ失敗モードを共有する場合は、1 つの教訓にまとめる
• テスト：「この教訓は、Java、Go、Python のプロジェクトでも同種のミスを防げるか？」はいなら良い教訓です。いいえなら書き直してください。

ステップ 3 — 学びの保存についてユーザーに確認する

「根本原因に関する教訓が [N] 件見つかりました。今後のセッションのために $learn を使って保存しますか？」

$learn を呼び出す前に、ユーザーの確認を待ってください。

次のいずれかを出力してください。

• 番号付きリスト：失敗モード → 普遍的な教訓 → 提案する $learn のテキスト
• このセッションでは AI のミスは特定されませんでした — 本当にミスが見つからなかった場合

正直に、批判的に振り返ってください。 このコードベースでしか役立たない表面的な症状への対処（「常にファイル X を確認する」など）は教訓ではなく、ノイズです。目的は、セッションを重ねるごとに根本原因の再発を防ぐことです。

---

次のステップ

必須・重要・必ず注意 — 例外なし これらの選択肢を提示する前に、watzup の要約と現在の変更セットを対象として、最後に必ず実行する TODO タスクとして $understand を呼び出してください。$understand を利用できない場合は、引き継ぎを黙って省略せず、作業を中断してその阻害要因を報告してください。

$understand の完了後は、必ず注意して、ユーザーに直接これらの選択肢を提示してください。タスクが「単純」または「明白」に思えるという理由で、決して省略しないでください。判断するのはユーザーです。

• "$workflow-end (Recommended)" — アクティブなワークフローを完了して終了する
• "$commit" — ワークフローを使わない場合は変更をコミットする
• "Skip, continue manually" — ユーザーが判断する

[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 になっていること。 プロジェクト参照ドキュメントのゲート — タスク追跡の初期化後、対象ファイルやソースファイルの読み取り、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. 対象ファイルの読み取り、grep、編集、分析を行う前に、小規模なタスク分解を作成します。コンテキストを失った場合は、まず現在のタスクリストを確認します。
2. 作業開始前にタスクを 1 つ 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つ以上確認 - [ ] 確信度の明示

根拠なしでの使用禁止： 「明らかに」「私はこう考えます」「～すべきです」「おそらく」「これが原因です」 未完了の場合 → 次を出力してください："Insufficient evidence. Verified: [...]. Not verified: [...]."

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

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

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

必ず注意してください 重要かつ段階的な思考を適用してください。すべての主張には、適切に追跡可能な根拠が必要です（リポジトリ／コードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または成果物のセクション）。実行するには確信度が80%を超えている必要があり、60%未満の場合は推奨してはいけません。幻覚を防ぐため、推測を事実として提示せず、不確実性を率直に認め、独立して相互参照し、自分の確信度を懐疑的に評価してください。

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

• 必須 対象作業に着手する前に、タスク管理を開始してください。タスクは一度に1つずつ進めてください。

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

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

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

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

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

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

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

重要・必ず注意 このスキルで宣言された手順の順序に従ってください。ユーザーの明示的な承認なしに、手順を省略、並べ替え、統合してはなりません。 重要・必ず注意 各手順／サブスキル呼び出しでは、実行前に 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 から読み取ってください。本文が欠落または不正な形式の場合は報告し、再構成してはなりません。オーバーレイは追加のみ（このスキル独自のルールを置き換えません）であり、概要であって権限を強化するものではありません。同じ具体性の項目が矛盾する場合はユーザーに提示してください。

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

重要・必ず注意 目標： ファイルを一切変更せず、変更概要、ドキュメント／仕様の古さに関する警告、根本原因から得た教訓、$understand のレビューガイドを含む、完全で根拠に基づいた総括を開発者に提供してください。これにより、開発者は全体像を踏まえて次の手順を決定できます。

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

• ネストされたタスクの作成： 子フェーズを展開し、親タスクにリンクし、タスクを1つだけ in_progress にします。
• プロジェクト参照ドキュメントのガイド： 作業を始める前に、必須のプロジェクト参照ドキュメント（必ず lessons.md）を読みます。
• タスク追跡と外部レポート： タスク追跡を初期化し、調査結果を plans/reports/ に随時保存します。
• 批判的思考： 批判的かつ順序立てて考え、根拠を追跡し、推測を事実として扱いません。
• 証拠： すべての主張に file:line を添え、推測は一切しません。
• AI の誤りの防止： 生成した内容を証拠と照合し、後続の参照を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後は読み直し、曖昧な点を明示します。

重要：必ず注意してください — 読み取り専用を守ってください。指摘事項はフラグを立てるだけにし、指摘したドキュメントや仕様を編集、修正、実装、更新してはいけません。理由：watzup はレビュー／引き継ぎであり、編集作業ではありません。指摘後に修正すると、読み取り専用の契約に気づかないまま違反することになります。 重要：必ず注意してください — 変更の要約後に、必須の3つのゲートをすべて実行してください。ドキュメントの陳腐化チェック（パス→ドキュメントの表）、仕様駆動の健全性チェック（ビジネスコードを変更した場合のみ）、根本原因に基づく教訓の抽出です。変更が「小さく見える」からといって、ゲートを省略してはいけません。理由：古くなったドキュメントや見逃された教訓は、セッションをまたいで気づかないうちに積み重なります。 重要：必ず注意してください — ユーザーに「次のステップ」を直接尋ねる前に、最後の必須の引き継ぎとして $understand を呼び出してください。$understand を利用できない場合は、停止してそのブロッカーを報告してください。引き継ぎを黙って省略してはいけません。理由：開発者が必要とする終了時のコンテキストは説明であり、生の差分ではありません。

重要：必ず注意してください — 症状ではなく、根本原因（推論や前提の誤り）に基づいて教訓を抽出してください。それぞれの教訓は、3つ以上のコードベースで成り立つ汎用的なルールとして記述してください。「ファイル X を必ず確認する」のような表面的なメモはノイズです。理由：セッションをまたいで効果が積み重なるのは、根本原因を防ぐ教訓だけです。 重要：必ず注意してください — 明示的にユーザーの確認を得た後に限り、教訓を $learn に送信してください。自動で保存したり、指示ファイルを自分で編集したりしてはいけません。理由：教訓の記録は、ユーザー自身が管理すべき永続的な指示の変更です。 重要：必ず注意してください — 「次のステップ」の決定は、ユーザーに直接尋ねてください。明白に「見える」場合でも、進め方を自動で決めてはいけません。理由：ワークフローを終了するか、コミットするか、続行するかはユーザーが決めます。 重要：必ず注意してください — 作業を始める前に、タスク追跡を行いながら作業を小さな TODO タスクに分割してください（1ファイルを読むごとに1タスク）。in_progress は常に1つだけにし、作業品質を確認する最終レビューの TODO も追加してください。理由：長いファイルはコンテキストを使い果たすことがあり、細分化されたタスクは圧縮後も維持されます。 重要：必ず注意してください — すべての主張／指摘には、file:line の証拠または追跡可能な証拠と確信度（%）を添えてください（着手するには80%超、80%未満の場合は先に検証）。推測を事実として示してはいけません。理由：検証されていない陳腐化や教訓の指摘は、開発者の次の判断を誤らせます。 重要：必ず注意してください — ドキュメント、パス、API を指摘する前に、grep/glob を使って実在することを確認してください。ドキュメントの対応関係や件数をでっち上げてはいけません。理由：AI はファイルパスやメソッド名を捏造することがあり、変更の要約は実際の差分と一致していなければなりません。 重要：必ず注意してください — 作業をまとめる前に、CLAUDE.md とプロジェクト参照ドキュメントのゲート（必ず lessons.md）を読んでください。理由：プロジェクトの規約は、一般的な陳腐化の想定より優先されます。

合理化の防止：

回避策	反論
「ドキュメントに問題はなさそうだから、鮮度チェックはスキップしよう」	それでもパス→ドキュメントの対応表を確認してください。古さは表面化しないため、フラグを立てるか、No doc updates needed と出力してください。
「このセッションでは実際のミスはなかったから、教訓はスキップしよう」	それでもチェックを実行してください。率直に自己レビューした後に限り、No AI mistakes identified と出力してください。
「次にコミットするよう求められているのは明らかだから、そのまま実行しよう」	決して自動で判断しないでください。ユーザーに選択肢を直接提示してください。進め方を決めるのはユーザーです。
「ここにいるついでに、この古いドキュメントを修正しておこう」	読み取り専用です。フラグを立てるだけにしてください。ここで修正すると契約に反します。判断するのはユーザーです。
「小さな変更だから、$understand はスキップしよう」	$understand は必須の引き継ぎです。実行するか、ブロッカーを報告してください。決してスキップしないでください。

重要：必ず目的を反映すること： 根拠に基づく読み取り専用のまとめです。変更の概要、ドキュメント／仕様の古さに関するフラグ、根本原因から得た教訓、必須の $understand への引き継ぎを含め、何も変更せず、次のステップはユーザーが決めます。

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

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