Codex Task Split

指示元は分担、中核判断、自身の実装、統合、最終採否を担当する。ワーカーには編集範囲を定めた成果を渡し、調査・局所設計・実装・検証を任せる。提案だけなら工程1まで。開始が承諾された範囲は工程2以降を進める。

ガントの独立タスクchatで使う場合、本書の「指示元」はそのタスクPMである。PMが自分のワーカーを起動・回収・検収し、自身の担当成果の最終採否と許可済みの正式化まで行う。タスクを配置した親オーケストラへワーカー報告や通常判断を転送せず、親のGO・検収・commit代行を追加しない。

計画外の危険や本人判断が必要な事象を確認したら、選択肢UIと完全停止に従い、PMと全ワーカーを止める。本人の明示回答までは別工程も進めず、PMの判断回答やタイマーを本人承認へ読み替えない。

記録は通常、会話と作成先chatを使う。projectに正本があれば既存の担当欄やhandoffから参照し、別台帳は作らない。

1. 成果と実装の担当を決める

原依頼、適用指示、既存のStory・PLAN、担当と差分を読む。委任のために全仕様や詳細設計、全テストケースを作り直さない。

状況	分担
既存契約内で完結し、編集範囲と検収方法が明確	ワーカーへ渡せる。UI、API、状態処理、複数ファイルも対象にでき、局所的な解き方は任せてよい。
認可・所有・状態・資源寿命など未決の共有契約をまたぐ	指示元が中核判断と統合を担当し、境界が決まった成果だけを切り出す。
分担・検収の負担が重い、または共有判断を分離できない	指示元が直接行う。

ワーカーの成果だけでなく、指示元が並行して実装する部分と、回収後に統合する部分を決める。同じ範囲を二重に調査・編集しない。独立した小作業を一括委任して指示元が検収する場合は理由を示す。ワーカーの起動義務や件数ノルマにはしない。

2. 許可・起動先・依頼文を確認する

共通実行条件で実際の許可、直接の指示元ID、host、project、開始元、モデル・推論、環境を確認する。モデルや方式を黙って代替せず、既許可も局所修正ごとに取り直さない。

依頼文に今回の原条件、担当成果、編集範囲、終了条件と確認済みの実行設定を入れる。指定された工程本文と配送本文を展開し、実際のツール引数と照合する。履歴全体のforkや、本スキルの再実行をワーカーに依頼しない。

3. ワーカーを起動し、自分の実装を進める

共通の起動手順を使う。タイトルは選定モデルの表示名、作業ID、成果名を含め、返された実タイトルを記録する。正式thread ID、実設定、cwd、開始HEADを作業に対応付ける。pendingや結果不明は照会して解決し、同じ成果を重複起動しない。

指示元は自分の独立した実装を進める。起動確認後、待機直前、再開直後、成果の観測時は回収手順を使う。通知なしcompletedや未commit成果も回収する。

4. 報告を検収し、修正・引取りを判断する

採否、証拠、同ワーカーへの修正、引取りはmain-reviewで判断する。配送結果が不明な場合だけdelivery、原因不明の停止や反復にはexecution-loopを読む。通常の検収で全資料を読み直さない。

5. 統合・完了処理を行う

検収済みの成果を統合し、原条件に必要な利用動作・失敗条件・Gateを確認する。必要なCLI更新、commit、受渡しを実許可の範囲で行い、処理済みと残件を区別する。

通常担当は承諾された成果群、大規模PMは同じ元IDの残条件へ戻る。担当範囲が終わったら終了し、追加改善や無関係な作業、自動archiveへ広げない。初回の実作業では品質、事前設計、差戻し、手直しを短く振り返る。利用量は取得できた範囲だけ示し、削減率を推測しない。