migration

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. 分析 — マイグレーションの要件と対象データベースを把握します
2. 作成 — プラットフォームの規約に従ってマイグレーションを生成します
3. 検証 — マイグレーションを実行し、検証します

主なルール：

• プラットフォームのマイグレーションパターン（EF マイグレーションまたはプロジェクトのデータマイグレーション実行機能。docs/project-reference/backend-patterns-reference.md を参照）に従ってください
• マイグレーションを作成する前に、必ず「コードを先に理解する」プロトコルを使用してください

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

$ARGUMENTS

⚠️ 必ず references/migration-patterns.md を読んで、マイグレーションパターンを確認してください。

重要： マイグレーションの設計を提示し、ファイルを作成する前にユーザーの明示的な承認を待ってください。

例

$migration "Add department field to Employee entity"

---

[IMPORTANT] 作業を始める前に、すべての作業を小さなタスクに分割してタスク追跡に登録してください。各ファイルの読み込みもタスクに含めてください。これにより、長いファイルによるコンテキストの喪失を防げます。単純なタスクの場合、AI は必ず省略してよいかユーザーに確認してください。

前提条件： 実行前に必ず読んでください：

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関係、サービス間の同期（タスクにビジネスエンティティ／モデルが関係する場合に読みます）（関連する場合は直接読み、フックで挿入された会話テキストに依存しないでください）

ソース／テストの乖離チェック。 コーディング、修正、デバッグ、調査、テスト、レビューを行う場合、ソースの動作が変わったら、影響を受ける単体／統合／E2E テストを調査し、意図した動作に合わせてテストを変更すべきか、それともソースの変更が意図しないバグであり修正すべきかを、根拠に基づいて判断してください。移行コードのテストは作成しないでください。スキーマ／データ移行は一度だけ実行される処理であり、アプリケーションの中核ロジックではありません。

AI のミスを防ぐ — あらゆるタスクで避けるべき失敗パターン：

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

ネストされたタスクの展開ルール — ワークフローのステップを呼び出す場合、[Workflow] ... の行は親コンテナにすぎません。子スキルも、可視のフェーズタスクを作成します。

1. 最初に現在のタスクリストを取得してください。一致するアクティブな親ワークフロー行がある場合は nested=true を設定し、parentTaskId を記録してください。ない場合は、単独で実行してください。
2. フェーズ作業を始める前に、宣言されたフェーズごとにタスクをひとつ作成してください。ネストされている場合は、件名の先頭に [N.M] $skill-name — phase を付けてください。
3. ネストされている場合は、TaskUpdate(parentTaskId, addBlockedBy: [childIds]) で親にリンクしてください。
4. オーケストレーターは、子スキルまたはサブエージェントを呼び出す前に、その子スキルのフェーズ一覧を展開し、ワークフロー行をリンクしなければなりません。
5. 作業を始める前に、子タスクをひとつだけ 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 が存在する場合） - [ ] 根拠に基づいて前提を検証する

• 必須・重要・厳守 変更を加える前に、既存パターンを 3 つ以上検索してコードを読みます。graph.db が存在する場合は、グラフをトレースします。

厳守 批判的思考を適用します。あらゆる主張には追跡可能な証拠が必要であり、確信度が 80% を超えた場合にのみ行動します。ハルシネーション対策：推測を事実として提示してはいけません。

厳守 AI の誤りを防止します。全体を優先するデバッグ、責任を持つレイヤーでの修正、コーディング前の曖昧さの明示、コンテキストの圧縮後のファイル再読み込みを徹底します。

• 必須 タスク追跡の初期設定後、対象やソースの作業を始める前に、必要なプロジェクトリファレンスドキュメントを読み、Reference docs read: ... と記載します。

• 必須 常に lessons.md を含めます。プロジェクトの規約は一般的なデフォルト設定より優先されます。

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

• 必須 オーケストレーターは呼び出し前に子スキルのフェーズを展開します。[N.M] $skill-name — phase の接頭辞を使用し、in_progress は常に 1 つだけにします。

最後の注意事項

• 必須・重要・必ず注意 作業を始める前に、タスク管理を使って作業を小さな ToDo タスクに分割してください
• 必須・重要・必ず注意 新しいコードを作成する前に、コードベースを検索して類似パターンを3つ以上見つけてください
• 必須・重要・必ず注意 すべての主張に file:line の根拠を明記してください（信頼度が80％を超える場合に実行）
• 必須・重要・必ず注意 作業品質を確認するための最終レビュー ToDo タスクを追加してください 必須・重要・必ず注意 作業を始める前に、次のファイルを必ず読んでください：
• 必須・重要・必ず注意 作業を始める前に references/migration-patterns.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：「[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] ワークフローやスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成または更新してください。その後、各手順の開始時と完了時に、タスク追跡の内容を同期してください。