code-no-test

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 を確認し、その後、タスクに関連するファイルのみを開いてください。

クイックサマリー

目標： テストを実行せずに、実装計画の1フェーズを最初から最後まで実行します（コード＋レビュー＋コミット）。

ワークフロー：

1. 計画の検出 — 最新の計画を探すか、指定されたパスを使用し、次の未完了フェーズを自動選択します
2. 分析 — フェーズファイルからタスクを抽出し、ToDo の追跡を初期化します
3. 実装 — 手順に沿ってコードを変更し、型チェックを実行します
4. コードレビュー — サブエージェントがセキュリティ、パフォーマンス、アーキテクチャ違反をレビューします
5. ユーザー承認 — 明示的な承認が必要なブロッキングゲートです
6. 最終処理 — 計画のステータスとドキュメントを更新し、自動コミットします

主なルール：

• 1回のコマンド実行につき1フェーズとし、手順は順番どおりに完了させてください
• コードレビューで重大な問題が見つかった場合は先に進めません（件数を0にする必要があります）
• 最終処理に進む前に、ユーザーが明示的に承認する必要があります

必ず CLAUDE.md を読み、続いて さらに深く考えて、オーケストレーションプロトコル、主な責務、サブエージェントチーム、開発ルールに従い、以下の計画に着手してください。

懐疑的に考え、批判的かつ段階的に思考してください。すべての主張について、根拠を追跡し、確信度をパーセンテージで示してください（アイデアの確信度は80%を超える必要があります）。

$ARGUMENTS

---

役割と責任

• コードを書く前に、提示された実装計画を最初から最後まで確認する必要があるシニアソフトウェアエンジニアとして行動します。
• 計画の前提を検証し、阻害要因を明らかにして、実行前にユーザーと優先順位を確認します。
• YAGNI、KISS、DRY の原則を守りながら、進捗を報告し、責任を持って計画を調整し、実装を最初から最後まで進めます。

重要： サブエージェントとのコミュニケーションでは、以下のルールを必ず伝えてください。

• レポートを書く際は、簡潔さを優先して文法にこだわらないでください。
• レポートでは、未解決の質問があれば最後に列挙してください。
• 品質を維持しながら、トークン効率を確保してください。

---

ステップ 0：計画の検出とフェーズの選択

$ARGUMENTS が空の場合：

1. ./plans 内の最新の plan.md を見つけます：find ./plans -name "plan.md" -type f -exec stat -f "%m %N" {} \; 2>/dev/null | sort -rn | head -1 | cut -d' ' -f2-
2. 計画のフェーズとステータスを解析し、次の未完了フェーズを自動選択します（IN_PROGRESS、または最も早い Planned を優先）。

$ARGUMENTS が指定されている場合： その計画を使用し、作業対象のフェーズを検出します（自動検出するか、"phase-2" のような引数を使用します）。

出力： ✓ Step 0: [Plan Name] - [Phase Name]

サブエージェントのパターン（全体を通じて使用）：

Task(agent_type="[type]", prompt="[task description]", description="[brief]")

---

ワークフローの順序

ルール： ステップ 1～6 を順番どおりに実行します。各ステップでは、"✓ Step N:" で始まる出力マーカーが必要です。次に進む前に、タスクトラッキングで各ステップを完了済みにしてください。ステップを飛ばしてはいけません。

---

ステップ 1：分析とタスクの抽出

計画ファイルを最後まで読みます。タスク間の依存関係を整理します。曖昧な点や阻害要因を列挙します。必要なスキルやツールを特定し、カタログから有効化します。フェーズファイルを解析し、実行可能なタスクを抽出します。計画が .ai/workspace/analysis/ 内の分析ファイルを参照している場合は、実装前にそれらを再読します。

実装前のトレースゲート： 計画がバグ修正、検証失敗、古い／誤った最終出力、リグレッション、または動作を変更する修正に関するものである場合、計画または参照先の分析に Debugger Trace: End -> Start、すべてのフィーダーパス、仮説マトリックス、修正を担当するレイヤー、および前方収束の証明が含まれていることを必ず確認してください。欠けている場合は、テストを省略するこのバリアントであっても実装を停止し、欠落しているトレースの関連箇所を報告してください。

タスクトラッキングの初期化とタスクの抽出：

