fix

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 Spec
• 統合テストの実装／レビュー：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 ツールを使用できない場合は、同じステータス遷移を用いた、同等の手順ごとの計画トラッカーを維持してください。

クイックサマリー

目標： サブエージェントによる並行調査を使って問題の根本原因を取り除き、file:line の証拠を示しながら末端から起点まで追跡し、不変条件を所有する最下層で修正します（クラッシュ箇所では決して修正しません）。その後、$prove-fix で修正を検証し、症状だけでなく問題そのものが解消されたことを証明します。

概要：

• 目的： 症状ではなく問題そのものを解消する、インテリジェントな修正ルーターです。証拠に基づいて根本原因を診断し、不変条件を所有する最下層で修正し、$prove-fix で検証したうえで、仕様・テスト・コードの同期を維持します。
• ルーター優先（--target=）： --target={ci|issue|logs|test|types|ui} を指定した場合は、Root-Cause Prerequisite Gate を通過してから、その自己完結型のインライン分岐に進みます（各分岐は独自に診断と $prove-fix を実行します）。フラグを指定しない場合は、診断から修正までの一連の手順をすべて実行します。 — 理由：分岐でスタンドアロン手順の §1／§2 を再実行しないようにするためです。ただし、どの分岐でも根本原因の追跡は必須です。
• 主な手順（フラグなしの一連の手順）： Root-Cause Prerequisite Gate → スカウト（並行サブエージェント）→ 根本原因を末端から起点まで診断（debug-investigate、file:line の証拠、仮説マトリクス、前方への収束の証明）→ Confidence & Evidence Gate → 影響分析を含む計画 → 🛑 修正前の承認確認 → 所有するレイヤーで実装 → $prove-fix → 条件付きの $spec 正確性確認 → $changes-review（本番コード）→ $why-review による最終承認。
• Root-Cause Prerequisite Gate（ブロッキング、最初に実行）： 直接の $fix 呼び出しでは、フラグなしの一連の手順と、すべての --target= 分岐の両方で、$debug-investigate がこのセッションでこの問題の根本原因を特定するまで、コードを編集してはなりません。その証拠は、現在のタスクリストの項目または書面の調査レポートで示す必要があります（記憶は証拠ではありません。親ワークフローの項目だけでは証明になりません）。未実行の場合は、まず $debug-investigate を実行し、計画の手順から再開します。 — 理由：そうしないと、原因を追跡しないまま最初の編集が行われ、症状の箇所にパッチを当てることになるためです。
• 省略できない3つの必須ゲート： Root-Cause Prerequisite Gate（上記）、Confidence & Evidence Gate（Confidence: X% と file:line を提示し、60% 未満なら停止）、🛑 修正前の承認確認（コード変更の前に、根本原因と計画をユーザーに直接提示して承認を求めること。ワークフロー内に限り承認を省略できます）。
• パッチの前に診断する： 症状を末端から起点までたどって不変条件を所有するレイヤーを特定し、クラッシュ箇所では決して修正しないでください。クラッシュ箇所は症状であり、原因はより下層から入り込みます。
• モードと省略ルール： 5つすべての軽微なバグに関するオプトアウト条件を満たさない限り、デフォルトは HARD モード（厳密な手順）です。スタンドアロン（親ワークフローなし）では、最小限の一連の手順 debug-investigate → fix + prove-fix → $spec correctness check → $changes-review (production code) → $why-review を自動的に構成します。ワークフロー内では、この契約全体を省略します。ただし、Root-Cause Prerequisite Gate は常に必須です。この問題について debug-investigate が実際に実行されたことを示す証拠は、引き続き必要です。 — 理由：スタンドアロンには診断、仕様の同期、レビューを行う手順がなく、ワークフローの項目だけでは診断ステップが実行された証明にならないためです。

ワークフロー：

1. スカウト — スカウト／リサーチャーのサブエージェントを使い、問題を並行して調査します
2. 診断 — 証拠をもとに、コードパスをたどって根本原因を特定します
3. 計画 — 影響分析を含む修正計画を作成します
4. 修正 — 修正を実装して検証します

主なルール：

• Root-Cause Prerequisite Gate（ブロッキング）： $debug-investigate がこのセッションでこの問題を証拠に基づいて追跡するまで、コードを編集してはなりません。記憶ではなく、証拠が必要です。
• デバッグの心得：すべての主張に file:line の証拠が必要です
• 複数の仮説を並行して調査するには、サブエージェントを使用します
• 複雑な修正を実装する前に、必ず計画を作成します
• ターゲットフラグ（Target Routing を参照）：--target={ci|issue|logs|test|types|ui} は、対象領域に修正範囲を限定する自己完結型のインライン分岐を選択します。フラグを指定しない場合は、以下の診断から修正までの一連の手順をすべて実行します。

デフォルトモードのポリシー

デフォルトモードは HARD（徹底調査）です。 以下の各セクションはすべて、デフォルトで適用されます。並列のスカウト／リサーチャーサブエージェント、file:line の根拠を用いた根本原因の追跡、Confidence & Evidence Gate、影響分析を含む修正計画、バグを対象とした再発防止テストが含まれます。

次の条件をすべて満たす場合に限り、ファストモードを選択できます（バグが本当に些細な場合）。

• エラーメッセージから根本原因が明らかで、すでに特定されている（診断が不要）
• 単一ファイルの修正で、変更が10行以下
• サービス間への影響がなく、契約の変更もない
• バグのテストがすでに存在する、またはバグが機能に影響しない（誤字、ログメッセージなど）
• 追加調査をしなくても、修正への確信度が95％以上

条件をひとつでも満たさない場合 → 以下のフルプロトコルを使用してください。 判断に迷ったら、デフォルトの HARD を選択してください。重大なバグ修正で診断を省略すると、症状だけを修正して原因を残すことになります。

ファストモードで省略するのは、以下に限られます。 並列サブエージェントによる調査（代わりに直接読み取り／grepを実施）、独立した修正計画（変更と併せて対応）、回帰テストの作成（対象をカバーするテストが存在する場合に限る）。Confidence & Evidence Gate、Behavioral Delta Matrix、既存テストスイートの実行は省略しません。

🛑 根本原因の事前確認ゲート（直接の $fix 呼び出し）— ブロッキング

【ブロッキング】$debug-investigate がこのセッションでこの問題の根本原因を特定するまで、$fix はコードを編集してはいけません。 このゲートは、以下のスタンドアロンモードの最小契約より前、--target= の各分岐本体より前、そして 🛑 修正前検証の承認より前に実行されます。— 理由：$fix を直接呼び出すと、追跡された根本原因がまったくないまま最初の編集に進み、症状の箇所にパッチを当てて病気をそのままリリースするおそれがあります。

1. トリガー — $fix の直接呼び出しはすべて対象です。 ユーザーが入力したスラッシュコマンドでも、モデルが選択したスキルでも同様です。すべての --target={ci|issue|logs|test|types|ui} 分岐と、フラグなしの処理経路の両方が対象です。--target= 分岐では、以下の契約の §1／§2 を再実行しませんが、このゲートは通過します。— 理由：分岐独自の debugger／tester サブエージェントのステップは、最初から最後までの根本原因の追跡ではないため、実行範囲を絞っても追跡は必要です。

2. 確認 — 記憶ではなく証拠を確認します。 最初のコード編集の前に、このセッションで同じ問題に対して $debug-investigate がすでに実行されたかを確認します。認められる証拠は、次のいずれかのみです。

