test-specs-docs

Codex 互換性に関する注意：

• Codex でリポジトリのスキルを呼び出すには、$skill-name を使用します。このミラー版では、従来の Claude の /skill-name 参照を書き換えています。
• この Codex ミラー版で計画のガイダンスが必要な場合は、plan-hard スキルを優先してください。
• タスクトラッカーに関する必須事項：ワークフローまたはスキルの手順を実行する前に、すべての手順のタスク追跡を作成または更新し、進捗の変化に合わせて同期させてください。
• ユーザーへの質問を求める指示は、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 を確認し、タスクに関連するファイルだけを開いてください。

[IMPORTANT] タスク追跡を常に同期し、証拠に関するゲートを維持し、必須の手順を絶対に省略しないでください。

[DEPRECATED] このスキルは $tdd-spec に統合されました。代わりに $tdd-spec [direction=sync] を使用してください。

• 順方向同期（機能ドキュメント → ダッシュボード）：$tdd-spec [direction=sync]
• 逆方向同期（ダッシュボード → 機能ドキュメント）：$tdd-spec [direction=reverse]
• 双方向の調整：$tdd-spec [direction=full]

すべての同期アルゴリズム、孤立項目の検出、古さの追跡、品質ゲートは、$tdd-spec の ## Mode: Sync to Dashboard セクションに移行しました。

概要

目標： [DEPRECATED] このスキルは tdd-spec に統合されました。順方向同期には $tdd-spec [direction=sync]、逆方向同期には $tdd-spec [direction=reverse]、双方向の調整には $tdd-spec [direction=full] を使用してください。

ワークフロー：

1. 検出 — リクエストの範囲と対象成果物を分類します。
2. 実行 — 証拠に裏付けられたアクションで、必要な手順を適用します。
3. 検証 — 制約、出力品質、完了の証拠を確認します。

主なルール：

• 対応する際は、主張を証拠（file:line）に基づくものとし、確信度を 80% 超にしてください。必ず遵守してください。
• 各手順の開始時と完了時にタスク追跡を更新してください。必ず遵守してください。
• 必須のワークフローやスキルのゲートを絶対に省略しないでください。

---

終了時の注意事項

重要：必ず注意してください。構造を強化する前に、フェーズ 1 の圧縮を適用し、意味を保持してください。 重要：必ず注意してください。最適化中に YAML フロントマター、コードブロック、表、SYNC タグの本文を絶対に変更しないでください。 重要：必ず注意してください。エビデンスゲートと必須のワークフロー／スキルの手順を、明示的かつ実行可能な状態にしてください。 重要：必ず注意してください。出力品質と未解決のリスクを確認する最終レビュータスクを追加してください。

フックなしプロンプトプロトコルミラー（自動同期）

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

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須、重要、絶対に遵守。いかなる理由があっても省略しないでください。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップの組み合わせのほうが適しているかどうかも評価します
3. 質問（必須形式）： 次の構成でユーザーに直接質問します。
   • 質問：「どのワークフローを有効にしますか？」
   • オプション 1：「[BestMatch Workflow] を有効にする（推奨）」
   • オプション 2：「カスタムワークフローを有効にする：[step1 → step2 → ...]」（理由を 1 行で添えます）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順番に実行します
5. タスクの作成： ワークフローのすべてのステップについてタスクを追跡します
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と逐次的思考を適用します。すべての主張には追跡可能な根拠が必要です。実行する際の確信度は 80% を超えている必要があります。 ハルシネーション防止の原則： 推測を事実として提示してはいけません。すべての主張に出典を示し、不確実性は率直に認め、出力に誤りがないか自己点検し、独立して相互検証し、自分の確信度にも懐疑的でいてください。根拠のない確信が、あらゆるハルシネーションの根本原因です。 AI の注意原則（初頭効果・新近効果）： 長いプロンプトやプロトコルでは、最も重要な 3 つのルールを最初と最後の両方に置き、長いコンテキストでも指示が守られるようにします。

学んだ教訓

学んだ教訓

[CRITICAL] プロジェクトのデバッグ／アーキテクチャで苦労して得たルールです。仮説を立てたりコードを書いたりする前に、必ず適用してください。

クイックサマリー

目標： デバッグ、アーキテクチャ、命名、AI オーケストレーション、環境に関する既知の失敗パターンの再発を防ぎます。

最優先ルール（常に適用）：

• コード層の仮説を立てる前に、すべての前提条件（設定、環境、DB 名、DI 登録）を必ず確認します
• 原因となっている層を修正します。呼び出し元固有の防御コードで症状の発生箇所を修正してはいけません
• 並列非同期処理とリポジトリ／UoW には ExecuteInjectScopedAsync を使用します。ExecuteUowTask は絶対に使用しません
• 内容ではなく目的に基づいて命名します。メンバーを追加したことで名前の変更が必要になるなら、抽象化が適切ではありません
• サブエージェントの調査結果は、各ファイルの確認後に逐次保存します。最後にまとめて保存してはいけません
• Windows の bash では、Python のエイリアスを確認します（where python／where py）。python／python3 が解決されると決めつけてはいけません

デバッグと根本原因の推論

