ce:work-beta

作業実行コマンド

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

はじめに

このコマンドは、作業内容を記述したドキュメント（計画、仕様書、または TODO ファイル）か、作業内容を説明するプロンプトを受け取り、体系的に実行します。要件をすばやく理解し、既存のパターンに従い、品質を維持しながら、機能を完成させてリリースすることに重点を置いています。

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

入力ドキュメント

<input_document> #$ARGUMENTS </input_document>

引数の解析

$ARGUMENTS を解析して、次の任意のトークンを特定します。認識したトークンをそれぞれ取り除いてから、残りを計画ファイルのパスまたはプロンプトとして解釈します。

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

トークンはすべて任意です。指定されていない場合は、以下の優先順位に従って設定を解決します。

あいまいな有効化： 「use codex」、「delegate to codex」、「codex mode」、「delegate mode」など、委任の意図を示す命令形のフレーズも delegate:codex と同等として認識します。プロンプト内で「codex」に言及しているだけの場合（例：「codex converter のバグを修正」）は、委任を有効にしてはいけません。明確な委任の意図がある場合に限り、有効にします。

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

設定の解決順序

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

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

設定（事前解決済み）： !cat "$(git rev-parse --show-toplevel 2>/dev/null)/.compound-engineering/config.local.yaml" 2>/dev/null || cat "$(dirname "$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null)")/.compound-engineering/config.local.yaml" 2>/dev/null || echo '__NO_CONFIG__'

上記のブロックに YAML のキーと値のペアが含まれている場合は、以下に記載されたキーの値を取得します。 __NO_CONFIG__ と表示された場合、ファイルは存在しません。すべての設定は既定値にフォールバックします。 未解決のコマンド文字列が表示された場合は、リポジトリのルートから .compound-engineering/config.local.yaml をネイティブのファイル読み取りツール（例：Claude Code の Read、Codex の read_file）で読み取ります。ファイルが存在しない場合、すべての設定は既定値にフォールバックします。

認識できない値が設定されている場合、その設定は既定値にフォールバックします。

設定キー：

• work_delegate -- codex または既定値の false
• work_delegate_consent -- true または既定値の false
• work_delegate_sandbox -- yolo（既定値）または full-auto
• work_delegate_decision -- auto（既定値）または ask
• work_delegate_model -- 使用する Codex モデル（既定値は gpt-5.4）。値はそのまま渡されます。有効なモデル名であれば使用できます。
• work_delegate_effort -- minimal、low、medium、high（既定値）、または xhigh

以降で使うため、解決した状態を保存します。

• delegation_active -- 委任モードが有効かどうかを示すブール値
• delegation_source -- 委任の解決元を示す argument、config、または default。通知の詳細度を環境ガードが決定するために使用します。
• sandbox_mode -- yolo または full-auto（設定値または既定値）
• consent_granted -- ブール値（設定 work_delegate_consent の値）
• delegate_model -- 文字列（設定値または既定値の gpt-5.4）
• delegate_effort -- 文字列（設定値または既定値の high）

---

実行ワークフロー

Phase 0：入力のトリアージ

<input_document> で提供された内容に基づいて、進め方を判断します。

計画ドキュメント（入力が既存の計画書、仕様書、またはTODOファイルへのファイルパス）→ Phase 1 に進みます。

プロンプトのみ（入力がファイルパスではなく、作業内容の説明）：

