ce-work-beta

Work Execution Command

品質を維持しながら、作業を効率的に実行し、機能を完成させます。

Introduction

このコマンドは、作業内容を記述したドキュメント（計画書または仕様書）または作業内容を説明する簡単なプロンプトを受け取り、体系的に実行します。要件を素早く把握し、既存のパターンに従い、全体を通して品質を維持しながら、完成した機能をリリースすることに重点を置いています。

ベータ版の展開に関する注意： Codex への委任を試す場合は、手動で ce-work-beta を呼び出してください。ベータ期間中は、二重経路のオーケストレーションが複雑になるのを避けるため、計画とワークフローの引き継ぎ先は安定版の ce-work のままです。

Input Document

<input_document> #$ARGUMENTS </input_document>

Argument Parsing

$ARGUMENTS から以下の任意のトークンを解析します。認識した各トークンを取り除いてから、残りを計画ファイルのパスまたは簡単なプロンプトとして解釈します。

トークン	例	効果
delegate:codex	delegate:codex	計画の実行で Codex 委任モードを有効にします
delegate:local	delegate:local	設定で委任が有効になっていても、委任を無効にします

すべてのトークンは任意です。指定されていない場合は、以下の解決順序に従います。

あいまいな有効化： 「use codex」、「delegate to codex」、「codex mode」、「delegate mode」のような委任の意図を示す命令的なフレーズも、delegate:codex と同等に認識します。プロンプト内に「codex」という語が単に含まれているだけの場合（例：「fix codex converter bugs」）は、委任を有効にしてはいけません。明確な委任の意図が示されている場合に限り、有効にします。

あいまいな無効化： 「no codex」、「local mode」、「standard mode」のようなフレーズも、delegate:local と同等に認識します。

設定の解決チェーン

引数からトークンを抽出した後、次の優先順位に従って委任状態を解決します。

1. 引数フラグ -- 現在の呼び出しにおける delegate:codex または delegate:local（最優先）
2. 設定ファイル -- 以下の設定ブロックから設定を抽出します。work_delegate の値が codex の場合は委任が有効になり、false の場合は無効になります。
3. ハードデフォルト -- false（委任はオフ）

設定を読み取ります。 リポジトリルートはスキルの読み込み時に事前解決されています。 !git rev-parse --show-toplevel 2>/dev/null || true

上記の行が絶対パスの場合は、それを <repo-root> として使用します。空の場合、またはバッククォートで囲まれたコマンド文字列のままの場合（事前解決を実行しなかった、Claude 以外のハーネスの場合）は、シェルツールを使って git rev-parse --show-toplevel を実行し、実行時に <repo-root> を解決します。次に、ネイティブのファイル読み取りツール（Claude Code の Read、Codex の read_file など）を使って <repo-root>/.compound-engineering/config.local.yaml を読み取ります。ルートを解決できない場合、またはファイルが存在しない場合は、すべての設定でデフォルト値を使用します。それ以外の場合は、以下に記載されたキーの値を抽出します。

設定に認識できない値がある場合は、その設定のハードデフォルトにフォールバックします。ハードデフォルトのないオプション設定（work_delegate_model、work_delegate_effort）で、値を認識できない場合、または解析できない場合は、未設定として解決します。この場合、対応するフラグは codex exec の呼び出しから省略され、Codex は ~/.codex/config.toml の設定を使用します。無効な値を CLI フラグに代入してはいけません。

設定キー：

• work_delegate -- codex またはデフォルトの false
• work_delegate_consent -- true またはデフォルトの false
• work_delegate_sandbox -- yolo（デフォルト）または full-auto
• work_delegate_decision -- auto（デフォルト）または ask
• work_delegate_model -- 使用する Codex モデル。オプションです。未設定または解析できない場合は、ユーザーの ~/.codex/config.toml のデフォルト設定に委ねます。パススルー項目であり、空でない文字列はすべて有効な値として受け入れます。未設定になるのは、YAML の解析に失敗した場合、または値が空の場合のみです。
• work_delegate_effort -- minimal、low、medium、high、xhigh のいずれか。オプションです。未設定の場合、またはこの列挙型にない値の場合は未設定となり、ユーザーの ~/.codex/config.toml のデフォルト設定に委ねます。

後続の処理で使用できるよう、解決した状態を保存します。

• delegation_active -- 委任モードが有効かどうかを示すブール値
• delegation_source -- 委任の解決元を示す argument、config、default のいずれか（通知の詳しさを環境ガードが決定する際に使用）
• sandbox_mode -- yolo または full-auto（設定またはデフォルトの yolo）
• consent_granted -- ブール値（設定 work_delegate_consent の値）
• delegate_model -- 設定の文字列、または未設定（Codex の設定に委ねる）
• delegate_effort -- 設定の文字列、または未設定（Codex の設定に委ねる）。バッチごとの effort 選択における下限です。codex exec に直接渡されることはありません。
• effective_effort -- バッチごとに導出される値（default | medium | high | xhigh）。references/codex-delegation-workflow.md の「Per-Batch Effort」に従い、各バッチの前に delegate_effort と選択されたレベルから算出します。codex exec の呼び出しでは、delegate_effort の代わりに使用します。