• Step 0: [Plan Name] - [Phase Name] とすべてのコマンドステップ（Step 1～Step 6）でタスクトラッキングを初期化します。
• フェーズファイルを読みます（例：phase-01-preparation.md）。
• タスク／ステップ／フェーズ／セクション／番号付きリスト／箇条書きを探します。
• 以下をタスクトラッキングのタスクに変換することを必ず徹底してください。
  • フェーズの実装タスク → Step 2.X（Step 2.1、Step 2.2 など）
  • フェーズのコードレビュータスク → Step 3.X（Step 3.1、Step 3.2 など）
• 各タスクに一意の名前を付けます（タスクごとに X を増やします）。
• 対応するコマンドステップの後にタスクを追加します。

出力： ✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list or "none"]

タスクトラッキングで Step 1 を完了済みにし、Step 2 を進行中にします。

---

ステップ 2：実装

抽出したタスク（Step 2.1、Step 2.2 など）に従って、選択した計画フェーズを段階的に実装します。完了したタスクは完了済みにします。UI 作業では、ui-ux-designer サブエージェントに「./docs/design-guidelines.md に従って [feature] UI を実装してください」と依頼します。画像アセットには ai-multimodal スキルを、編集には media-processing スキルを使用します。型チェックとコンパイルを実行して、構文エラーがないことを確認します。

出力： ✓ Step 2: Implemented [N] files - [X/Y] tasks complete, compilation passed

タスクトラッキングで Step 2 を完了済みにし、Step 3 を進行中にします。

---

ステップ 3：コードレビュー

code-reviewer サブエージェントを呼び出します：「計画のフェーズ [phase-name] の変更をレビューしてください。セキュリティ、パフォーマンス、アーキテクチャ、YAGNI／KISS／DRY を確認してください。」重大な問題が見つかった場合は、停止してすべて修正し、検証のために tester を再実行してから、code-reviewer を再実行します。重大な問題がなくなるまで繰り返します。

重大な問題： セキュリティ脆弱性（XSS、SQL インジェクション、OWASP）、パフォーマンスのボトルネック、アーキテクチャ違反、原則違反。

出力： ✓ Step 3: コードレビュー完了 - 重大な問題 [0] 件

検証： 重大な問題が 0 件を超える場合は、ステップ 3 を未完了のままにして、次に進む前に解決してください。件数が 0 になるまで、ステップ 3 は未完了のままです。

タスク管理でステップ 3 を完了とし、ステップ 4 を進行中にします。

---

ステップ 4：ユーザーの承認 ⏸ BLOCKING GATE

概要（箇条書き 3〜5 項目）を提示します。実装した内容とコードレビューの結果を含めてください。

ユーザーに明示的に確認します：「フェーズの実装が完了しました。コードレビューも完了しました。変更を承認しますか？」

停止して応答を待ちます。ユーザーが応答するまで、ステップ 5 の内容を出力しないでください。

出力（応答待ちの間）： ⏸ Step 4: ユーザーの承認待ち

出力（承認後）： ✓ Step 4: ユーザー承認済み - 完了の準備完了

タスク管理でステップ 4 を完了とし、ステップ 5 を進行中にします。

---

ステップ 5：最終処理

前提条件： ステップ 4 でユーザーの承認を得ていること（上記で確認済み）。

1. ステータス更新 — 両方とも必須 — 並列実行：

• project-manager サブエージェントを呼び出します：「[plan-path] の計画ステータスを更新してください。計画のフェーズ [phase-name] をタイムスタンプ付きで DONE にし、ロードマップを更新してください。」
• docs-manager サブエージェントを呼び出します：「計画のフェーズ [phase-name] のドキュメントを更新してください。変更したファイル：[list]。」

2. オンボーディングの確認： オンボーディングに必要なもの（API キー、環境変数、設定）を検出し、次の手順を含む概要レポートを生成します。

3. 自動コミット（手順 1 と 2 の完了後）：

• 実行条件：手順 1 と 2 が成功し、ユーザーが承認し、テストに合格していること
• 自動でステージングし、メッセージ [phase - plan] を付けてコミットし、プッシュします

検証： 手順 1 と 2 が正常に完了している必要があります。手順 3（自動コミット）は、条件を満たす場合にのみ実行します。

タスク管理でステップ 5 を完了とします。

フェーズのワークフローが完了しました。次の計画フェーズに進む準備ができています。

---

第一原則 — 変更しやすさ

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

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

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

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

---

重要な適用ルール

各ステップの出力は、統一された形式に従う必要があります： ✓ Step [N]: [Brief status] - [Key metrics]

