create-feature

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

クイックサマリー

目標： バックエンド（エンティティ、CQRS、コントローラー）とフロントエンド（Angular コンポーネント、サービス）を備えたフルスタック機能を新たにスキャフォールディングします。

ワークフロー：

1. 分析 — 要件を分解し、対象範囲（バックエンド／フロントエンド／フルスタック）を特定します
2. 特定 — 対象となるマイクロサービスと Angular アプリ／モジュールを決定します
3. 計画 — エンティティ、コマンド／クエリ、エンドポイント、コンポーネント、DTO を整理します
4. 承認 — 計画を提示し、ファイルを作成する前にユーザーの明示的な承認を待ちます
5. 作成 — エンティティ → アプリケーション → DTO → コントローラー → フロントエンドの順にファイルをスキャフォールディングします

主なルール：

• 先に進む前に、ユーザーの明示的な承認を待ってください
• CLAUDE.md と .github/prompts/ のテンプレートにあるプラットフォームのパターンに従ってください
• ビルド順序：ドメイン → アプリケーション → API → フロントエンド
• 作成後、dotnet build と nx build で検証してください

懐疑的に考えてください。批判的思考と逐次的思考を適用してください。すべての主張には、追跡可能な根拠と確信度（Idea は 80% 超）が必要です。

M1-M6 コンプライアンスゲート（違反があれば停止してやり直すこと）

ブロッキング条件については、.claude/skills/shared/sdd-artifact-contract.md → 「AI-SDD Mandates (M1-M6)」を参照してください。このスキルが出力する要件や仕様のテキストは、スキャフォールディングの前に必ずゲートを通過しなければなりません。

• **M1/M2：**要件と設計の説明文では、ビジネス上の振る舞いのみを記述します。フレームワーク名、製品名、言語名、説明文中のクラス／メソッド／ファイルへの参照は禁止です。ソース識別子はエビデンスキャリア（[Source:]、**Evidence**）に記載してください。
• **M3：**各機能ルールには、論理 ID（FR-/BR-/OP-）と、それとは別の [Source: namespace/service/id] 抽象アンカーのエビデンスキャリアを含めます（物理的な file:line／src/ パスは使用しません）。両方を保持してください。
• **M4/M5：**要件ごとに解釈は1つとし、成功／失敗の結果を明示します。また、仕様のテキストだけをもとに、どのスタックでも振る舞いを再実装できるようにします。
• 説明文で実装パターンに言及する場合は、抽象パターン（パターン ID、または「操作ハンドラー」「永続化レイヤー」「イベントバス」などのビジネス用語）を示します。フレームワーク名や製品名は使いません。具体的なパターン名やライブラリ名は、スキャフォールディングの手順とエビデンスフィールドのみに記載し、仕様の説明文には含めないでください。

要件や設計のテキストがいずれかの指令に違反する場合は、スキャフォールディングに進む前に停止して修正してください。

新しい機能を作成します：$ARGUMENTS

手順：

1. 要件を分析する

   • 機能要件を分解します
   • 対象範囲（バックエンドのみ、フロントエンドのみ、またはフルスタック）を特定します

2. サービスの場所を特定する

   • バックエンドに適切なマイクロサービスを決定します
   • フロントエンドの Angular アプリ／モジュールを特定します

3. 実装を計画する

   • 必要なドメインエンティティ
   • CQRS コマンド／クエリ
   • API エンドポイント（コントローラー）
   • Angular コンポーネントとサービス
   • DTO とバリデーション

4. プロジェクトのパターンを使用する

   • CLAUDE.md のパターンを参照します
   • スキャフォールディングには .github/prompts/ のテンプレートを使用します：
     • create-cqrs-command.prompt.md
     • create-cqrs-query.prompt.md
     • create-entity-event.prompt.md
     • create-angular-component.prompt.md
     • create-api-service.prompt.md

5. 承認を待つ

   • 実装計画を提示します
   • 明示的な承認なしに先へ進んではいけません

6. ファイルを作成する（承認後） 次の順序で実行します：

   1. ドメインエンティティ（.Domain/Entities/）
   2. アプリケーションレイヤー（.Application/UseCaseCommands/、.Application/UseCaseQueries/）
   3. エンティティ DTO（.Application/EntityDtos/）
   4. API コントローラー（.Api/Controllers/）
   5. フロントエンドのコンポーネントとサービス

7. 検証する

   • バックエンドをビルドします：dotnet build
   • フロントエンドをビルドします：nx build <app-name>

---

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

前提条件：実行前に必ず注意して読むこと：

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

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

ネストされたタスクの展開ルール — ワークフローのステップを呼び出す場合、[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 が存在する場合） - [ ] 根拠に基づいて前提を検証する

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

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

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

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

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

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

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

終了時のリマインダー

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

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