---

実行ワークフロー

Phase 0: 入力のトリアージ

<input_document> に指定された内容に基づいて、進め方を決定します。

計画ドキュメント（入力が既存の計画または仕様書のファイルパスの場合）：まず計画のメタデータを読み取ります。Markdown の計画書では YAML フロントマターを、HTML の計画書では表示されているヘッダーテキストを確認します（どちらの形式にも同じフィールドが含まれています）。execution: knowledge-work が設定されている場合、これは非コード計画です。references/non-code-execution.md を読み、残りのワークフローではなく、その例外手順に従ってください。それ以外の場合（フィールドがない、または execution: code）は、Phase 1 に進み、通常のコードライフサイクルを実行します。（マーカーの確認はここ、つまり計画ドキュメントの処理内で行います。マーカーの検出にはファイルが必要なためです。「通常のプロンプト」には影響しません。）

通常のプロンプト（入力がファイルパスではなく、作業の説明である場合）：

1. 作業領域を確認する

   • プロンプトに基づいて、変更が必要と思われるファイルを特定する
   • 該当領域の既存のテストファイルを探す（実装ファイルをインポート、参照するファイル、または実装ファイルと同じ名前を含むテスト／仕様ファイルを検索する）
   • 影響を受ける領域の既存のパターンと規約を確認する

2. 複雑さを評価し、進め方を決定する

   複雑さ	判断材料	対応
   ごく簡単	ファイル数が 1～2 個で、動作に変更がない（誤字、設定、名前変更）	Phase 1 のステップ 2（環境設定）に進み、その後、タスクリストや実行ループを設けずに直接実装します。動作に関わるコードを変更する場合は、テストの調査を行います
   小規模／中規模	範囲が明確で、ファイル数が約 10 個未満	調査結果に基づいてタスクリストを作成し、Phase 1 のステップ 2 に進みます
   大規模	複数領域にまたがる、アーキテクチャ上の判断が必要、ファイル数が 10 個以上、認証／決済／マイグレーションに関わる	エッジケースと範囲の境界を明確にするために、/ce-brainstorm または /ce-plan の利用が役立つことをユーザーに伝えます。ユーザーの選択に従ってください。作業を続行する場合は、タスクリストを作成して Phase 1 のステップ 2 に進みます

---

Phase 1: クイックスタート

1. 計画を読み、内容を確認する (Phase 0 から通常のプロンプトで進んできた場合はスキップ)

   • 作業ドキュメントを完全に読む
   • 計画は実行スクリプトではなく、意思決定の成果物として扱う
   • 計画に Implementation Units、Work Breakdown、Requirements（または旧称の Requirements Trace）、Files、Test Scenarios、Verification などのセクションが含まれている場合は、それらを実行の主要なソース資料として使用する
   • 各実装単位に Execution note があるか確認する — これらにはその単位に対する計画の実行姿勢のシグナルが含まれています（たとえば、テストファーストや特性化ファーストなど）。タスクを作成する際にそれらを記録してください。
   • Deferred to Implementation または Implementation-Time Unknowns セクションがあるか確認する — これらは計画者が実行中に解決するよう意図的に残した問いです。タスクの途中で不意打ちを食らうのではなく、アプローチに活かせるよう、開始前に記録しておいてください
   • Scope Boundaries セクションがあるか確認する — これらは明示的な非目標です。実装が隣接する作業へと引っ張り始めたら、これらを参照し直してください
   • 計画に記載されている参考文献やリンクを確認する
   • ユーザーがこのセッションで TDD、テストファースト、または特性化ファーストでの実行を明示的に求めた場合は、計画に Execution note がなくてもその要望に従う
   • 不明な点や曖昧な点があれば、今すぐ明確化のための質問をする
   • 上記で明確化のための質問が必要だった場合は、解決した回答についてユーザーの承認を得る。明確化が不要だった場合は、別途承認ステップを設けずに進める — 計画のスコープが計画の権限であり、再交渉するものではない
   • これを省略しないでください - 間違ったものを構築するより、今質問する方が良いです
   • 実行中に計画の本文を編集しないでください。 計画は意思決定の成果物です。進捗は git コミットとタスクトラッカーに存在し、計画には存在しません。ce-work は計画を変更しません — 出荷されたかどうかは git から導出され、ドキュメントには記録されません。旧形式の計画では、単位見出しに - [ ] / - [x] のマークや status: フィールドが含まれている場合があります — それらは状態としては無視してください。単位ごとの完了は、実行中に現在のファイル状態を読むことで判定されます。

