code-parallel

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. 統合 — 結果を統合して検証する

主なルール：

• 入力として既存の計画ファイルが必要です
• 各サブエージェントは特定のファイルを担当し、担当範囲を越えて編集しません
• 逐次実行が必要なフェーズは、依存関係が解消されるまで待機します

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

計画を実行：$ARGUMENTS

重要： 必要なスキルを有効化してください。トークン効率を確保してください。簡潔さを優先し、文法は犠牲にして構いません。

ワークフロー

1. 計画の分析

• 指定されたパスの plan.md を読む
• 確認項目： 依存関係グラフ、実行戦略、並列化情報、ファイル担当範囲のマトリックス
• 判断： 並列実行可能なら → ステップ 2A、そうでなければ → ステップ 2B
• 外部メモリ： 計画で参照されている .ai/workspace/analysis/ のファイルがあれば、並列エージェントへの割り当て前に再度読み込んでください。
• 実装前のトレースゲート： バグ修正、検証失敗、古い／誤った最終出力、リグレッション、または動作を変更する修正の計画では、計画または参照先の分析に Debugger Trace: End -> Start、すべての入力経路、仮説マトリックス、修正を担当するレイヤー、前方への収束を示す証明が含まれていることを検証してください。不足している場合は停止してください。含まれている場合は、入力経路が重複したり抜け落ちたりしないよう、各並列作業者にトレース分岐とファイル担当範囲を割り当ててください。

2A. 並列実行

1. 実行戦略（どのフェーズを並列／順次で実行するか、ファイルの担当範囲）を解析します
2. 並列フェーズでは、複数の fullstack-developer エージェントを同時に起動します
   • フェーズのファイルパス、環境情報、ファイルの担当範囲を渡します
3. 並列グループの完了を待ち、競合がないことを確認します
4. 順次フェーズを実行します（依存関係に従い、各フェーズでエージェントを1つ使用）
5. ステップ3に進みます

2B. 順次実行

./.claude/workflows/primary-workflow.md に従います。

1. メインエージェントを使って、手順を1つずつ進めます
2. plan.md を読み、フェーズを1つずつ実装します
3. 進捗の更新には project-manager を使います
4. フロントエンドには ui-ux-designer を使います
5. 各フェーズの後に型チェックを実行します
6. ステップ3に進みます

3. テスト

• テスト一式には tester を使います（偽のデータやモックは使用しません）
• 失敗した場合：debugger → 修正 → 再実行

4. コードレビュー

• すべての変更に code-reviewer を使います
• 重大な問題がある場合：修正 → 再テスト

5. プロジェクト管理とドキュメント

• 承認された場合：project-manager と docs-manager を並列で使用します（計画、ドキュメント、ロードマップを更新）
• 却下された場合：修正 → 再実行

6. オンボーディング

• ユーザーを段階的にガイドします（1回に1つの質問）

7. 最終報告

• 概要、ガイド、次のステップ
• コミットするか尋ねます（はいの場合は git-manager を使います）

例：

• 並列：「フェーズ1～3を並列、その後4」→ エージェントを3つ起動 → 待機 → エージェントを1つ起動
• 順次：「フェーズ1 → 2 → 3」→ メインエージェントが各フェーズを実装

---

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

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

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

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

［重要］ 作業を始める前にタスク管理を使って、ファイルの読み取りを含むすべての作業を小さなタスクに分割してください。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合、AI はスキップするかどうかを必ずユーザーに確認してください。

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

スキルのバリアント： $code のバリアントです — 計画に基づくフェーズの並列実行。 最終状態から開始するデバッガートレース — 複雑なバグ、検証の失敗、回帰修正、動作を変えるコード、またはコードフローが不明瞭な場合は、修正案を提示する前に、観測された最終状態から逆向きにたどってください。

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 登録、データの前提条件）。その後、コード層の仮説を立てる前に、それぞれを証拠と照合してください。 変更は最小限に — 差分テストを適用してください。 バグ修正では、変更する各行がバグに直接結び付いている必要があります。隣接するコードのスタイル変更や改善はしないでください。機能改善タスクでは、改善を実装し、その内容を明確に伝えてください。 実装前に曖昧さを明らかにし、黙って決めないでください。 依頼に複数の解釈がある場合は、それぞれの工数見積もりを示して確認してください。全レコード対象、ファイルベース、またはより複雑な方法だと決めつけないでください。

ネストされたタスクの展開ルール — ワークフローのステップを呼び出す場合、[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 を含めてください。プロジェクトの慣例は汎用的なデフォルトより優先されます。

重要・必ず注意 デバッガーの追跡を必須とします。重要なバグ修正、調査、レビューでは、観測された最終出力から始め、reader → storage/projection → writer → consumer/job → producer/trigger の順に遡って追跡してください。修正前に、すべての入力経路と仮説を列挙してください。次の条件を満たすまで作業禁止: 追跡、仮説マトリクス、修正を担当するレイヤー、および前方への収束を示す証拠が揃っていること。

• 必須 親ワークフローの行で子フェーズの追跡を置き換えることはできません。フェーズを展開し、ネストする場合は親にリンクしてください。
• 必須 オーケストレーターは呼び出し前に子スキルのフェーズを事前に展開します。[N.M] $skill-name — phase のプレフィックスと、in_progress を常に1つだけにするルールを使用してください。

終了時のリマインダー

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

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

Hookless Prompt Protocol Mirror（自動同期）

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