• この症状を対象としている、現在のタスクリストにある debug-investigate の行（またはそのフェーズのタスク）、または
• この症状を明記し、最初から最後までの追跡を含む調査レポート（例：.ai/workspace/analysis/{issue-name}.analysis.md、plans/reports/debug-investigate-*.md）。

該当する証拠がない場合 → 未実行として扱います。 原因が「わかっている」という記憶は証拠ではありません。— 理由：コンテキストが圧縮された後も、調査は済んだというモデルの認識は残る一方で、実際の調査結果は失われることがあります。

3. 実行。 未実行の場合は、まず問題に対して $debug-investigate を実行し、その後、根本原因レポートを使って、計画ステップから $fix の処理経路を再開します。これは、処理経路内のステップ1にある debugger サブエージェント（以下の契約の §1 のルールと同一）を置き換えます。— 理由：スキルですでに追跡済みの診断を再実行すると、処理経路が重複して実行されます。

4. 同一問題の判定。 別の症状に対して以前実行した $debug-investigate では、このゲートを満たしません。適用対象はスキル名ではなく、問題に紐づきます。現在の <issues> にある症状が既存のレポートで扱われていない場合、このゲートが発動します。— 理由：そうでなければ、セッションごとに1回調査するだけで、追跡されていない修正を無制限に実行できてしまいます。

5. スキップ条件 — 明示的かつ限定的で、記録が必要です。 該当する条件とその証拠を記録し、黙ってスキップしてはいけません。

条件	スキップ？
§2 に基づく同一問題の証拠がある → file:line／タスク行の証拠を引用して続行します	はい
高速モードでの軽微なバグ（Default Mode Policy のオプトアウト条件5つすべてを満たす） → スキルを起動せずに、最初から最後までの追跡をインラインで記述してもかまいません。ただし追跡自体は必須です	部分的
アクティブな親ワークフローの行で、この問題に対する debug-investigate がすでに実行済み → 完了したステップを引用します	はい
アクティブな親ワークフローの行はあるが、この問題に対する debug-investigate のステップが完了していない	いいえ

最後の行が、このゲートで塞ぐ抜け穴です。 以下の契約では、親ワークフローの行が存在するだけでスタンドアロンモードとして検出します（「モードの検出」、「スタンドアロンモードの最小契約」）。その行があっても、シーケンス内の debug-investigate ステップが実行されていない、別の症状を対象に実行された、またはスキップされた可能性があります。このゲートは、その検出条件に加えて、この問題に対する実行証拠という、より厳格な要件を追加するものであり、決して緩和するものではありません。— 理由：タスクを格納する入れ物が存在することは、その中の作業が行われた証拠にはなりません。

ブロック解除の条件： §2 の確認を証拠とともに明示する（または、該当するスキップ行とその証拠を示す）こと、そしてこの問題の根本原因を追跡した記録が存在すること。根拠が「原因は明らか」というだけで、計画や編集に進んではいけません。

スタンドアロンモードの最小契約（ワークフロー以外のみ）

$fix は通常、workflow-bugfix 内のステップです — その場合、シーケンス（scout → investigate → debug-investigate → spec [mode=amend] → plan → … → fix → prove-fix → … → spec [mode=sync] → workflow-review-changes]）によって、修正に伴う診断、仕様の同期、レビューが行われます。単独で呼び出した場合、これらを実行するシーケンスはありません。 $fix 単独ではコードの診断とパッチ適用を行いますが、根本原因をその原因を持つレイヤーまで追跡したこと、docs/specs/ 内の Feature Spec が引き続き動作と一致していること、変更がレビューされたことを、それだけで保証するわけではありません。単独で実行すると、その不足によって症状へのパッチ適用と仕様／ドキュメントの乖離が生じます。

適用範囲： この契約は、フラグなしの $fix の流れ（診断から修正までの全工程）を対象とします。--target={ci|issue|logs|test|types|ui} の分岐はそれぞれ自己完結しており、各分岐で独自に診断と $prove-fix を実行するため、ここでは§1／§2を再実行しません。単独で実行する場合、後続ゲートとして適用されるのは**§3（仕様の正確性チェック）と§4（why-review）**のみです（--target=issue には独自の $changes-review ゲートがすでにあります。その分岐を参照してください）。

検出モード： まず現在のタスクリストを確認してください（以下の Nested Task Expansion Contract に従います）。アクティブな親ワークフローの行がある場合 → このセクション全体をスキップします（ワークフローがこれらのステップを担うため、重複すると一連の工程が二重実行されます）。ただし、上記の Root-Cause Prerequisite Gate は引き続き適用されます。つまり、このセクションをスキップするには、親シーケンスの debug-investigate ステップが単に存在するだけでなく、_この問題について完了している_必要があります。行はあるが、このステップが未実行 → ゲートが作動し、まず $debug-investigate を実行します。親の行がない場合 → 単独実行： 最初のコード編集の前に、MUST ATTENTION で、タスク管理の ToDo として以下の最小限のバグ修正工程を、順番どおりに組み立ててください。

1. $debug-investigate — 根本原因の調査を最初に行います。上記の Root-Cause Prerequisite Gate で必須とされており、§2の証拠チェックによって、この問題についてすでに実行済みかを判断します。 症状を起点から逆向きにたどり、不変条件を所有するレイヤーまで追跡し、file:line の根拠を示します（仮説マトリクスと、順方向の収束証明を含みます）。これが単独実行時の診断そのものです。工程の内部ステップ1である debugger サブエージェントの役割を含んでいるため、このレポートを使って計画ステップから工程を再開します。高速モードの自明なバグ（Default Mode Policy のオプトアウト条件をすべて満たすもの）では、スキルを起動せず、追跡をその場で行ってもかまいません。ただし、起点から逆向きにたどる追跡は必須です。
2. 修正工程 — 以下に記載されている、このスキルの plan → 🛑 approve → implement → $prove-fix`` の手順です。修正前検証の承認ゲートと $prove-fix に変更はありません。
3. $spec による仕様の正確性チェック — 仕様ドキュメントが古いままにならないようにするための条件付きチェックです。 根本原因の検証結果に基づき、該当するケースを判断します。
   • 仕様が誤っていた／古くなっていた場合 — 実際には一度も正しくなかった動作を記述していた、または意図する動作が変わったのに仕様が更新されていなかったケースです。仕様も（欠陥の）一部であるため、$spec [mode=amend] を実行して§1～§7の仕様を修正し、その後 $spec [mode=sync] を実行して§8の TC-{FEATURE}-{NNN} と統合テストの対応を調整します。
   • 仕様は正しく、コードが仕様を満たしていなかっただけの場合 — コードのみの欠陥であり、§1～§7の動作は再び仕様と一致しています。§1～§7は修正しません。 ただし、§8のテストケースは引き続き確認します。バグによって再現したシナリオ／エッジケースをカバーする既存の TC-{FEATURE}-{NNN} がない場合（仕様は_正しいが、バグのケースが不足していた場合）、$spec [mode=tests] で回帰テストケースを追加して仕様に反映し、その後 $spec [mode=sync] を実行して§8と新しい回帰テストの対応を調整します。既存の TC ですでにそのケースをカバーしている場合に限り、file:line の根拠を添えて Spec verified correct, bug case already in §8 — no spec change (code-only defect) と記録して先に進みます。修正したバグのケースを、仕様の§8に記載されていないままにしてはいけません。
   • 該当する仕様がない場合 — バグのある領域に docs/specs/ 内の Feature Spec がありません。file:line の根拠を添えて No governing spec — nothing to amend と記録します。その領域に仕様が必要となる場合は、提案だけにとどめず $spec [mode=init] を実行し、その後 [mode=tests] を実行して、バグのケースを回帰 TC として§8に追加します。ケースを明示的に判断してください。省略できるのは修正だけであり、判断ではありません。領域を仕様が対象としている場合、バグのケースをドキュメント化せずに残してはいけません。