2. 環境をセットアップする

   まず、現在のブランチを確認します:

   current_branch=$(git branch --show-current)
   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
   
   # Fallback if remote HEAD isn't set
   if [ -z "$default_branch" ]; then
     default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
   fi
   

   すでにフィーチャーブランチにいる場合（デフォルトブランチではない）:

   まず、ブランチ名が意味のあるものかどうかを確認します — feat/crowd-sniff や fix/email-validation のような名前は、将来の読者にその作業が何についてなのかを伝えます。自動生成されたワークツリー名（例: worktree-jolly-beaming-raven）やその他の意味不明な名前はそうではありません。

   ブランチ名が無意味または自動生成されたものである場合は、続行する前に名前の変更を提案してください:

   git branch -m <meaningful-name>
   

   新しい名前は計画のタイトルや作業内容から導出してください（例: feat/crowd-sniff）。名前の変更は、現状のまま続行する選択肢と並べて推奨オプションとして提示してください。

   次に尋ねてください: 「[current_branch] で作業を続けますか、それとも新しいブランチを作成しますか？」

   • 続行する場合（名前変更の有無を問わず）、ステップ 3 に進みます
   • 新規作成する場合は、以下のオプション A または B に従ってください

   デフォルトブランチにいる場合は、進め方を選択してください:

   オプション A: 新しいブランチを作成する

   git pull origin [default_branch]
   git checkout -b feature-branch-name
   

   作業内容に基づいた意味のある名前を使用してください（例: feat/user-authentication、fix/email-validation）。

   オプション B: ワークツリーを使用する（並行開発に推奨）

   skill: ce-worktree
   # Ensures isolation: detects an existing worktree, prefers the harness's
   # native worktree tool, else creates one from the default branch
   

   オプション C: デフォルトブランチで続行する

   • ユーザーの明示的な確認が必要です
   • ユーザーが明示的に「はい、[default_branch] にコミットしてください」と言った後にのみ進めてください
   • 明示的な許可なくデフォルトブランチに直接コミットしないでください

   推奨: 以下の場合にワークツリーを使用してください:

   • 複数のフィーチャーを同時に作業したい場合
   • 実験中にデフォルトブランチをクリーンに保ちたい場合
   • 頻繁にブランチを切り替える予定がある場合

3. タスクリストを作成する (Phase 0 ですでに作成済みの場合、または Phase 0 で Trivial と判定された場合はスキップ)

   • プラットフォームのタスク追跡ツール（Claude Code の TaskCreate／TaskUpdate／TaskList、Codex の update_plan、または他のハーネスに相当するツール）を使って、計画を実行可能なタスクに分割します
   • 計画に記載された実装単位、依存関係、ファイル、テスト対象、検証基準からタスクを導き出します
   • 計画で実装単位に U-ID が定義されている場合は、タスクの件名の先頭にその単位の U-ID を付けます（例：「U3: パーサーのテスト範囲を追加」）。これにより、ブロッカーの参照、保留作業の記録、最終要約を、計画と同じ識別子にひも付けられます。計画を編集しても進捗と追跡可能性が明確に保たれます
   • 各単位に Execution note がある場合は、その内容をタスクに引き継ぎます
   • 実装に着手する前に、各単位の Patterns to follow フィールドを確認します。ここには、参考にする特定のファイルや規約が示されています
   • 各タスクの主要な完了基準として、その単位の Verification フィールドを使います
   • 計画に実装コード、細かな TDD 手順、正確なシェルコマンドが含まれているとは想定しないでください
   • タスク間の依存関係を設定します
   • 先に行う必要がある作業を優先します
   • テストと品質チェックのタスクを含めます
   • タスクは具体的で、完了可能なものにします