1. 作業領域を確認する

   • プロンプトに基づいて、変更する可能性の高いファイルを特定します
   • 該当する領域の既存テストファイルを探します（実装ファイルをインポート、参照、または名前を共有するテスト／specファイルを検索します）
   • 影響を受ける領域のローカルなパターンや規約を確認します

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 Trace、Files、Test Scenarios、Verification などのセクションがある場合は、実行の主な情報源として使用します
   • 各実装単位に Execution note があるか確認します。これは、その単位における計画の実行方針（テストファーストや特性評価ファーストなど）を示します。タスクの作成時に記録してください
   • Deferred to Implementation または Implementation-Time Unknowns セクションがあるか確認します。ここにあるのは、計画作成者が実行時に解決するよう意図的に残した質問です。作業を始める前に確認し、途中で不意打ちにならないよう、進め方に反映してください
   • Scope Boundaries セクションがあるか確認します。これは明示的な対象外事項です。実装が関連作業に広がり始めた場合は、ここを参照してください
   • 計画に記載された参照資料やリンクを確認します
   • このセッションでユーザーがTDD、テストファースト、または特性評価ファーストでの実行を明示的に求めた場合は、計画に Execution note がなくてもその要望に従います
   • 不明確な点や曖昧な点があれば、ここで確認の質問をします
   • 進める前にユーザーの承認を得ます
   • この手順を省略しないでください。誤ったものを作るより、今質問するほうがよいです

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: git-worktree
   # The skill will create a new branch from the default branch in an isolated worktree
   

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

   • ユーザーの明示的な確認が必要です
   • ユーザーが「yes, commit to [default_branch]」と明示的に伝えた後にのみ続行します
   • 明示的な許可なしにデフォルトブランチへ直接コミットしてはいけません

   推奨事項：次の場合はワークツリーを使用してください：

   • 複数の機能を同時に作業したい場合
   • 試行錯誤の間、デフォルトブランチをクリーンな状態に保ちたい場合
   • ブランチを頻繁に切り替える予定がある場合

3. ToDo リストを作成する (Phase 0 ですでに作成されている場合、または Phase 0 で Trivial に振り分けられた場合はスキップ)

   • 利用可能なタスク追跡ツール（TodoWrite、タスクリストなど）を使って、計画を実行可能なタスクに分割します
   • 計画の実装単位、依存関係、ファイル、テスト対象、検証基準からタスクを導き出します
   • Execution note がある場合は、各単位の内容をタスクに引き継ぎます
   • 実装に着手する前に、各単位の Patterns to follow フィールドを確認してください。これらは、踏襲すべき具体的なファイルや規約を示しています
   • 各タスクの主な完了判定には、その単位の Verification フィールドを使用します
   • 計画に実装コード、細かなステップに分けた TDD の手順、正確なシェルコマンドが含まれているとは想定しないでください
   • タスク間の依存関係を含めます
   • 先に完了する必要があるものを優先します
   • テストと品質チェックのタスクを含めます
   • タスクは具体的で完了可能なものにします

4. 実行戦略を選択する

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

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

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

   並列安全性チェック — 並列実行を選ぶ前に必ず実施します：

   1. 候補となる各単位の Files: セクション（Create、Modify、Test のパス）から、ファイルと単位の対応表を作成します
   2. 重複を確認します。同じファイルパスが 2 つ以上の単位に含まれている場合は、重複があります
   3. 重複が見つかった場合は、直列サブエージェントに切り替えます。その理由を記録します（例：「Units 2 and 4 share config/routes.rb — using serial dispatch」）。直列サブエージェントでも、共有ディレクトリに関するリスクを避けながらコンテキストウィンドウを分離できます

   ファイルの重複がなくても、同じ作業ディレクトリを共有する並列サブエージェントでは、git インデックスの競合（同時のステージングやコミットによるインデックスの破損）や、テストの干渉（実行中の変更を別のテスト実行が取り込むこと）が発生する可能性があります。以下の並列サブエージェントに関する制約によって、これらの問題を軽減します。 サブエージェントへの割り当てでは、利用可能なサブエージェントまたはタスクの起動手段を使用します。各ユニットについて、サブエージェントに次の情報を渡します。

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

   サブエージェントを並列実行する際の制約 — ユニットを並列で割り当てる場合（直列またはインラインではない場合）：

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

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

   直列モードで各サブエージェントの作業完了後：

   1. サブエージェントの差分を確認し、変更がユニットの範囲と Files: の一覧に合致していることを確認します
   2. 関連するテストスイートを実行し、作業ツリーに問題がないことを確認します
   3. テストに失敗した場合は、次に進む前に原因を特定して修正します。問題が残った状態で依存するユニットを割り当てないでください
   4. 計画のチェックボックスとタスクリストを更新します
   5. 次のユニットを割り当てます

   並列サブエージェントのバッチがすべて完了した後：

   1. 現在の並列バッチ内のすべてのサブエージェントが完了するまで待ってから、その結果に対応します
   2. 見つかったファイルの競合を相互確認します。宣言された Files: の一覧だけでなく、バッチ内のすべてのサブエージェントが実際に変更したファイルを比較します。計画時に想定していなかったファイルが作成または変更されることがあります。計画は「何をするか」を記述するものであり、「どのようにするか」を示すものではないため、これは想定内です。同じバッチ内で2つ以上のサブエージェントが同じファイルを変更した場合に限り、競合とみなします。共有作業ディレクトリでは、最後に書き込んだ内容だけが残り、他のユニットによるそのファイルへの変更は失われます。競合が見つかった場合は、まず全ユニットのうち競合していないファイルをすべてコミットし、その後、競合したファイルについて該当ユニットを直列で再実行し、各ユニットがコミット済みの変更を引き継ぐようにします
   3. 完了したユニットごとに、依存関係の順序に従って、差分を確認し、関連するテストスイートを実行し、そのユニットのファイルだけをステージングして、ユニットの Goal に基づく Conventional Commit メッセージでコミットします
   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
     - 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 の並列サブエージェントの制約を参照）。このセクションのコミットのガイダンスは、インラインおよび直列実行、ならびに並列バッチ完了後のオーケストレーターのコミット判断に適用されます。

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

   • 計画では類似のコードを参照する必要があります - それらのファイルを先に読んでください
   • 命名規則に正確に一致させる
   • 可能な限り既存のコンポーネントを再利用する
   • プロジェクトのコーディング標準に従う（AGENTS.md を参照。リポジトリが互換性シムをまだ維持している場合に限り CLAUDE.md を使用）
   • 迷ったときは、類似の実装を grep で探す