4. $why-review — 修正後、さらに $changes-review がある場合はその後に行う、最終 ToDo の根拠レビューです。 収束した変更に対する最終承認として、根本原因が正しいレイヤーに帰属していること、修正がクラッシュ発生箇所ではなく不変条件を所有する最も低いレイヤーで行われていること、症状へのパッチ適用にとどまっていないこと、回帰がテストでカバーされていること、§3の仕様判断に根拠があることを確認します。これに合格するまでは「完了」と報告できません。機能に影響しない自明な修正（誤字、ログ／コメントのテキスト修正、高速モード）では、フルスキルを起動せず、その場で簡潔に確認してもかまいません。§1と同様です。

本番コードの修正では、§4の前に $changes-review の ToDo も追加します（検証済みの修正によって差分が変わる可能性のある、広範なコードレビューです。§4ではその結果を最終確認します）。$changes-review の配置とワークフロー内でのスキップは、以下の共通 Standalone Review Gate の規定に従います。ここを参照し、この要件を重複して記載しないでください。単独実行時の最終的な ToDo の順序： debug-investigate → [fix spine + prove-fix] → spec-check → changes-review (if production code) → why-review。

デバッグの考え方（絶対厳守）

懐疑的な姿勢で、批判的思考と段階的思考を適用してください。すべての主張は追跡可能な証拠を必要とします。確信度が80％を超える場合にのみ実行してください。

• 実行に移す前に、実際のコードトレースで各仮説を検証してください。最初の仮説が正しいと思い込んではいけません。理由：最初の推測はたいてい、原因ではなく、最も目につきやすいものに引きずられる罠です。
• 根本原因に関するすべての主張には、file:line の証拠を含めてください。
• コードトレースで根本原因を証明できない場合は、「仮説であり、未確認」と明記してください。
• 前提を疑ってください：「本当にこれが原因ですか？」→実際の実行経路を追跡してください。
• 網羅性を検証してください：「ほかに要因はありませんか？」→関連するコードパスを確認してください。
• 証拠なしに「これで直るはず」と言ってはいけません。修正が追跡した根本原因に対処していることを検証してください。

⚠️ 必須：確信度と証拠のゲート

必ず、すべての主張について、証拠リストと file:line の根拠を添えて Confidence: X% を明示してください。 95％以上なら制限なく推奨できます。**80～94％**なら注意事項を添えてください。**60～79％**なら不明点を列挙してください。60％未満なら作業を停止し、証拠をさらに集めてください。

徹底的に考え抜いて、オーケストレーションプロトコル、コア責務、サブエージェントチーム、開発ルールに従って、これらの問題の計画を立て、修正を開始してください： $ARGUMENTS

ターゲットルーティング（--target=）

$fix はインテリジェントなルーターです。フラグを指定しない場合は、以下の診断→修正の一連の流れをすべて実行します。--target= を渡すと、自己完結したインライン分岐に処理を限定します。

--target	動作
types	インライン分岐（以下） — TypeScript／型エラーの解決。
ci	インライン分岐（以下） — CI／パイプライン障害のトリアージ。
issue	インライン分岐（以下） — 追跡中の課題／チケットの解決。
logs	インライン分岐（以下） — ログ／スタックトレースに基づくデバッグ。
test	インライン分岐（以下） — 失敗したテストの修正。
ui	インライン分岐（以下） — UI／視覚的な不具合の修正。

--target がない場合（または認識されない値の場合）は、以下のワークフロー全体を実行し、<issues> から適切な専門分野を推定してください。

以前は独立したスキルでした。 --target=ci|issue|logs|test|ui は、以前は個別のスキル /fix-ci、/fix-issue、/fix-logs、/fix-test、/fix-ui でした。現在は $fix のインライン分岐に統合されており、独立した名前は存在しません。

--target=types — TypeScript／型エラーの分岐

tsc --noEmit（または nx build／bun run typecheck／npx tsc）を実行して、すべての型エラーを収集し、次の手順を実施してください。

1. 収集 — 各型エラーを file:line とともに記録します。
2. 分類 — 原因別に分類します。型の欠落、シグネチャの誤り、インポート／エクスポートの問題などです。
3. 根本から修正 — 各値に実際の具体的な型（または unknown と絞り込み用のガード）を指定します。型チェッカーを黙らせるために any を使ってはいけません。any を使うと、根本にある型の欠陥がそのままリリースされます。症状が現れる箇所ではなく、根本原因（誤ったインターフェースやエクスポートの欠落など）を修正してください。理由：any は型チェッカーを黙らせ、型の欠陥をそのままリリースさせてしまいます。
4. tsc --noEmit のエラーがゼロになるまで繰り返します。
5. 🛑 修正前に検証： エラーと根本原因を提示し、ユーザーに直接確認して承認を得てからコードを変更します（ワークフロー内の場合は省略します）。
6. 修正後は $prove-fix を実行し、変更ごとにコードによる証明トレースと確信度スコアを作成します。省略してはいけません。

デバッグの考え方、確信度と証拠のゲート、および以下のすべての SYNC ゲートは、この分岐にもそのまま適用されます。

--target=ci — CI／パイプライン失敗ブランチ

目標： CI／CD パイプラインのログを分析し、設定されている CI プロバイダー／ツールのビルド／テスト失敗を特定して修正します。

主なルール：

• インフラストラクチャのコンテキスト： docs/project-config.json → infrastructure.cicd.tool を読み、CI プロバイダー／ツール（例：azure-devops、github-actions、gitlab-ci）を特定します。対象プロバイダーのパイプライン設定ファイルを確認してください。
• CI 固有の問題（環境変数、Docker、依存関係、ビルド順序）に注目します。
• 修正によってローカル開発に支障が出ないことを確認します。

ワークフロー：

1. debugger サブエージェントを使い、設定済みの CI ツール／API（docs/project-config.json に記載）経由で CI ログを読み取ります。最後に発生した失敗ログ／エラーから逆向きに根本原因を分析し、結果を報告してもらいます。調査結果を .ai/workspace/analysis/{ci-issue}.analysis.md に書き込み、実装前に再読します。
2. 🛑 根本原因と提案する修正を提示 → ユーザーに直接尋ねる → 承認を待ちます。
3. 報告に基づいて修正を実装します。
4. tester サブエージェントを使って検証し、結果を報告してもらいます。
5. テストが失敗した場合は、ステップ 2 から繰り返します。
6. 変更内容を要約し、次のステップを提案します。その後、$prove-fix を実行します。

注： 設定済みの CI プロバイダーの CLI／API を使用してください。GitHub Actions を使用していて gh が利用できない場合は、GitHub CLI をインストールして認証するようユーザーに案内してください。

以下の Debug Mindset、Confidence & Evidence Gate、およびすべての SYNC ゲートは、このブランチにも変更なく適用されます。

--target=issue — 追跡対象の課題／チケットブランチ