4. 実行戦略を選択する

   委任ルーティングゲート： delegation_active が true で、入力が計画ファイル（単独のプロンプトではない）の場合は、references/codex-delegation-workflow.md を読み、「委任前チェック」と「委任判断」のフローに従います。すべてのチェックに合格して委任を進める場合は、逐次実行を強制し、そのワークフローのバッチ実行ループを使って Phase 2 に直接進みます。いずれかのチェックで委任が無効になった場合は、以下の標準戦略の表に進みます。委任が有効でも入力が単独のプロンプト（計画ファイルなし）の場合は、delegation_active を false に設定し、簡潔な注記「Codex の委任には計画ファイルが必要です。標準モードを使用します。」を添えて、以下の標準戦略の選択に進みます。

   タスクリストの作成後、計画の規模と依存関係に基づいて実行方法を決定します。

   戦略	使用する状況
   インライン	小規模なタスクが 1～2 件の場合、または作業中にユーザーとのやり取りが必要な場合。単独のプロンプトによる作業ではデフォルトです。単独のプロンプトでは、サブエージェントへの割り当てを正当化できるだけの構造化されたコンテキストが得られないことがほとんどです
   逐次サブエージェント	依存関係のあるタスクが 3 件以上ある場合。各サブエージェントには、1 つの単位に集中した新しいコンテキストウィンドウを割り当て、多数のタスクを通じたコンテキストの劣化を防ぎます。計画単位のメタデータ（Goal、Files、Approach、Test scenarios）が必要です
   並列サブエージェント	以下の並列安全性チェックに合格するタスクが 3 件以上ある場合。独立した単位を同時に割り当て、依存する単位は前提タスクの完了後に実行します。計画単位のメタデータが必要です

   並列安全性チェック — 並列割り当てを選ぶ前に必ず実施します。

   1. 候補となる各単位の Files: セクション（作成、変更、テストのパス）から、ファイルと単位の対応表を作成します
   2. 重複がないか確認します。同じファイルパスが 2 つ以上の単位に現れる場合は重複です
   3. 重複があり、ワークツリー分離を利用できない場合：逐次サブエージェントに切り替えます。理由を記録します（例：「単位 2 と 4 は config/routes.rb を共有するため、逐次割り当てを使用します」）。逐次サブエージェントでも、共有ディレクトリへの同時書き込みによる競合を避けながら、コンテキストウィンドウを分離できます
   4. 重複があり、ワークツリー分離を利用できる場合：サブエージェントは分離された環境で作業するため、並列割り当てでも安全です。重複は予測可能なマージコンフリクトとして表面化し、オーケストレーターが以下のバッチ後フローで処理します。バッチ後フローで予想されるコンフリクトがわかるよう、予測される重複を記録します ファイルの重複がなくても、オーケストレーターの作業ディレクトリを共有する並列サブエージェントでは、Git インデックスの競合（ステージングやコミットを同時に行うとインデックスが破損します）やテストの干渉（同時に実行したテストが互いの進行中の変更を取り込むことがあります）が発生します。ワークツリーで分離すれば、どちらも解消できます。以下の共有ディレクトリ使用時の制約は、これらの問題を軽減します。

   サブエージェントの分離 — 並列サブエージェントごとに専用の作業ツリーを用意します。

   • Claude Code（Agent ツール）： isolation: "worktree" と run_in_background: true を渡します。ハーネスは、専用ブランチ上にサブエージェントごとのワークツリーを .claude/worktrees/agent-<id> 配下に作成します。これを利用する前に、.claude/worktrees/ が Git の無視対象になっていることを確認してください。
   • 組み込みのワークツリー分離機能がないその他のプラットフォーム：サブエージェントはオーケストレーターのディレクトリを共有します。

   サブエージェントのディスパッチでは、利用可能なサブエージェントまたはタスクの起動メカニズムを使用します。各ユニットについて、サブエージェントに以下を渡します。

   • 計画ファイルの完全なパス（全体的なコンテキスト用）
   • 対象ユニットの Goal、Files、Approach、Execution note、Patterns、Test scenarios、Verification
   • そのユニットに関連する、解決済みの保留中の質問
   • テストを作成する前に、対象ユニットのテストシナリオが該当するすべてのカテゴリ（正常系、エッジケース、エラー系、統合テスト）を網羅しているか確認し、不足があれば補うよう指示します。

   共有ディレクトリ使用時の制約 — ワークツリーによる分離を利用できない場合にのみ適用します。

   • 各サブエージェントに、次のように指示します。「ファイルをステージング（git add）したり、コミットを作成したり、プロジェクトのテストスイートを実行したりしないでください。すべての並列ユニットが完了した後、オーケストレーターがテスト、ステージング、コミットを行います。」
   • これらの制約により、並行するサブエージェント間での Git インデックスの競合やテストの干渉を防ぎます。
   • ワークツリーによる分離が有効な場合は、これらの制約を省略します。サブエージェントはそれぞれのワークツリーのブランチ内で、ステージング、コミット、担当ユニットのテスト実行を行えます。

   権限モード： サブエージェントをディスパッチする際は、ユーザーが設定した権限設定が適用されるよう、mode パラメーターを省略します。mode: "auto" は渡さないでください。これは bypassPermissions などのユーザーレベルの設定を上書きします。

   各サブエージェントの完了後（直列モード）：

   1. サブエージェントの差分を確認し、変更がユニットの対象範囲と Files: リストに一致していることを検証します。
   2. 関連するテストスイートを実行し、ツリーが正常であることを確認します。
   3. テストが失敗した場合は、次に進む前に原因を特定して修正します。ツリーが壊れた状態で、依存するユニットをディスパッチしないでください。
   4. タスクリストを更新します（計画本文は編集しないでください。進捗はコミットによって記録されます）。
   5. 次のユニットをディスパッチします。 バッチ内のすべての並列サブエージェントが完了した後（worktree 分離モード）：
   6. 現在の並列バッチ内のすべてのサブエージェントが完了するのを待ちます。
   7. 完了した各サブエージェントについて、依存関係の順に：worktree の差分をオーケストレーターのブランチと比較してレビューします。サブエージェントが自身の作業をコミットしていない場合は、その worktree 内でステージしてコミットします。
   8. 各サブエージェントのブランチを、依存関係の順にオーケストレーターのブランチへ順次マージします。マージコンフリクトが発生した場合は、マージを中止し（git merge --abort）、競合したユニットを現在マージ済みのツリーに対して直列に再ディスパッチします — 手動で解決すると、暗黙的に一方の側を選んでしまい、もう一方のユニットの意図を破棄することになります。（並列安全チェックで予測された重複は、共有ディレクトリモードでの暗黙的なデータ損失ではなく、ここでコンフリクトとして表面化します。）
   9. 各マージの後、関連するテストスイートを実行します。テストが失敗した場合は、次のブランチをマージする前に診断して修正します。
   10. タスクリストを更新します（進捗はマージコミットによって記録されます）。
   11. マージ後、各サブエージェントの worktree を削除し、そのブランチを削除します。サブエージェントの結果で返された絶対パスとブランチ名を使用します。
       • まず worktree のロックを解除します — ハーネスはサブエージェントごとの worktree をロックします：git worktree unlock <absolute-path>
       • worktree を削除します：git worktree remove <absolute-path>
       • ブランチを削除します：git branch -d <branch-name>（ブランチはデフォルトで worktree より長く存続し、クリーンアップしないと孤立ブランチとして蓄積されます。小文字の -d は未マージのブランチの削除を拒否しますが、これがまさに望ましい安全策です — 失敗した場合は、強制する前に調査してください）
   12. 独立したユニットの次のバッチ、または次の依存ユニットをディスパッチします。

   バッチ内のすべての並列サブエージェントが完了した後（共有ディレクトリフォールバック）：

   1. 現在の並列バッチ内のすべてのサブエージェントが完了するのを待ってから、いずれかの結果に対して操作を行います
   2. 発見されたファイルの衝突をクロスチェックします：バッチ内のすべてのサブエージェントが実際に変更したファイルを比較します（宣言された Files: リストだけではありません）。サブエージェントは、計画時に想定されていなかったファイルを作成または変更する場合があります — これは想定内です。計画は何をであってどのようにを記述するものではないからです。衝突が問題となるのは、同じバッチ内の 2 つ以上のサブエージェントが同じファイルを変更した場合のみです。共有作業ディレクトリでは、最後に書き込んだ側のバージョンだけが残ります — そのファイルに対するもう一方のユニットの変更は失われます。衝突が検出された場合：まずすべてのユニットの衝突していないファイルをコミットし、その後、共有ファイルについて影響を受けたユニットを直列に再実行して、それぞれが他方のコミット済みの作業の上に構築できるようにします
   3. 完了した各ユニットについて、依存関係の順に：差分をレビューし、関連するテストスイートを実行し、そのユニットのファイルのみをステージし、ユニットのゴールから導出した Conventional メッセージでコミットします
   4. あるユニットの変更をコミットした後にテストが失敗した場合は、次のユニットをコミットする前に診断して修正します
   5. タスクリストを更新します（計画本体は編集しないでください — 進捗はたった今作成したコミットによって記録されます）
   6. 独立したユニットの次のバッチ、または次の依存ユニットをディスパッチします