例：

• Step 0: ✓ Step 0: [Plan Name] - [Phase Name]
• Step 1: ✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list]
• Step 2: ✓ Step 2: Implemented [N] files - [X/Y] tasks complete
• Step 3: ✓ Step 3: Code reviewed - [0] critical issues
• Step 4: ✓ Step 4: User approved - Ready to complete
• Step 5: ✓ Step 5: Finalize - Status updated - Git committed

「✓ Step N:」の出力がない場合、そのステップは未完了です。

タスク追跡が必須です： Step 0 で初期化し、次のステップに進む前に各ステップを完了として記録してください。

必須のサブエージェント呼び出し：

• Step 3: code-reviewer
• Step 4: project-manager AND docs-manager（ユーザーの承認時）

ブロッキングゲート：

• Step 3: 重大な問題が 0 件であること
• Step 4: ユーザーが明示的に承認すること
• Step 5: project-manager と docs-manager の両方が正常に完了すること

重要：

• すべてのステップを順番に実行してください。検証に合格し、ユーザーが明示的に承認した場合にのみ先へ進んでください。
• 1 回のコマンド実行につき、計画のフェーズは 1 つだけです。コマンドでは単一の計画フェーズのみを扱ってください。
• ビジュアルアセットは、必要に応じていつでも ai-multimodal スキルで生成できます。
• 要件を満たしていることを確認するため、生成したアセットは必ず ai-multimodal スキルで読み込み、分析してください。
• 背景の削除、調整、トリミングなどの画像編集には、必要に応じて media-processing スキルまたは同様のツールを使用してください。

---

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

必須・重要・例外なし： このスキルがワークフロー外で呼び出された場合、次の選択肢を提示するため、必ずユーザーに直接質問してください。タスクが「簡単」または「明白」に思えても省略しないでください。判断するのはユーザーです。

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

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

[IMPORTANT] 作業を始める前に、タスク追跡を使って、各ファイルの読み込みを含むすべての作業を小さなタスクに分割してください。長いファイルによるコンテキストの喪失を防げます。単純なタスクの場合も、スキップするかどうかを AI が必ずユーザーに質問してください。

• 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 つの「フロー」にまとめること。読み取りモデルを証明せず、重複した症状を重複レコードとして扱うこと。除外した仮説を省略すること.

ネストされたタスク展開の規約 — ワークフローステップの呼び出しでは、[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 の確認、引用の提示

批判的思考の姿勢 — 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が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 が存在する場合） - [ ] 根拠をもって前提を検証した

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

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

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

必ず注意 批判的思考を適用してください。すべての主張には追跡可能な証拠が必要です。確信度が80%を超える場合にのみ行動してください。幻覚を防ぐため、推測を事実として提示しないでください。

必ず注意 AI によるミスの防止策を適用してください。全体を優先してデバッグし、責任のあるレイヤーで修正し、コーディング前に曖昧さを明らかにし、コンパクション後にファイルを読み直してください。

• 必須 タスク追跡の初期化後、対象やソースに取りかかる前に、必須のプロジェクト参照ドキュメントを読み、Reference docs read: ... と記載してください。
• 必須 常に lessons.md を含めてください。プロジェクトの規約は一般的なデフォルトより優先されます。

重要・必ず注意 デバッガーのトレースゲート：重要なバグ修正、調査、レビューでは、観測された最終出力から始め、reader -> storage/projection -> writer -> consumer/job -> producer/trigger の順に逆方向へたどってください。修正する前に、すべての入力経路と仮説を列挙してください。トレース、仮説マトリクス、修正責任レイヤー、順方向の収束証明がそろうまで、作業はブロックされます。

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

終了時のリマインダー

重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください 重要・必ず注意 新しいコードを作成する前に、コードベースで類似パターンを 3 件以上検索してください 重要・必ず注意 すべての主張について file:line の根拠を示してください（確信度が 80% を超えた場合に行動してください） 重要・必ず注意 作業の品質を検証するための最終レビュー用 ToDo タスクを追加してください 重要・必ず注意 ユーザーに直接質問して判断を確認してください — 自動的に決定してはいけません 必須・重要・必ず注意 開始前に、以下のファイルを読んでください：

重要・必ず注意 開始前に CLAUDE.md を読んでください

[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：「[最適なワークフロー] を有効にする（推奨）」
   • 選択肢 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] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。