目標： 追跡対象の課題（例：GitHub の issue）として報告されたバグを、完全な追跡可能性を確保しながら調査・修正します。

アクティブゴールの読み込み（根本原因の調査前）： SYNC:goal-contract-satisfaction-loop に従ってアクティブな Goal Contract を解決します（アクティブな計画 goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → issue から作成）。チケットの受け入れ基準を保存済みの成功基準に対応付け、修正後に証拠と未解決のギャップを Iteration Log に追記します。必須基準が FAIL のまま残っている場合、クローズはできません。

主なルール：

• 追跡可能性を確保するため、修正を issue に関連付けます。
• 修正が issue に記載された具体的な再現手順に対処していることを確認します。

ワークフロー：

1. debug-investigate スキルを有効にして、そのワークフローに従います。この手順によって、この問題に対する Root-Cause Prerequisite Gate を満たします。その報告のパスを、ゲートの §2 の証拠として記録します。包括的なガイドラインについては .claude/docs/AI-DEBUGGING-PROTOCOL.md を参照してください。
2. 構造化された分析には .ai/workspace/analysis/issue-[number].analysis.md の外部メモリーを使用します。修正を提案する前に、分析ファイル全体を再読してください。
3. 🛑 根本原因と提案する修正を提示 → ユーザーに直接尋ねる → 実装前に承認を待ちます。
4. 実装し、その後 $prove-fix を実行します。

単独レビューゲート（ワークフロー外のみ）： 単独で行う本番コードの修正（no-flag spine（上記の Standalone Mode Minimum Contract）、または $fix --target=issue）では、$changes-review タスクの追跡項目を追加し、最後の changes-review ゲートとして、契約の §4 にある $why-review の最終承認の直前に配置します（spec-check → changes-review → why-review）。ワークフロー内では、手順に $changes-review が含まれるため省略します。

以下の Debug Mindset、Confidence & Evidence Gate、およびすべての SYNC ゲートは、このブランチにも変更なく適用されます。

--target=logs — ログ／スタックトレースの分岐

目標： アプリケーションログを分析して、実行時エラーや予期しない動作を診断し、修正します。

主なルール：

• ログのパターンに注目します。スタックトレース、エラーコード、タイミングの異常などです。
• ログとソースコードを照合して、実際の根本原因を特定します。

ワークフロー：

1. ./logs.txt が存在するか確認します。ない場合は、プロジェクトのスクリプト設定（package.json、Makefile、pyproject.toml、…）で永続的にログをパイプするよう設定します。Bash/Unix では 2>&1 | tee logs.txt を追加し、PowerShell では *>&1 | Tee-Object logs.txt を追加します。コマンドを実行してログを生成します。
2. debugger サブエージェントを使って ./logs.txt を分析します。Grep の head_limit: 30 で読み込みます（末尾の30行。必要に応じて増やします。ファイル全体の読み込みは避けてください）。分析結果を .ai/workspace/analysis/{issue-name}.analysis.md に書き込みます。修正前に再読します。
3. scout サブエージェントを使って問題の正確な発生源を特定し、報告します。
4. planner サブエージェントを使って実装計画を作成し、報告します。
5. 🛑 根本原因と修正計画を提示し、ユーザーに直接確認して、承認を待ちます。
6. 修正を実装します。
7. tester サブエージェントを使って検証し、報告します。
8. code-reviewer サブエージェントを使って変更をレビューし、報告します。
9. テストに失敗した場合は、ステップ3から繰り返します。
10. 概要を報告し、次のステップを提案します。その後、$prove-fix を実行します。

以下の Debug Mindset、Confidence & Evidence Gate、およびすべての SYNC ゲートは、この分岐にも変更なく適用されます。

--target=test — テスト失敗の分岐

目標： テストスイートを実行して失敗を分析し、根本原因となっているコードまたはテストの問題を修正します。

アクティブな目標の確認（修正前）： SYNC:goal-contract-satisfaction-loop に従ってアクティブな Goal Contract を解決します（アクティブな計画の goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → 報告されたテスト失敗から作成）。失敗したテストの証拠（修正前）と成功したテストの証拠（修正後）を、Iteration Log に保存された成功基準に照らして対応付けます。保存された必須基準を満たさないままテストスイートに合格しても、ループを完了したことにはなりません。

主なルール：

• コードのバグと、誤ったテストの期待値を区別します。
• 修正後にテストを再実行し、すべて合格することを確認します。
• 統合テストのレビューや作成を行う前に docs/project-reference/integration-test-reference.md を読みます。失敗を診断する際は、期待される動作の背景について docs/specs/ を参照します。

ワークフロー：

1. tester サブエージェントを使ってコードをコンパイルし、構文エラーがあれば修正します。
2. tester サブエージェントを使ってテストを実行し、報告します。失敗の分析結果を .ai/workspace/analysis/{test-issue}.analysis.md に書き込みます。修正前に再読します。
3. テストに失敗した場合は、debugger サブエージェントを使って根本原因を特定し、報告します。
4. planner サブエージェントを使って実装計画を作成し、報告します。
5. 🛑 根本原因と修正計画を提示し、ユーザーに直接確認して、承認を待ちます。
6. 計画を段階的に実装します。
7. tester サブエージェントを使って検証し、報告します。
8. code-reviewer サブエージェントを使って変更をレビューし、報告します。
9. テストに失敗した場合は、ステップ2から繰り返します。
10. 概要を報告し、次のステップを提案します。その後、$prove-fix を実行します。

以下の Debug Mindset、Confidence & Evidence Gate、およびすべての SYNC ゲートは、この分岐にも変更なく適用されます。

--target=ui — UI／視覚的な不具合のブランチ

目標： レイアウト、スタイル、レスポンシブ対応、視覚的なバグなど、UI／UX の問題を診断して修正します。

主なルール：

• テンプレート要素では常に BEM クラスを使用します。
• レイアウトの問題を修正する際は、レスポンシブのブレークポイントを確認します。
• 事前読み込み（デザインシステム）： docs/project-config.json から designSystem.canonicalDoc と tokenFiles を読み込み、実際のトークン名（--brand-*、$brand-*）と標準のコンポーネントクラスを使用して修正します。値を独自に作り出してはいけません。

必須スキル（優先順）： ui-ux-pro-max（デザインインテリジェンス DB）→ web-design-guidelines（原則）→ design --lane=marketing（実装パターン）。

ワークフロー：

最初に — ui-ux-pro-max の検索を実行し、背景や一般的な問題を把握します。

python $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "<product-type>" --domain product
python $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "<style-keywords>" --domain style
python $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "accessibility" --domain ux
python $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "z-index animation" --domain ux

ユーザーがスクリーンショットや動画を提供した場合は、visual analysis tooling スキルを使って問題を詳しく説明し、開発者が根本原因を予測できるようにします。

🛑 UI の根本原因を特定したら、調査結果と修正案を提示し、ユーザーに直接確認して承認を待ってからコードを変更してください。