4. 継続的にテストする

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

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

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

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

   /simplify スキルまたは同等のものが利用可能な場合は、それを使用してください。そうでない場合は、変更したファイルを自分で見直して、再利用と統合の機会を探してください。

6. Figma デザイン同期（該当する場合）

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

   • デザイン仕様に従ってコンポーネントを実装する
   • figma-design-sync エージェントを反復的に使用して比較する
   • 特定された視覚的な差異を修正する
   • 実装がデザインに一致するまで繰り返す

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

   Figma デザインがない UI タスクの場合 -- 実装がビュー、テンプレート、コンポーネント、レイアウト、ページのファイルに触れる、ユーザーに見えるルートを作成する、または計画に明示的な UI／フロントエンド／デザインの文言が含まれる場合:

   • 実装を始める前に、frontend-design スキルを読み込みます
   • スキルの検出、ガイダンス、検証のフローに従います
   • スキルで検証用スクリーンショットが作成された場合は、Phase 4 のスクリーンショット要件を満たしているため、別途キャプチャする必要はありません。スキルがメンタルレビューにフォールバックした場合（ブラウザーにアクセスできない場合）は、Phase 4 で引き続きスクリーンショットをキャプチャしてください

8. 進捗を追跡する

   • タスクを完了するたびにタスクリストを更新します
   • ブロッカーや予期しない発見があれば記録します
   • 作業範囲が広がった場合は、新しいタスクを作成します
   • 主要なマイルストーンをユーザーに伝えます

Phase 3-4: 品質チェックとリリース

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

---

Codex 委任モード

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

---

重要な原則

すばやく始め、さらにすばやく実行する

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

計画を指針にする

• 作業ドキュメントでは、類似するコードやパターンを参照します
• それらの参照先を読み込み、従います
• 一から作り直さず、既存のものに合わせます

作業しながらテストする

• 変更のたびにテストを実行し、最後にまとめて行うことは避けます
• 失敗があればすぐに修正します
• 継続的にテストすることで、大きな問題を未然に防げます

品質を組み込む

• 既存のパターンに従います
• 新しいコードにはテストを作成します
• プッシュ前にリンティングを実行します
• すべての変更をレビューします。単純な追加作業ならインラインで、それ以外はすべて詳細にレビューします

完成した機能をリリースする

• 次に進む前に、すべてのタスクを完了にします
• 機能を 80％ 完了のまま放置しません
• リリースできる完成した機能は、完璧でもリリースできない機能に勝ります

避けるべきよくある落とし穴

• 分析麻痺 - 考えすぎず、計画を読んで実行します
• 確認質問の省略 - 誤ったものを作ってしまってからではなく、今すぐ質問します
• 計画の参照先を無視する - 参照リンクには理由があります
• 最後にまとめてテストする - 継続的にテストしないと、後で問題が起きます
• 進捗の追跡を忘れる - 作業しながらタスクの状況を更新しないと、何が完了したか分からなくなります
• 80％ 完了症候群 - 早々に次へ進まず、機能を完成させます
• レビューの省略 - すべての変更をレビューします。変わるのはレビューの深さだけです