cook

Codex 互換性に関する注意：

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

Codex プロジェクト参照ドキュメントの読み込み（フックなし）

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

必ず読むもの：

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

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

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画または TC マッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：変更したファイルに応じて、code-review-rules.md と上記のドメインドキュメント

すべてのドキュメントを無差別に読まないでください。docs-index-reference.md から始め、タスクに関連するファイルだけを開いてください。

[BLOCKING] スキルの手順は宣言された順序で実行してください。ユーザーの明示的な承認なしに、手順を省略、並べ替え、統合してはなりません。 [BLOCKING] 各手順またはサブスキル呼び出しの前に、タスク追跡を更新してください。開始時は in_progress、終了時は completed にします。 [BLOCKING] 完了またはスキップした各手順には、必ず証拠または明示的なスキップ理由を記載してください。 [BLOCKING] Task ツールを利用できない場合は、同じステータス遷移を伴う同等の手順別プラン追跡を維持してください。

クイックサマリー

目標： 綿密な調査、包括的な計画、最高品質の検証を通じて機能を実装します。

ワークフロー：

1. 調査 — 複数のリサーチャーサブエージェントを使用した綿密な調査
2. 計画 — $plan を使用した詳細な計画。ユーザーの承認が必要です
3. 実装 — コードレビューと SRE レビューを完全に実施して遂行
4. 検証 — すべてのテストを実行し、変更をレビューして、ドキュメントを更新

主なルール：

• 徹底性を最大限に高める：調査 → 計画 → 実装 → レビュー → テスト → ドキュメント
• 計画段階でユーザーの承認が必要です
• 作業を todo タスクに分割し、最後にセルフレビューのタスクを追加してください

第一原則 — 変更しやすさ

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

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

• 変更コストを上げる「ベストプラクティス」は退けてください（時期尚早な抽象化、 憶測に基づく汎用化、漏れのある間接化、見返りのない儀式的な手順）。
• 指摘では本当の敵に名前を付けてください。結合、隠れた状態、重複した 知識、不明確な意図、早すぎる段階で明らかにされる取り消し不能な決定です。
• 変更しやすいシンプルな設計は、変更しにくい洗練された設計に勝ります。

以下の具体的なルール、パターン、チェックリストを適用する前に、必ずこの観点を当てはめてください。下位のルールによって変更コストが上がる場合は、この原則を優先します。

---

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

デフォルトモードは HARD（完全な厳格さ）です。 以下のすべてのセクション（詳細な調査、必須の $plan、完全な code-reviewer レビュー、必須のテスト、必須の $docs-update）が、デフォルトで適用されます。

ファストモードへの切り替えは、以下の条件をすべて満たす場合に限ります（タスクが本当に些細な場合）。

• 単一ファイルの編集で、変更が30行以下
• 設計上の選択がない（妥当な方法が一つだけ）
• サービス間への影響、契約の変更、新しい依存関係がない
• 新しいパターンを導入せず、既存のコードベースのパターンに従う
• 既存のテストで変更をカバーしている、または変更が非機能的（誤字、コメント、ログメッセージ）

条件を一つでも満たさない場合は、以下の完全なプロトコルを使用してください。 判断に迷う場合は、デフォルトの HARD を選んでください。些細ではない変更でレビューやテストを省略すると、不具合をリリースすることになります。

ファストモードで省略するのは、次の項目だけです。 researcher サブエージェントのフェーズ（代わりに直接 grep を実行）、必須の code-reviewer レビュー（セルフレビューのみ）、独立したテストフェーズ（その場で検証）。$plan の手順、テストの実行、$docs-update のトリアージは省略しません。

フロントエンド／UI のコンテキスト（該当する場合）

タスクにフロントエンドまたは UI の変更が含まれる場合：

• コンポーネントのパターン：docs/project-reference/frontend-patterns-reference.md
• スタイリング／BEM ガイド：docs/project-reference/scss-styling-guide.md
• デザインシステムのトークン：docs/project-reference/design-system/README.md

これらのタスクは、最大限の検証を行いながら徹底的に考えて計画・実装してください。

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

$ARGUMENTS

モード： 追加調査、詳細な計画、必須のレビュー。

ワークフロー

1. 詳細な調査フェーズ

• 以下を対象に、researcher サブエージェントを2～3個並行して起動します。
  • 技術的アプローチの妥当性確認
  • エッジケース、障害モード
  • セキュリティへの影響
  • パフォーマンスに関する考慮事項