フェーズ 2：実行

1. タスク実行ループ

   優先順に各タスクについて：

   while (tasks remain):
     - Mark task as in-progress
     - Read any referenced files from the plan or discovered during Phase 0
     - **If the unit's work is already present and matches the plan's intent** (files exist with the expected capability, or the unit's `Verification` criteria are already satisfied by the current code), the work has likely shipped on a prior branch or session. Verify it matches, mark the task complete, and move on. Do not silently reimplement.
     - Look for similar patterns in codebase
     - Find existing test files for implementation files being changed (Test Discovery — see below)
     - If delegation_active: branch to the Codex Delegation Execution Loop
       (see `references/codex-delegation-workflow.md`)
     - Otherwise: implement following existing conventions
     - Add, update, or remove tests to match implementation changes (see Test Discovery below)
     - Run System-Wide Test Check (see below)
     - Run tests after changes
     - Assess testing coverage: did this task change behavior? If yes, were tests written or updated? If no tests were added, is the justification deliberate (e.g., pure config, no behavioral change)?
     - Mark task as completed
     - Evaluate for incremental commit (see below)
   

   ユニットが Execution note を持つ場合は、それに従います。テストファーストのユニットでは、そのユニットの実装前に失敗するテストを書きます。特性評価ファーストのユニットでは、変更前に既存の動作を記録します。Execution note を持たないユニットでは、実用的に進めます。

   実行姿勢のためのガードレール：

   • テストファーストで作業する場合、テストと実装を同じステップで書かないでください
   • 修正または機能を実装する前に、新しいテストが失敗することを検証するのを省略しないでください
   • テストファーストで作業する場合、現在の振る舞いのスライスを超えて過剰に実装しないでください
   • 些細なリネーム、純粋な設定、純粋なスタイリング作業では、テストファーストの規律を省略してください テストの検出 — ファイルを変更する前に、既存のテストファイルを見つけてください（実装ファイルをインポート、参照しているテスト／スペックファイルや、命名パターンを共有しているファイルを検索します）。計画でテストシナリオやテストファイルが指定されている場合は、まずそれらを確認し、次に計画で挙げられていない追加のテストカバレッジも確認してください。実装ファイルを変更する場合は、対応するテストも更新してください。新しい振る舞いには新しいテストを、変更された振る舞いにはテストの変更を、削除された振る舞いにはテストの削除または更新を行います。

   テストシナリオの網羅性 — 機能を持つユニットのテストを書く前に、計画の Test scenarios がそのユニットに当てはまるすべてのカテゴリを網羅しているか確認してください。カテゴリが欠けている場合や、シナリオが曖昧な場合（入力と期待される結果を示さずに「正しく検証する」など）は、テストを書く前にユニット自体のコンテキストをもとに補足してください。

   カテゴリ	該当する条件	不足している場合の導き方
   正常系	機能を持つユニットでは常に該当します	ユニットの Goal と Approach を読み、主要な入出力の組み合わせを確認します
   エッジケース	ユニットに意味のある境界（入力、状態、並行性）がある場合	境界値、空／nil の入力、並行アクセスのパターンを特定します
   エラー／失敗経路	ユニットに失敗モード（検証、外部呼び出し、権限）がある場合	ユニットが拒否すべき無効な入力、適用すべき権限／認証の拒否、処理すべき下流の失敗を列挙します
   統合	ユニットがレイヤーをまたぐ場合（コールバック、ミドルウェア、複数サービス）	レイヤー間の連鎖を特定し、モックを使わずにそれを実行するシナリオを作成します

   システム全体のテスト確認 — タスクを完了とする前に、立ち止まって次を確認してください。

   質問	対応
   これが実行されると、何が起動しますか？ コールバック、ミドルウェア、オブザーバー、イベントハンドラーなど、変更箇所から2段階先まで追跡します。	実際のコード（ドキュメントではなく）を読み、変更対象のモデルのコールバック、リクエストチェーン内のミドルウェア、after_* フックを確認します。
   テストで実際の連鎖を実行していますか？ すべての依存関係がモックされている場合、テストが証明するのはロジックが 単独で 動作することだけであり、相互作用については何も示しません。	実際のオブジェクトを使い、コールバック／ミドルウェアのチェーン全体を通す統合テストを少なくとも1つ作成します。相互作用するレイヤーにはモックを使いません。
   失敗によって孤立した状態が残る可能性はありますか？ コードが外部サービスを呼び出す前に状態（DB 行、キャッシュ、ファイル）を永続化する場合、サービスが失敗するとどうなりますか？再試行で重複が作られますか？	実際のオブジェクトを使って失敗経路を追跡します。リスクのある呼び出しより先に状態が作られる場合は、失敗時にクリーンアップされること、または再試行が冪等であることをテストします。
   この機能を公開しているほかのインターフェースはありますか？ ミックスイン、DSL、代替のエントリーポイント（Agent、Chat、ChatMethods など）。	関連クラスでメソッド／振る舞いを grep します。同等の対応が必要なら、後回しにせず今追加します。
   エラー処理の方針はレイヤー間で整合していますか？ 再試行ミドルウェア、アプリケーションのフォールバック、フレームワークのエラー処理が競合したり、二重実行を引き起こしたりしていませんか？	各レイヤーの具体的なエラークラスを列挙します。rescue の対象リストが、下位レイヤーで実際に送出されるものと一致していることを確認します。

   省略できる場合： コールバックも状態の永続化も代替インターフェースもない、リーフノードの変更。純粋な追加変更（新しいヘルパーメソッド、新しいビュー部分テンプレートなど）であれば、確認にかかる時間は10秒で、答えが「何も起動しないので省略」になる場合もあります。

   特に重要な場合： コールバックのあるモデル、フォールバック／再試行を伴うエラー処理、または複数のインターフェースから公開される機能に関わる変更。

2. 段階的なコミット

   各タスクの完了後、段階的なコミットを作成するかどうかを検討します。

   コミットする場合...	コミットしない場合...
   論理的な単位が完了したとき (モデル、サービス、コンポーネント)	より大きな単位の一部にすぎないとき
   テストが成功し、意味のある進捗があるとき	テストが失敗しているとき
   コンテキストを切り替えようとしているとき (バックエンド → フロントエンド)	振る舞いを伴わない純粋な足場にすぎないとき
   リスクのある/不確実な変更を試そうとしているとき	"WIP" というコミットメッセージが必要になるとき

   経験則: 「完全で価値のある変更を説明するコミットメッセージを書けるか? 書けるならコミットする。メッセージが『WIP』や『partial X』になるなら、待つ。」

   計画に実装単位がある場合は、コミットの境界を決める出発点としてそれらを使用してください — ただし実装中に見つけた内容に基づいて適応させてください。単位が想定より大きい場合は複数のコミットが必要になることがあり、小さな関連単位はまとめてコミットされることもあります。各単位の目標をコミットメッセージに反映させてください。

   コミットワークフロー:

   # 1. Verify tests pass (use project's test command)
   # Examples: bin/rails test, npm test, pytest, go test, etc.
   
   # 2. Stage only files related to this logical unit (not `git add .`)
   git add <files related to this logical unit>
   
   # 3. Commit with conventional message
   git commit -m "feat(scope): description of this unit"
   

   マージコンフリクトの処理: リベースやマージ中にコンフリクトが発生した場合は、すぐに解決してください。インクリメンタルコミットは各コミットが小さく焦点が絞られているため、コンフリクトの解決が容易になります。

   注意: インクリメンタルコミットでは、帰属フッターのないクリーンな conventional メッセージを使用します。最終的なフェーズ 4 のコミット/PR には完全な帰属情報が含まれます。

   並列サブエージェントモード: コミットの所有権は分離モードによって分割されます (フェーズ 1 ステップ 4 を参照):

   • Worktree 分離: サブエージェントは自身の worktree ブランチ内でステージングおよびコミットを行えます。オーケストレーターはバッチ後に依存関係の順序でそれらのブランチをマージします。
   • 共有ディレクトリフォールバック: サブエージェントはコミットしません。オーケストレーターが並列バッチ全体の完了後に各単位をステージングしてコミットします。

3. 既存のパターンに従う

   • 計画では類似のコードを参照しているはずです - まずそれらのファイルを読んでください
   • 命名規則を正確に一致させてください
   • 可能な場合は既存のコンポーネントを再利用してください
   • すでにコンテキストにあるプロジェクトのコーディング標準に従ってください
   • 迷ったときは、類似の実装を grep で検索してください

4. 継続的にテストする

   • 重要な変更のたびに関連するテストを実行してください
   • 最後までテストを待たないでください
   • 失敗はすぐに修正してください
   • 新しい振る舞いには新しいテストを追加し、変更された振る舞いにはテストを更新し、削除された振る舞いにはテストを削除してください
   • モックを使った単体テストはロジックを単独で証明します。実際のオブジェクトを使った統合テストは、レイヤーが連携して動作することを証明します。 変更がコールバック、ミドルウェア、エラーハンドリングに触れる場合は、両方が必要です。

5. 進めながら簡素化する

   関連する実装単位のクラスタ (または 2〜3 単位ごと) を完了したら、最近変更されたファイルを見直して簡素化の機会を探してください — 重複したパターンを統合し、共有ヘルパーを抽出し、コードの再利用と効率を改善します。これはサブエージェントを使用する場合に特に価値があります。各エージェントは分離されたコンテキストで動作し、単位をまたいで現れるパターンを見ることができないためです。

   すべての単位の後に簡素化しないでください — 初期のパターンは重複して見えても、後の単位で意図的に分岐することがあります。自然なフェーズの境界、または複雑さが蓄積されていることに気づいたときに待ってください。

   ce-simplify-code が利用可能な場合は、フェーズの境界 (特に diff が 30 行以上あるフェーズ 3 の前) でそれを呼び出してください。そうでない場合は、変更されたファイルを自分で見直して再利用と統合の機会を探してください。

6. Figma デザイン同期 (該当する場合)

   Figma デザインを使用した UI 作業の場合:

   • デザイン仕様に従ってコンポーネントを実装してください
   • references/agents/figma-design-sync.md を読み、そのローカルプロンプトをシードとして汎用サブエージェントをディスパッチし、実装を Figma デザインと比較してください。型/名前で単独のエージェントをディスパッチしないでください。
   • 特定された視覚的な差異を修正してください
   • 実装がデザインと一致するまで繰り返してください

7. フロントエンドデザインのガイダンス (該当する場合)

   Figma デザインがない UI タスク -- 実装が view、template、component、layout、page の各ファイルに触れる場合、ユーザーに表示されるルートを作成する場合、または計画に明示的な UI/フロントエンド/デザインの用語が含まれている場合:

   • このスキルに含まれるフロントエンドのガイダンスと、現在のリポジトリの指示を適用します。既存のデザインシステムの慣例を守り、実際に操作できる UI コントロールと状態を使用し、レイアウトをレスポンシブに保ち、テキストがはみ出したり重なったりしないことを確認します。
   • ブラウザツールを利用できる場合は、最終検証の前に、変更した UI をデスクトップ幅とモバイル幅で確認します。ブラウザーにアクセスできない場合は、コードレベルでレスポンシブ対応とレイアウトを確認し、ブラウザーでの検証ができなかったことを記録します。
   • 変更がユーザーに見える場合は、引き続きフェーズ 4 でスクリーンショットを撮影します。

8. 進捗を管理する

   • タスクを完了するたびにタスクリストを更新します
   • 障害や予期しない発見を記録します
   • スコープが拡大した場合は新しいタスクを作成します
   • 主要なマイルストーンをユーザーに伝えます
   • 計画で実装単位に U-ID が定義されている場合や、計画または起点となるドキュメントに安定した R-ID（および任意で A/F/AE ID）が付いている場合は、障害、保留作業の記録、タスクの概要、最終検証でそれらを参照します。U-ID は計画の編集をまたいで単位を特定し、R/A/F/AE はブレインストーミングから計画への引き継ぎをまたいでプロダクトの意図を特定します。計画に記載された ID を使い、記載されていない ID を作らないでください。これにより、情報を不要な詳細で埋め尽くすことなく、追跡可能性を保てます。

フェーズ 3〜4：品質チェックと仕上げ作業

フェーズ 2 のタスクがすべて完了し、品質チェックに移行したら、references/shipping-workflow.md を読み、品質チェック、コードレビュー、最終検証、PR 作成、通知を含むリリースワークフロー全体を確認します。

---

Codex 委任モード

引数の解析後に delegation_active が true の場合は、references/codex-delegation-workflow.md を読み、事前チェック、バッチ処理、プロンプトのテンプレート、実行ループ、結果の分類を含む委任ワークフロー全体を確認します。

---

重要な原則

迅速に始め、さらに迅速に実行する

• 最初に一度だけ確認し、その後は実行します
• 完全に理解できるまで待たず、質問して作業を進めます
• 目標は完璧なプロセスを作ることではなく、機能を完成させることです

計画を指針にする

• 作業ドキュメントでは、類似のコードやパターンを参照します
• 参照先を確認し、そのとおりに進めます
• 一から作り直さず、既存のものに合わせます

作業しながらテストする

• 変更のたびにテストを実行し、最後まで先送りしません
• 失敗はすぐに修正します
• 継続的なテストにより、大きな問題を未然に防ぎます

品質をプロセスに組み込む

• Tier 1 を利用できる場合、または Tier 2 の基準に該当する場合はレビューを行います（shipping-workflow.md を参照）

機能を完成させてリリースする

• 次に進む前に、すべてのタスクを完了にします
• 機能を 80% のままにしません
• リリースできない完璧な機能より、完成してリリースできる機能を優先します

よくある落とし穴を避ける

• 分析のしすぎ - 考え込みすぎず、計画を読んで実行します
• 確認質問の省略 - 誤ったものを作った後ではなく、今すぐ質問します
• 計画の参照先を無視する - 計画にリンクがあるのには理由があります
• 最後にまとめてテストする - 継続的にテストしないと、後で問題が起きます
• 進捗管理を忘れる - 作業を進めながらタスクの状態を更新しないと、何が完了したか分からなくなります
• 80% 完了症候群 - 早めに切り上げず、機能を完成させます
• 理由なくレビューを省略する — 利用できる場合は Tier 1 を使用し、shipping-workflow.md の基準に該当する場合に限り Tier 2 に引き上げます。両方を省略する場合は、その理由を記録します
• 計画を人間の作業時間に基づくフェーズに再編する - 実行範囲は計画の実装単位で定義されています。単位ごとの人間の作業時間を見積もったり、複数日にわたる分割を提案したり、「このセッション」で実行する単位をユーザーに選ばせたりしないでください。エージェントはエージェントの速度で実行し、コンテキストウィンドウの負荷は段階的なセッションではなく、サブエージェントへの委任（フェーズ 1 のステップ 4）で対処します。計画ファイルの入力が本当に大きすぎて一度の実行で扱えない場合は、その旨を明確に伝え、スコープを縮小するためにユーザーが /ce-plan に戻るよう提案してください。回避策としてセッションのフェーズを作り出してはいけません。プロンプトのみの入力の場合は、フェーズ 0 の Large ルーティングで、すでに大きすぎる作業に対処しています