1. ui-ux-designer サブエージェントを使い、デザインガイドライン（designSystem.canonicalDoc）に沿って段階的に修正を実装します。
2. （ページ全体ではなく）正確な親コンテナーのスクリーンショットを撮影し、適切な Gemini スキル（visual analysis tooling、video-analysis、または document-extraction）で分析します。結果がデザインガイドラインに一致し、すべての問題に対処できるまで繰り返します。
3. ブラウザー自動化ツールを使って、修正がデザインガイドラインに一致していることを確認します。
4. tester サブエージェントを使ってビルドとテストを実行し、結果を報告します。すべてのテストに合格するまで繰り返します。
5. ユーザーの承認後： project-manager と docs-manager の各サブエージェントを並行して実行し、計画の進捗と ./docs を更新します。さらに、project-manager に ./docs/project-roadmap.md のプロジェクトロードマップを作成または更新させます。
6. 概要を報告し、次のステップを提案します。その後、$prove-fix を実行します。

以下のすべての SYNC ゲートと、デバッグの考え方、確信度と根拠のゲートは、このブランチにもそのまま適用されます。

ワークフロー：

ユーザーがスクリーンショットや動画を提供した場合は、visual analysis tooling スキルを使って問題を詳しく説明し、開発者が説明から根本原因を予測できるようにします。

リクエストに対応する

あらゆることを問い直す： 質問でユーザーに直接確認するツールを使い、ユーザーのリクエスト、制約、真の目的を十分に把握できるよう掘り下げて質問します。思い込みで進めず、完全に確信できるまで確認してください。

• 未解決の疑問があれば、質問でユーザーに直接確認します。
• 質問は一度に 1 つずつ行い、次の質問をする前に回答を待ちます。
• 質問がなければ、次のステップに進みます。

⚠️ 修正前の検証（必須）： 根本原因と計画を作成した後、調査結果と修正計画を必ずユーザーに提示し、質問で直接確認して、コードを変更する前に明示的な承認を得てください。ユーザーに知らせずに修正してはいけません。 終点から始点へのトレースゲート： 複雑なバグ、検証の失敗、古い／誤った最終出力、または動作を変更する修正では、根本原因の計画に Debugger Trace: End -> Start、データ供給経路、仮説マトリクス、修正を担当するレイヤー、前方収束の証明を必ず含めてください。含まれていない場合は、計画に基づいてコードを変更する前に停止し、$debug-investigate または $investigate を実行してください。（根本原因の前提条件ゲートによって呼び出し時にすでに必須となっていますが、このゲートでは作成されたトレースの 内容 を再確認します。）

問題を修正する

アクティブな目標を確認する（根本原因の調査前）： SYNC:goal-contract-satisfaction-loop に従って、アクティブなゴール契約を特定します。アクティブな計画の goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → 報告された問題をもとに .claude/templates/goal-contract-template.md から作成します。保存された成功基準が「修正済み」の定義です。ローカルで修正できたことを証明しても、保存された必須基準を満たしていなければ、完了ではありません。証明後、根本原因、証拠、残っている目標の未達事項を Iteration Log に追記します。小規模な修正では、ユーザーが承認した理由をゴールファイルに記録すれば、より深いゲートを省略できます。

sequential-thinking スキルを使い、複雑な問題を順序立てた思考ステップに分解します。 問題に取り組むには problem-solving スキルを使います。 スキルカタログを分析し、プロセス中に必要なほかのスキルを有効にします。

1. debugger サブエージェントを使って根本原因を特定し、メインエージェントに報告します。この問題について Root-Cause Prerequisite Gate ですでに $debug-investigate が実行されている場合は、このステップを省略します。そのレポートでこのステップを代替できるため、診断をやり直さず、ステップ 3（計画）から再開します。— 理由：再診断すると、手順の中核を二重に実行することになります。 1.5. 調査結果を .ai/workspace/analysis/{issue-name}.analysis.md に記録します。修正を計画する前に、ファイル全体を読み直します。 1.6. レポートに、最終的な症状 → リーダー → ストレージ／プロジェクション → ライター → コンシューマー／ジョブ → プロデューサー／発生源、すべてのフィーダーパス、仮説マトリックス、修正を担当するレイヤー、およびフォワードコンバージェンスの証明が含まれていることを確認します。
2. 必要に応じて、researcher サブエージェントを使ってインターネットで根本原因を調査し、報告を受けます。
3. planner サブエージェントを使い、各レポートに基づいて実装計画を作成してもらい、報告を受けます。
4. 🛑 根本原因と修正計画を提示し、ユーザーに直接確認して、承認を待ちます。
5. $plan-execute SlashCommand を使って、計画を段階的に実装します。
6. 最終レポート：

• 変更の概要をユーザーに報告し、簡潔に説明します。使い始める方法を案内し、次のステップを提案します。
• Git にコミットしてプッシュするかユーザーに確認します。希望する場合は、git-manager サブエージェントを使います。

• 重要： レポートは文法より簡潔さを優先して書きます。
• 重要： 未解決の疑問があれば、レポートの最後に列挙します。

忘れないでください：

• ビジュアルアセットが必要な場合は、その都度 visual analysis tooling スキルを使って画像を生成します。

• 生成されたアセットを読み込み、visual analysis tooling スキルを使って要件を満たしていることを確認します。

• 背景の削除、調整、トリミングなどの画像編集には、必要に応じてメディア処理ツールを使います。

• 修正後は必ず $prove-fix を実行してください。変更ごとに、信頼度スコア付きのコード証明トレースを作成します。決して省略しないでください。

Spec-Loop 完了ゲート（標準仕様：SYNC:spec-loop-discipline）。 変更対象の不変条件についてループが完了するまで、修正は完了ではありません。（1）バグに違反していた §4 の [HARD] ルール／§5 の不変条件すべてに対して、境界での反例を含む全称量化されたプロパティ TC（「{domain} のすべての入力に対して、{invariant} が成立する」）があること。単一の再現例だけでは不十分です（これが §3 の回帰 TC に求められるプロパティの基準であり、単なる例示ケースではありません）。（2）修正したコアロジックの行がミューテーションによって検出されること。変更行のミュータントが残る場合、検出するテストが欠けており、バグが気付かれないまま再発する可能性があります（行カバレッジ率ではなく、MUTATION-SCORE の基準です）。（3）§3 の仕様の正しさに関する判断と、ガードテスト（Dual-Feedback）の両方に調査結果が反映されていること。どちらもないコードだけのパッチでは、問題の根本が文書化されません。修正完了を宣言する前に、仕様、テスト、コードをまとめて再検証します。

---

次のステップ（単独実行の場合：Minimum Contract の完了後。ワークフロー内の場合は省略。）

根本原因の前提条件ゲートとスタンドアロンモードの最小契約は、任意ではなく、質問でもありません — スタンドアロンの$fixはすでにdebug-investigate（ゲートによって強制）→ 修正の主要手順 → $prove-fix → 条件付きの$specチェック →（本番コードの場合は$changes-review）→ 最終承認としての$why-reviewを自動実行しています。これらを実施するかどうか、ユーザーに再度尋ねてはいけません。これらは保証される最低限の手順です。

その最低限の手順を満たした後は、 MUST ATTENTION は、最低限の範囲を超える内容を提示するため、必ずユーザーに直接尋ねてください（決定するのはユーザーです）。

• 「完全なワークフローを続行（推奨）」 — ここから最適なワークフロー（例：workflow-bugfix）に引き継ぎ、最低限の主要手順では省略されている残りのゲート（plan-validate、integration-testの作成／レビュー／検証、production-readiness-review、security-review、changelog、docs-update）を追加します。
• 「$test」 — 修正をコンテキスト内で検証するため、テストスイート全体を実行します。
• 「コミットしてプッシュ」 — 検証・レビュー済みの変更をgit-managerサブエージェントに引き継ぎます。
• 「ここで停止」 — 最小契約は満たされています。以降はユーザーが引き継ぎます。