• 包括的なコードベース分析には $scout-ext を使用します。
• 調査レポートはそれぞれ最大150行とします。
• 外部メモリ： すべての調査内容を .ai/workspace/analysis/{task-name}.analysis.md に書き込みます。計画の前にファイル全体を読み直してください。
• 実装前トレースゲート： バグ修正、検証失敗、古くなった／誤った最終出力、リグレッション、または動作を変更する修正計画の場合、計画／参照する分析に Debugger Trace: End -> Start、すべての入力経路、仮説マトリクス、修正を担当するレイヤー、前方収束の証明が含まれていることを必ず確認してください。欠けている場合は停止し、編集を開始する前に不足しているトレースの一覧を提示してください。

実装後、変更したファイルに対して python .claude/scripts/code_graph connections <file> --json を実行し、関連ファイルも更新する必要がないか確認してください。

実装前のグラフトレース

グラフ DB が利用可能な場合は、コードを書く前に影響範囲をトレースしてください。

• python .claude/scripts/code_graph trace <file> --direction both --json — このコードを呼び出す側と、このコードが引き起こす処理
• python .claude/scripts/code_graph trace <file> --direction downstream --json — すべての下流コンシューマー
• これにより、暗黙の依存関係（バスメッセージのコンシューマー、イベントハンドラー）の破壊を防ぎます。

2. 包括的な計画

• すべての調査レポートを使って planner サブエージェントを使用します
• 計画ディレクトリを完全に作成します：
  • plan.md — リスク評価を含む概要
  • phase-XX-*.md — 詳細なフェーズファイル
  • フェーズごとの成功基準
  • ロールバック戦略

3. 検証済みの実装

• 一度に1つのフェーズを実装します
• 各フェーズの後に：
  • 型チェックとコンパイルを実行します
  • 関連するテストを実行します
  • 次に進む前にセルフレビューします

バッチチェックポイント（大規模な計画）

タスクが10件以上ある計画では、人によるレビューを挟みながらバッチで実行します：

1. バッチを実行 — 次の3タスク（またはユーザー指定の件数）を完了します
2. 報告 — 実装内容、検証結果、懸念事項があれば提示します
3. 待機 — 「フィードバックをお待ちしています」と伝えて停止します。自動的に続行してはいけません。
4. フィードバックを反映 — 変更を取り込み、次のバッチを実行します
5. 繰り返す — すべてのタスクが完了するまで続けます

タスクが10件以上ある計画では、チェックポイントを挟まずにすべてのタスクを続けて実行してはいけません。 人によるレビューのため、各バッチの後に停止します。これにより、初期の誤りが後続のタスクに連鎖して拡大するのを防ぎます。

4. 必須テスト

• 完全なテストカバレッジを確保するために tester サブエージェントを使用します
• 次のテストを作成します：
  • 正常系のシナリオ
  • 調査で判明したエッジケース
  • エラー処理の経路
• モックや偽データは使用しません
• すべてのテストが合格するまで繰り返します

5. 必須コードレビュー

• code-reviewer サブエージェントを使用します
• 重大および主要な指摘事項すべてに対応します
• 修正後にテストを再実行します
• 承認されるまで繰り返します

6. ドキュメントの更新

• docs-manager を使用して関連ドキュメントを更新します
• project-manager を使用してプロジェクトのステータスを更新します
• アーキテクチャ上の決定を記録します

7. 最終報告

• すべての変更の概要
• テストカバレッジの指標
• 対応したセキュリティ上の考慮事項
• 未解決の質問（あれば）
• ユーザーにレビューと承認を依頼します

使用する場面

• 本番環境における重要な機能
• セキュリティ上重要な変更
• パブリック API の変更
• データベーススキーマの変更
• サービス間の連携

品質ゲート

ゲート	基準
調査	調査担当者のレポートが2件以上
計画	完全な計画ディレクトリ
テスト	すべて合格し、モックなし
レビュー	重大または主要な指摘事項が0件
ドキュメント	必要に応じて更新

---

次のステップ（単独実行の場合：ユーザーに直接質問して確認する必要があります。ワークフロー内の場合はスキップしてください。）

必須・重要・要確認 — 例外なし： このスキルがワークフロー外で呼び出された場合は、必ずユーザーに直接質問して以下の選択肢を提示します。タスクが「単純」または「明白」に思えるからといって省略してはいけません。決定するのはユーザーです：

• 「完全なワークフローで続行（推奨）」 — ここから続行する最適なワークフロー（機能の実装済み）を検出します。レビュー、テスト、ドキュメントの手順が省略されないようにします。
• 「$code-simplifier」 — 実装を簡素化して整理します
• 「$workflow-review-changes」 — コミット前に変更をレビューします
• 「スキップして手動で続行」 — ユーザーが決定します