• [2026-04-11] 全体を優先し、コードの前に環境を検証します。 障害が発生したら → すべての前提条件（設定、環境変数、DB 名、エンドポイント、DI 登録、認証情報、権限、データの前提条件）を列挙 → コード層の仮説を立てる前に、証拠（grep/cat/query）ですべてを検証します。最悪の迷走は、バグが別の場所にあるのに最も近い層を調べることです。たとえば、「同期タイムアウト」のデバッグに何時間も費やした結果、実際の原因は、テストの appsettings が誤った DB を参照していたことだった、というケースです。まず最も手軽な確認から行います。
• [2026-04-01] 修正する前に「どちらの責任か？」を確認します。 呼び出し元（誤ったデータ）と呼び出し先（誤った処理）のどちらにバグがあるかを追跡します。責任を持つ層を修正し、実際の問題を覆い隠す症状の発生箇所へのパッチは絶対に行いません。
• [2026-04-01] エラーの発生箇所ではなく、データのライフサイクルを追跡します。 データを、作成 → 変換 → 消費の順に追います。バグは通常、データが消費される場所ではなく、誤って作成される場所にあります。
• [2026-04-01] コードは呼び出し元に依存しません。 関数、ハンドラー、コンシューマーは、誰が呼び出しているかを知りません。コメント、ガード、メッセージではビジネス上の意図を説明し、特定の呼び出し元（テスト、シーダー、スクリプト）には絶対に言及しません。

アーキテクチャの不変条件

• [2026-03-31] ParallelAsync とリポジトリ／UoW を使う場合は ExecuteInjectScopedAsync を必ず使い、ExecuteUowTask は絶対に使いません。 ExecuteUowTask は新しい UoW を作成しますが、外側の DI スコープ（同じ DbContext）を再利用するため、スレッドセーフではない DbContext を並列イテレーション間で共有し、データを気付かないうちに破損させます。ExecuteInjectScopedAsync は新しい UoW と DI スコープを作成し、イテレーションごとに新しいリポジトリを使用します。
• [2026-03-31] バスメッセージ名には必ずサービス名のプレフィックスを含めます。コアサービスが機能イベントを消費することは絶対にありません。 プレフィックスはスキーマの所有権を示します（AccountUserEntityEventBusMessage は Accounts が所有することを意味します）。コアサービス（Accounts、Communication）はリーダーです。コアサービスにメッセージを送信する機能サービス（Growth、Talents）は、必ず {CoreServiceName}...RequestBusMessage を使い、コアサービスが消費する独自イベントを定義してはいけません。

命名と抽象化

• [2026-04-12] 内容ではなく目的に名前を付けます。「OrXxx」はアンチパターンです。 HrManagerOrHrOrPayrollHrOperationsPolicy は、何を保護するかではなく、メンバーの集合に名前を付けています。ロールの追加に伴って名前を変更すると、抽象化が壊れます。ルール： 名前は「含むもの」ではなく、「実行すること／保護するもの」を表します。テスト： メンバーの追加や削除によって名前の変更が必要ですか？ 必要なら、内容に基づく名前付けであり、適切ではありません。目的を表す名前（例：HrOperationsAccessPolicy）に変更します。補足： 動作を表す慣用表現（FirstOrDefault、SuccessOrThrow）では「Or」を使っても問題ありません。メンバーシップではなく、起こることを表します。

環境とツール

• [2026-04-20] Windows の bash では、python／python3 が解決されると決めつけず、まずエイリアスを確認します。 bash の PATH には、これらの名前で Python が含まれていない場合があります。where python／where py で確認します。1 行コマンドには py（Windows Python Launcher）を優先し、JavaScript で代替できる場合は node を使います。

テスト固有の教訓 → docs/project-reference/integration-test-reference.md の Lessons Learned セクション。本番コードのアンチパターン → docs/project-reference/backend-patterns-reference.md の Anti-Patterns セクション。一般的なデバッグ／リファクタリングの注意事項 → .claude/hooks/lib/prompt-injections.cjs の System Lessons。

終了時のリマインダー

• 重要：必ず注意すること 全体を優先して確認します。コードレイヤーの仮説を立てる前に、すべての前提条件（設定、環境、DB 名、エンドポイント、DI 登録）を確認します。まずは最も低コストな確認から行います。
• 重要：必ず注意すること 原因となっているレイヤーを修正します。症状が現れている箇所には絶対にパッチを当てず、呼び出し元（誤ったデータ）と呼び出し先（誤った処理）のどちらに問題があるかをたどり、根本原因を担う箇所を修正します。
• 重要：必ず注意すること 並列非同期処理とリポジトリ／UoW を併用する場合は、必ず ExecuteInjectScopedAsync を使用し、ExecuteUowTask は絶対に使用しません（DbContext の共有は、気付かないままデータ破損を引き起こします）。
• 重要：必ず注意すること バスメッセージのプレフィックスはスキーマの所有者を表します。機能サービスはコアサービス向けのイベントを絶対に定義せず、{CoreServiceName}...RequestBusMessage を使用します。
• 重要：必ず注意すること 目的に基づいて命名します。メンバーの追加や削除によって名前の変更が必要になるなら、抽象化が適切ではありません。
• 重要：必ず注意すること サブエージェントは、各ファイル／セクションの後に必ず調査結果を書き込みます。すべての調査結果を最後にまとめて書き込むことは絶対にしません。
• 重要：必ず注意すること Windows の Bash では、python／python3 が実行できると決めつけないでください。まず where python／where py を実行し、py ランチャーまたは node を使用します。

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

開始前に作業を小さなタスクに分割し、タスクを追跡します。最後のタスクとして「AI の誤りと教訓を分析する」を追加します。

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

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