すでにワークフロー内にいる場合は、契約とこのメニューの両方を省略してください。ワークフローの順序で、診断、仕様の同期、レビュー、次の手順が処理されます。

[IMPORTANT] 作業を始める前に、タスク管理を使って、各ファイルの読み取りを含むすべての作業を小さなタスクに分割してください。長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合は、スキップするかどうかを必ずユーザーに尋ねてください。

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

終点から始点へたどるデバッガートレース — 単純ではないバグ、検証の失敗、リグレッションの修正、動作を変更するコード、またはコードの流れが不明瞭な場合は、修正を提案する前に、観測された最終状態から逆方向にたどってください。

1. フレーム0：観測された最終状態 — ユーザーに表示された出力、失敗したアサーション、ログ行、永続化された値、APIレスポンス、レンダリングされたUI、集計バケットを正確に特定します。それを生成したリーダー／クエリ／レンダラーを、file:lineの根拠とともに記録します。
2. 一度に1ホップずつ逆方向にたどる — 最終リーダー → プロジェクション／キャッシュ／ストレージ → ライター → コンシューマー／ハンドラー／ジョブ → プロデューサー／呼び出し元 → 元のトリガーの順に追跡します。各ホップで、入力、変換、出力、所有者、根拠を記録します。
3. すべての供給経路を列挙する — リトライ、非同期処理、キャッシュ、バックグラウンド処理、別のUI／API経路を含め、最終経路に書き込む可能性がある上流のプロデューサー／呼び出し元／イベント／ジョブをすべて見つけます。各経路を、検証済み、除外済み、または未解明として記します。
4. 仮説マトリクスを作成する — 妥当な原因ごとに、裏付ける根拠、反証する根拠、再現／検証方法、影響範囲、ステータス（primary、contributing、ruled out、latent）を列挙します。競合する原因が明示的に解決されるか、範囲を限定されるまで修正してはいけません。
5. 修正を担うレイヤーを選ぶ — 不変条件の所有者と、下流のすべてのコンシューマーを保護する最も低い共通地点を特定します。不変条件の所有者がその地点でない限り、症状が現れる箇所での修正は却下します。
6. 前方向に収束することを証明する — 修正を選んだ後、始点から終点まで改めてたどり、修正された状態が観測された最終出力にどう到達するかを示します。各根本原因を修正の各部分に、各修正部分をテスト／証明に対応付けます。

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

絶対にしてはいけないこと： 最初に疑わしいコード経路から調べ始めること。複数のプロデューサーを1つの「フロー」にまとめること。読み取りモデルを証明せずに、重複する症状を重複レコードとして扱うこと。除外済みの仮説を飛ばすこと。 根本原因のデバッグ — 当てずっぽうではなく、体系的に進めます。

1. 再現 — エラーメッセージ、スタックトレース、スクリーンショットなどの証拠で、問題が存在することを確認します
2. 切り分け — 二分探索とグラフ追跡を使って、対象のファイル／関数／行を絞り込みます
3. 追跡 — 入力から障害発生箇所までのデータフローをたどります。推測せず、実際のコードを読みます。
4. 仮説の立案 — 確信度（％）を添えて仮説を立てます。それを裏付ける証拠、または反証する証拠を示します
5. 検証 — 対象を絞った grep／読み取りで仮説を検証します。一度に変更する変数は1つにします。
6. 修正 — 症状ではなく根本原因に対処します。グラフの connections を使って、修正によって呼び出し元が壊れないことを確認します

絶対にしてはいけないこと： 証拠なしに推測すること。原因ではなく症状を修正すること。再現の手順を省略すること。