すでにワークフロー内にいる場合はスキップしてください。手順の順序はワークフローが管理します。

[IMPORTANT] 作業を開始する前に、ファイルの読み込みごとのタスクも含め、すべての作業を小さなタスクに分割してタスク管理を使用します。これにより、長いファイルを扱う際のコンテキスト消失を防ぎます。単純なタスクの場合は、省略するかどうかを必ずユーザーに確認します。

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関連性、サービス間同期（タスクがビジネスエンティティ／モデルに関係する場合に読みます）（関連する場合は直接読み、フックによって会話文に挿入されたテキストに依存しないでください）
• docs/specs/ — モジュールごとのテスト仕様（既存のTCを読み、実装後に $tdd-spec で生成／更新します）

最終状態から開始するデバッガートレース — 複雑なバグ、検証の失敗、回帰修正、動作を変えるコード、またはコードフローが不明瞭な場合は、修正案を提示する前に、観測された最終状態から逆向きにたどってください。

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

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

禁止事項： 最初に疑わしいコード経路から調査を始めないでください。複数のプロデューサーを単一の「フロー」にまとめないでください。読み取りモデルを証明せずに、重複した症状を重複レコードとして扱わないでください。除外した仮説を飛ばさないでください。

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

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

UI システムのコンテキスト — .ts、.html、.scss、.css ファイルに関わるタスクでは、必ず以下を確認してください：

実装前に必ず注意深く読むこと：

1. docs/project-reference/frontend-patterns-reference.md — コンポーネントの基底クラス、ストア、フォーム
2. docs/project-reference/scss-styling-guide.md — BEM 手法、SCSS 変数、ミックスイン、レスポンシブ対応
3. docs/project-reference/design-system/README.md — デザイントークン、コンポーネント一覧、アイコン

プロジェクト固有のパスについては、docs/project-config.json を参照してください。

グラフを活用した調査 — .code-graph/graph.db が存在する場合は必須です。

必須ゲート： 調査を完了する前に、主要なファイルに対して少なくとも 1 つのグラフコマンドを必ず実行してください。

手順： Grep でファイルを特定 → trace --direction both でシステム全体の流れを把握 → Grep で詳細を検証

タスク	最低限実行するグラフ操作
調査／スカウト	2〜3 個のエントリーファイルに対して trace --direction both を実行
修正／デバッグ	バグのある関数に対して callers_of を実行し、さらに tests_for を実行
機能追加／機能強化	変更対象のファイルに対して connections を実行
コードレビュー	変更した関数に対して tests_for を実行
影響範囲	trace --direction downstream を実行

CLI： python .claude/scripts/code_graph {command} --json。まず --node-mode file を使ってノイズを 10〜30 分の 1 に減らし、その後、詳細を確認するために --node-mode function を使ってください。 ネストされたタスク展開の契約 — ワークフローステップの呼び出しでは、[Workflow] ... の行は親コンテナにすぎません。子スキルは引き続き、可視のフェーズタスクを作成します。

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

以下が完了するまでブロック： 現在のタスクリストの確認、子フェーズの作成、ネストされている場合は親のリンク、最初の子タスクの in_progress への設定。

プロジェクト参照ドキュメントのゲート — タスク追跡の初期化後、対象ファイルやソースファイルの読み取り、grep、編集、分析の前に実行します。プロジェクトのドキュメントは、汎用的なフレームワークの前提に優先します。

1. 対象範囲を特定します。ファイルの種類、ドメイン領域、操作を確認します。
2. トリガーに応じて必要なドキュメントを確認します。常に docs/project-reference/lessons.md、ドキュメントの検索では docs-index-reference.md、レビューでは code-review-rules.md、バックエンド／CQRS／API では backend-patterns-reference.md、ドメイン／エンティティでは domain-entities-reference.md、フロントエンド／UI では frontend-patterns-reference.md、スタイル／デザインでは scss-styling-guide.md と design-system/design-system-canonical.md、統合テストでは integration-test-reference.md、E2E では e2e-test-reference.md、機能ドキュメント／仕様では feature-docs-reference.md、アーキテクチャ／新しい領域では project-structure-reference.md が必要です。
3. 存在する必須ドキュメントはすべて読みます。存在しないドキュメントは該当なしとしてスキップします。[Injected: <path>] のような会話文を、現在のコンテキストにそのドキュメントが含まれている証拠として信頼しないでください。
4. 対象の作業を始める前に、Reference docs read: ... | Missing/not applicable: ... と記載します。

以下が完了するまでブロック： 対象範囲の評価、必須ドキュメントの確認と読み取り、lessons.md の確認、引用の提示。

タスク追跡と外部レポートの永続化 — 実行の前にこれを初期化し、その後、対象やソースの作業に入る前にプロジェクト参照ドキュメントを事前取得します。

1. 対象ファイルの読み取り、grep、編集、分析の前に、簡潔なタスク内訳を作成します。コンテキストが失われた場合は、まず現在のタスクリストを確認します。
2. 作業の前にタスクを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つ以上のパターンを検索する - [ ] グラフをトレースする（graph.db が存在する場合） - [ ] 仮定を根拠と照合して検証する

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

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

モード： TDD 優先 → 既存の TC を Evidence: TBD として参照します。実装優先 → TBD を使用し、後で $tdd-spec が補完します。

• 必須・重要・厳守 — 変更を行う前に、既存のパターンを3つ以上検索し、コードを読むこと。graph.db が存在する場合は、グラフのトレースを実行してください。

• 必須・重要・厳守 — フェーズごとに、TC ID を含む ## Test Specifications を追加すること。新しいタスクを作成する前に、現在のタスクリストを呼び出してください。

• 必須・重要・厳守 — UI を変更する前に、frontend-patterns-reference、scss-styling-guide、design-system/README を読むこと。

• 必須・重要・厳守 — graph.db が存在する場合、重要なファイルに対して少なくとも1つのグラフコマンドを実行すること。パターン：grep → graph trace → grep で検証。

厳守 — 批判的に考え、すべての主張を追跡可能な証拠で裏付けてください。確信度が80%を超えた場合にのみ行動してください。幻覚を防ぐため、推測を事実として提示してはいけません。

厳守 — AI の誤りを防ぐため、全体を見渡してからデバッグし、適切なレイヤーで修正し、コーディング前に曖昧な点を明らかにし、コンテキストの圧縮後にファイルを読み直してください。

• 必須 — 対象の作業に着手する前に、タスク追跡を初期化すること。タスクは一度に1つずつ進める。

• 必須 — 計画／レビューの所見を plans/reports/ に段階的に保存し、ディスク上の内容をもとにまとめる。

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

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

重要・厳守 — デバッガートレースのゲート：複雑なバグ修正／調査／レビューでは、観測された最終出力から始め、reader → storage/projection → writer → consumer/job → producer/trigger の順にさかのぼって追跡する。修正前に、すべての入力経路と仮説を列挙する。次の項目が揃うまで作業は禁止： トレース、仮説マトリックス、修正を担当するレイヤー、前方への収束を示す証拠。

• 必須 — 親ワークフローの行は、子フェーズの追跡の代わりにはなりません。ネストする場合はフェーズを展開し、親と関連付けてください。
• 必須 — オーケストレーターは呼び出し前に子スキルのフェーズを展開し、[N.M] $skill-name — phase のプレフィックスと、同時に1つだけを in_progress にするルールを使用すること。

締めくくりの注意事項

• 必須・重要・厳守 デフォルトモードは HARD です。すべての軽微なタスクの条件を満たす場合に限り、fast mode に切り替えてください
• 必須・重要・厳守 作業を始める前に、タスク管理を使って作業を小さな ToDo タスクに分割してください
• 必須・重要・厳守 新しいコードを作成する前に、コードベースから類似パターンを 3 つ以上検索してください
• 必須・重要・厳守 すべての主張について file:line の根拠を示してください（確信度が 80% を超える場合にのみ実行してください）
• 必須・重要・厳守 作業の品質を検証するための最終レビュー ToDo タスクを追加してください
• 必須・重要・厳守 直接ユーザーに質問して判断を確認してください。自動で判断してはいけません
• 必須・重要・厳守 重要な変更では、code-reviewer によるレビューもテストの実行も決して省略してはいけません

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

---

最後の注意事項 — 変更しやすさが成功の指標です。 あらゆる調査結果、 テスト、リファクタリング、抽象化は、次の問いに答えなければなりません。 これは、 次の変更にかかるコストを下げるでしょうか、それとも上げるでしょうか？ 将来の変更コストを下げないものは採用しないでください。結合、隠れた状態、 重複した知識、意図の不明瞭さこそが真の敵です。名指しで指摘してください。

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

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

[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 を読み、そこに記載されたプロジェクト参照ドキュメントを開いてください。この共有コンテキストとローカルドキュメントが利用可能であれば、サポート対象の AI ツールで実行できます。

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

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

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

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

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