ネストされたタスクの展開ルール — ワークフローステップから呼び出す場合、[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. 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. すべての主張について、file:line、grep の検索結果、またはフレームワークのドキュメントを引用してください。
2. 確信度を明示してください。80％超なら自由に行動し、60〜80％なら先に検証し、60％未満なら推奨してはいけません。
3. アーキテクチャ変更では、サービス間の検証が必須です。
4. 「証拠が足りません」は正当であり、期待される出力です。

ブロック解除条件： - [ ] 証拠のファイルパス（file:line） - [ ] grep 検索を実施した - [ ] 3つ以上の類似パターンを見つけた - [ ] 確信度を明示した

証拠なしでの使用禁止： 「明らかに」「私はそう思います」「〜のはずです」「おそらく」「これは〜が原因です」 未完了の場合 → 次を出力してください："証拠が不十分です。検証済み：[...]。未検証：[...]。" 修正レイヤーの責任 — クラッシュが発生した箇所では絶対に修正しないでください。全体のフローをたどり、責任を持つレイヤーで修正してください。

AI のデフォルトの動作：場所 A でエラーを確認 → 場所 A を修正。これは誤りです。クラッシュが発生した箇所は症状であり、原因ではありません。

修正を行う前に必ず実施すること：

1. データフロー全体をたどる — データの発生元からクラッシュ箇所まで、すべてのレイヤー（ストレージ → バックエンド → API → フロントエンド → UI）を通る完全な経路を把握します。不正な状態がどこで入り込むのかを特定してください。クラッシュが発生する箇所ではありません。
2. 不変条件の責任者を特定する — この値が有効であることを保証する契約を持つレイヤーはどこですか？そのレイヤーに責任があります。不変条件を所有する最も低いレイヤーで修正してください。不変条件を利用する最も高いレイヤーではありません。
3. 修正は1か所で、保護は最大限に — 「ここで修正すれば、1回の変更ですべての下流の利用者を保護できるか？」と考えてください。防御チェックのために3つ以上のファイルを変更する必要があるなら、修正するレイヤーが間違っています。さらに下のレイヤーで修正してください。
4. 迂回経路がないことを確認する — すべてのデータフローが修正箇所を通ることを確認します。次の点を調べてください：ファクトリーを介さない直接構築、再検証を伴わないクローン／スプレッド、ドメインモデルでラップされていない生データ、モデルレイヤー外での変更。

次の項目が完了するまで作業を進めてはいけません： - [ ] データフロー全体（発生元 → クラッシュ）を追跡済み - [ ] 不変条件の責任者を file:line の根拠とともに特定済み - [ ] すべてのアクセス箇所を監査済み（grep の件数） - [ ] 修正レイヤーの妥当性を説明済み（大多数の利用者を保護する最も低いレイヤー）

アンチパターン（却下してください）：

• 「クラッシュした箇所で修正する」 — クラッシュ箇所 ≠ 原因箇所です。上流をたどってください。
• 「すべての利用箇所に防御チェックを追加する」 — 防御が散在しているのは、レイヤーが間違っている証拠です。散在するガードを多数追加するより、権威ある1か所で修正してください。
• 「両方修正する方が安全」 — 権威あるレイヤーを1つ選んでください。複数のレイヤーに重複したチェックを設けると、不変条件の責任者について一貫しないメッセージになります。

ソース／テストの乖離を確認してください。 コーディング、修正、デバッグ、調査、テスト、レビューを行う際、ソースの動作が変わった場合は、影響を受けるユニットテスト／統合テスト／E2E テストを確認し、意図した動作に合わせてテストを変更すべきか、ソースの変更が意図しないバグで修正すべきかを、根拠に基づいて判断してください。移行コードのテストは作成しないでください。スキーマ／データ移行は一度だけ実行する処理経路であり、アプリケーションの中核ロジックではありません。 テスト失敗時の責任判定 — テストが失敗した場合（または失敗のデバッグや修正を行う場合）、どちらに問題があるか、つまり ソースコードかテストコードか を判断することが重要です。スイートをグリーンにすることよりも、正しい判定を下すことのほうが重要です。すべてのデバッグ／修正／テストスキルに同じように適用されます。

1. どちらにも手を加える前に暫定判定を行う。 観察された証拠を SOURCE-WRONG、TEST-WRONG、TEST-NOT-OPTIMAL、ENVIRONMENT-BLOCKED、AMBIGUOUS のいずれかに分類し、その後 $debug-investigate を実行して、編集前に処理を最後から最初へたどります。スイートを再びグリーンにすることは目的ではありません。
2. 仕様とソースの両方に照らして三角測量する。 動作を対象とする Feature Spec（例：docs/specs/** — §3 ACs／§4 BRs／§5 invariants／§8 TCs）がある場合、それを 意図された 動作を判断する際の決め手とし、本番ソースと失敗したテストの両方を仕様と比較します。仕様がない場合は、文書化された意図／受け入れ基準／呼び出し元との契約を基準にします。これらの証拠から、誤っているのがソースかテストかを判断します。
3. どちらに問題があるかを分類し、誤っている側を根本から修正する。
   • SOURCE-WRONG — 本番コードが仕様の意図する動作または明確な不変条件に違反している → 所有するレイヤーでソースを修正し、問題を検出したテストは維持または強化します。
   • TEST-WRONG — テストに古い、または誤ったアサーション、セットアップ、期待値が含まれ、意図する動作と矛盾している → テストを根本から修正します。グリーンにするためにアサーションを弱めたり、スキップを追加したり、タイムアウトを緩和したりしてはいけません。
   • TEST-NOT-OPTIMAL — 意図する動作は妥当だが、テストの接点、タイミング、またはアサーションのシグナルが不安定である → 不変条件を弱めずにテストを改善します。
   • ENVIRONMENT-BLOCKED — インフラストラクチャまたは外部状態がソース／テストの判定を妨げている → 診断情報を保持し、環境が正常になるまで変更を停止します。
   • AMBIGUOUS — 証拠または意図する動作から、どちらが問題の所有者かを安全に判断できない → 編集前にユーザーまたは正式な責任者に確認します。
   • 壊れたソースに合わせてテストを変更してはいけません。また、壊れたテストを満たすためにソースを変更してはいけません。（マイグレーションコードは除きます。スキーマ／データのマイグレーションは一度だけ実行される処理であり、コアアプリケーションロジックではありません。）
4. 意図する動作が不明確な場合はユーザーに確認する。 動作を対象とする仕様がない場合、仕様に記載がない場合、またはどちらが正しいか仕様が曖昧な場合は、編集前に停止してユーザーに直接確認する（または正式な仕様の責任者に相談する）。スイートを通すためだけに、ソースかテストかを黙って選んではいけません。

現在どちらが通るかではなく、意図する動作に合わせます。グリーンが、まさにバグを含んでいることもあります。 AI のミス防止 — あらゆるタスクで避けるべき失敗パターン：

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

重要・必ず注意 データフロー全体をたどり、クラッシュが起きた箇所ではなく、責任を持つレイヤーで修正してください。?. を追加する前に、すべてのアクセス箇所を監査してください。

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

重要・必ず注意 すべての主張に file:line 形式の根拠を引用してください。確信度が80％を超えた場合に実行し、60％未満の場合は推奨しないでください。

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

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

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

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

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

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

• 必須 プロジェクト設定、ルートの指示ファイル、または必須の参照ドキュメントが欠けているか古い場合は、通常のプロジェクト固有の作業に着手する前に、$project-init または適切な下位レベルの手順を自動で実行してください。 重要：必ず注意 デバッガートレースゲート：重要度の高いバグ修正、調査、レビュー作業では、観測された最終出力から始めて、reader → storage/projection → writer → consumer/job → producer/trigger の順に遡ってトレースします。修正に着手する前に、すべての入力経路と仮説を列挙します。トレース、仮説マトリクス、修正を担当するレイヤー、前方への収束の証明がそろうまでは、作業はブロックされます。

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

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

• 必須 作業を開始する前に、有効な Goal Contract を解決します（有効なプランの goal.md → plans/goals/{YYMMDD-HHmm}-{slug}/goal.md → 現在のリクエストから作成）。編集前に、保存済みの成功基準を読みます。

• 必須 実行後に反復の証拠を追記します。PASS を報告する前に Goal Satisfaction マトリクス（PASS/FAIL/BLOCKED）を出力し、検証済みの FAIL があれば繰り返し、進展がない状態が続く場合やブロッカーがある場合はエスカレーションします。Goal ファイルにシークレットを保存してはいけません。

プロジェクトプロトコルオーバーレイ — このスキルを実行する前に、このスキルに適用される 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 にある一致した本文のみを読みます。本文が存在しないか、不正な形式の場合は報告し、再構築してはいけません。オーバーレイは追加のみ（このスキル独自のルールを置き換えてはならない）であり、ブリーフであって権限を引き上げるものではありません。同じ具体性で矛盾する場合は、ユーザーに提示します。

クロージング時のリマインダー

重要：必ず注意 — Goal： 問題の根本原因を取り除きます。file:line の証拠を伴って末端から起点までトレースし、原因箇所ではなく、不変条件を管理する最下層で修正します。その後、$prove-fix で修正を証明し、症状だけでなく根本原因が解消されたことを確認します。

必ず注意 — 適用中のプロトコル（このスキルに含まれる SYNC/shared ブロックの簡潔な要約）：

• 最終出力から始めるデバッガートレース： 観測された最終出力から開始し、修正する前に、すべての入力経路を遡って追跡します。
• 根本原因のデバッグ： 再現 → 切り分け → 追跡 → 仮説立案 → 検証 → 修正の順に進め、症状ではなく原因を修正します。
• ネストされたタスクの作成： 親ワークフローの行で子フェーズの追跡を代替することはできません。フェーズを展開してリンクします。
• プロジェクト参照ドキュメントのガイド： 対象作業に取りかかる前に、必須のプロジェクト参照ドキュメント（必ず lessons.md を含む）を読みます。
• タスク追跡と外部レポート： タスク追跡を初期化し、計画とレビューの所見を plans/reports/ に逐次保存します。
• 批判的思考： 批判的かつ段階的に思考し、主張ごとに追跡可能な根拠を示します。確信度が80%を超えた場合に対応します。
• まずコードを理解する： 変更を加える前に、3つ以上のパターンを検索し、コードを読みます。
• 根拠に基づく推論： すべての主張に file:line 形式の根拠を示します。確信度が60%未満の場合は、推奨してはいけません。
• 修正レイヤーの説明責任： データフロー全体を追跡し、クラッシュ箇所ではなく、責任を担うレイヤーで修正します。
• ソースとテストのずれの確認： ソースの動作を変更した場合、影響を受けるテストも変更する必要があるか、根拠に基づいて判断します。
• AIのミス防止： 生成した内容を根拠と照合し、下流の参照を追跡し、影響を受けるすべての出力を検証します。コンテキストが失われた後は読み直し、曖昧さを明らかにします。 重要・必ず注意 根本原因の前提条件ゲート（ブロッキング、最優先） — 直接の $fix 呼び出し（フラグなしの基本手順およびすべての --target= 分岐）は、このセッションで $debug-investigate がこの問題を調査し、その証拠が現在のタスクリストの行または記述された調査レポートに示されるまで、コードを編集してはいけません。記憶は証拠になりません。別の症状に対する過去の調査も該当せず、親ワークフローの行だけでは診断ステップが実行された証明になりません。条件を満たしていない場合は、まず $debug-investigate を実行し、その後、計画ステップから再開してください — 理由：これを行わないと、原因を追跡しないまま最初の編集を行い、症状の箇所にパッチを当てることになります 重要・必ず注意 症状を最初から最後まで追跡して、不変条件を所有するレイヤーを特定し、そのレイヤーで修正してください — クラッシュ箇所で修正してはいけません。理由：クラッシュ箇所は症状です。不正な状態はより下位のレイヤーで発生するため、そこで修正すれば、その下流のすべての利用者を保護できます 重要・必ず注意 すべての主張に Confidence: X% と file:line の証拠を示してください — 95％以上は推奨、80～94％は注意事項を付記、60～79％は不明点を列挙、60％未満なら停止してください。理由：推測でパッチを当てると、誤ったレイヤーを修正し、問題の本質を残したままリリースすることになります 重要・必ず注意 🛑 修正前に検証 — 根本原因と計画をユーザーに直接提示して承認を得てから、コードを変更してください（ワークフロー内の場合に限り省略可能）。理由：黙って修正すると、取り消せないコード変更に対する人間の確認ゲートを迂回してしまいます 重要・必ず注意 まず --target= で分岐してください — {ci|issue|logs|test|types|ui} の各分岐は、それぞれ独自の診断と $prove-fix を含む自己完結型です。フラグがない場合は、診断から修正までの基本手順をすべて実行してください。理由：各分岐で、独立した基本手順の §1／§2 を再実行してはいけません 重要・必ず注意 デフォルトモードは厳格（完全な厳密さ）です。高速モードへの切り替えは、バグが本当に些細である場合（デフォルトモードのポリシーの5条件をすべて満たす場合）に限ります。迷った場合は厳格モードを選んでください。理由：些細でないバグの診断を省くと、症状だけが修正され、問題の本質が残ります 重要・必ず注意 親ワークフローなしの単独実行では、基本手順 debug-investigate → fix + prove-fix → $spec correctness check → $changes-review (production code) → $why-review を自分で組み立ててください。ワークフロー内ではこの手順を省略します。ただし、根本原因の前提条件ゲートは必ず守ってください。このゲートでは、手順内の debug-investigate ステップがこの問題に対して実行された証拠が引き続き必要です。理由：単独実行では診断、仕様の同期、レビューを行う手順が提供されず、コンテナの行だけでは診断ステップが実行された証明になりません 重要・必ず注意 修正後に $prove-fix を実行してください — 変更ごとに、確信度スコア付きのビルドコード証明トレースを作成してください。省略してはいけません。理由：「これで直るはず」という見込みだけでは、前向きな収束の証明がなく、未検証のままです 重要・必ず注意 仕様ループの完了 — 違反した §4／§5 の不変条件に対して全称量化されたプロパティ TC と境界ケースを用意し、変更した行がミューテーションテストで検出され、指摘事項が仕様とテストの両方に反映される（Dual-Feedback）まで、修正は完了していません。理由：コードだけのパッチでは、バグのケースが文書化されず、気付かれないまま再発する可能性があります 重要・必ず注意 作業を始める前に、小さなタスクに分けて追跡用の TODO を作成してください（1 回の読み取りにつき 1 タスク）。コンテキストを失った場合は、最初に現在のタスクリストを確認して作業を再開し、重複させないでください。理由：長いデバッグファイルはコンテキストを使い果たし、調査結果が気付かれないまま失われる原因になります 重要・必ず注意 対象作業に入る前に、必須のプロジェクト参照ドキュメントを読んでください（lessons.md は常に、テスト分岐では integration-test-reference.md、動作については docs/specs/）。理由：プロジェクトの規約は、一般的なデバッグの前提より優先されます 重要・必ず注意 テストが失敗した場合（--target=test または何らかのテスト失敗）は、修正の方向性を決めるために、まず $integration-test-review スキルのプロトコル（アサーションの品質、カバレッジ、仕様↔テスト↔コードの故障ゲート）を読んでください。問題がソースコードの根本原因なのか、テストコードのセットアップ／アサーションの問題なのかを判断してください。理由：この判断をせずに修正すると、誤った側にパッチを当て、不変条件に違反したままテストを成功させる可能性があります 重要・必ず注意 修正前に類似パターンを3つ以上検索し、既存コードを読んでください。近くにあるパターンをコピーする前に、適合性を評価してください。理由：最も近い例が、前提条件まで一致するとは限りません 重要・必ず注意 作業品質を検証する最終レビューの TODO を追加し、その注意書きがなければ同じ障害モードが再発する場合は、根本原因の教訓を $learn で抽出してください 合理化を防ぐ：

言い逃れ	反論
「根本原因は明らかだから、パッチを当てるだけ」	まず file:line を示しながら、末端から起点へたどって不変条件の所有者を特定してください。明白に見える箇所は症状にすぎません。
「すでに調査しました」	この症状に関する現在のタスクリストの行、または調査レポートを提示してください。記憶は証拠ではありません。圧縮後も信念は残りますが、調査結果は残りません。
「ワークフローが実行中で、診断も済んでいます」	親の行はコンテナーであり、証拠ではありません。この問題に対して_完了した_ debug-investigate ステップを示してください。そうしないとゲートが発動します。
「--target= で範囲を絞っているから、トレースは不要」	すべての分岐は Root-Cause Prerequisite Gate を通過します。debugger／tester サブエージェントのステップは、末端から起点へのトレースではありません。
「クラッシュする箇所を修正する」	クラッシュ箇所 ≠ 原因箇所です。不変条件を所有し、すべての利用側を保護する最も低いレイヤーで修正してください。
「?.／ガードを追加して先に進む」	防御的チェックが散在しているなら、レイヤーが間違っています。多数のガードより、権威ある修正を1つ行うほうが優れています。
「十分な自信があるので、証拠は不要」	file:line と Confidence % がなければ主張はできません。60% 未満なら停止して証拠を集めてください。
「小さな修正だから、承認ゲートは不要」	🛑 Validate-Before-Fix は単独でも必須です。根本原因と計画を提示し、承認を得てください。
「テストに合格したので、修正は完了」	プロパティ TC と境界ケースを追加し、変更行をミューテーションテストで検出し、仕様 ↔ テストを連携させる（Dual-Feedback）まで完了ではありません。
「コードベースはすでに検索しました」	file:line の証拠を示してください。証明がなければ、検索していないのと同じです。

IMPORTANT MUST ATTENTION このセッションで $debug-investigate がこの問題をトレースするまで、コードを編集してはいけません。必要なのは証拠（タスクの行／レポート）であり、記憶ではありません。 IMPORTANT MUST ATTENTION クラッシュ箇所を修正してはいけません。末端から起点へたどって不変条件の所有者を特定し、その箇所を修正してください。 IMPORTANT MUST ATTENTION すべての主張について Confidence: X% と file:line を明示してください。60% 未満なら停止してください。 IMPORTANT MUST ATTENTION コードを変更する前に 🛑 Validate-Before-Fix の承認を得て、その後に $prove-fix を実行してください。どちらも省略してはいけません。

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

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

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