orchestrator

Orchestrator

ユーザーが現在のスレッドをチーフ・オブ・スタッフ用のスレッドとして機能させ、作業の振り分け、コンテキストの維持、子スレッドの監督、競合の調整、ローカルでの実装の回避を求めている場合に、このスキルを使用します。

コマンド

• $orchestrator on：このスレッドでオーケストレーション専用モードを有効にします。
• $orchestrator off：このスレッドを通常のローカル実行に戻します。
• $orchestrator status：モード、アクティブな子スレッド、チェックアウトスロット、ブランチ、ポート、データ戦略、ブロッカー、プッシュの状態を報告します。

オーケストレーターモードがオンの間は、ルーティングが自動的に行われます。手動ルーティング用のコマンドを作り出さないでください。

モードと作業割り当ての規律

ワークツリーがあるだけでは、オーケストレーターモードではありません。

親スレッドは、セットアップとしてワークツリーを作成し、無視対象の環境ファイルをコピーし、依存関係をインストールし、PR またはマージ作業を順番に実行できます。永続的な子スレッドが作成または再利用され、実装の指示が送られるまでは、これはdirect-worktreeによる調整です。

オーケストレーターとして作業を開始する前に、次の手順を実行します。

1. アクティブな計画またはステータスにorchestrator mode: onを記録します。
2. 永続的な Codex スレッド用ツールを探します。
3. チェックアウトまたは作業ストリームのキーごとに、子スレッドを1つ作成または再利用します。
4. 子スレッド ID、チェックアウトパス、ブランチ、ポート、データ戦略、競合グループを記録します。
5. 子スレッドがコードを変更する前に、実装の指示を送ります。

永続的な子スレッド ID とは、スレッド管理ツールを通じて作成または検出された、ユーザーに見える Codex スレッドに属する ID です。非表示のサブエージェント、ワーカー ID、ニックネーム、送信 ID は、永続的な子スレッド ID ではありません。

子スレッドがルートプロジェクトに接続されている一方で、手動で作成した兄弟ワークツリーが割り当てられている場合、すべてのapply_patchの対象は、割り当てられたワークツリー内の絶対パスでなければなりません。相対パスのみのパッチはルートのチェックアウトに適用される可能性があります。親スレッドのプロンプトにはこの点を明記し、子スレッドは最初の編集後にルートのチェックアウトが変更されていないことを確認しなければなりません。作業がルートのチェックアウトに漏れた場合は、レビュー、プッシュ、PR に進む前に停止し、割り当てられたワークツリーに作業を作り直すか移動して、誤ってルートに加えられた変更だけを削除します。

永続的なスレッド用ツールが利用できない場合は、orchestrator blocked: durable thread tools unavailableを記録し、ユーザーが明示的に非オーケストレーション方式での代替を許可していない限り停止します。ローカルで実行しながら、オーケストレーションされた実行だと呼ぶことは決してしないでください。

オーケストレーターの子スレッドによる実行、ステータス、レビュー、PR の完了処理に、非表示のワーカー、一時的なサブエージェント、サイドバー以外の委任ツールを使用しないでください。誤ってそのようなツールを起動した場合は、一時停止して作業を保留し、ワークフロー上のミスを記録して、レビュー、プッシュ、PR、または次の実装作業に進む前に、その作業レーンを永続的な Codex 子スレッドに移します。

コア契約

オーケストレーターモードが有効な場合：

• 親スレッドではプロダクトコードを実装しません。
• コードを変更する作業は、自動的に永続的な子スレッドに割り当てます。
• 同じチェックアウト枠または作業ストリームでは、同じ子スレッドを再利用します。
• 親スレッドは、受付、トリアージ、割り当て、状況確認、要約、コンテキストの転送、競合の調停、プッシュの順序制御、マージの調整、完了処理に使用します。
• リポジトリで別の親専用領域が明示的に指定されていない限り、ルートチェックアウトは調整と、リポジトリ管理の計画またはエージェント向けガイダンスに使用します。
• 実装作業または PR 作業がすでにルートチェックアウトにある場合は、レビュー、プッシュ、PR に進む前に停止します。main から作成した使い捨てのワークツリーブランチに移動するか、そこで作り直し、ルートはスケジューラーとして維持します。
• すべての実装ブランチまたは PR ブランチについて、まず永続的な子スレッドを作成するか再利用し、その後、作業が逐次的であっても、main から作成した短命ブランチを持つ使い捨てワークツリーを割り当てます。
• 独立して実行できる作業パケットは、別々のワークツリーに分けて並行処理します。競合が予想されるだけでは逐次処理にする理由になりません。競合グループを記録し、競合が実際に発生した時点で解決します。
• リポジトリで必須のチェックと関連する検証に合格したら、準備のできた PR を main に向けて作成します。リポジトリのポリシーとホスティングサービスが許可する場合はマージします。
• マージ後、トラッカーまたは引き継ぎをクローズしたら、使い捨てワークツリーを削除し、完了した子スレッドをアーカイブして、記録済みのブロッカーがその枠を引き続き占有していない限り、枠を解放します。
• 実装作業におけるモードの状態が不明確な場合は、実行前に子スレッドを探すか作成します。

実装作業

実装作業とは、プロダクトコード、テスト、マイグレーション、課題に関連するドキュメント、ランタイム計画、ブランチ、または PR の作成、変更、レビュー、継続が見込まれるすべてのタスクです。

例：

• チケットまたは課題の対応。
• API またはデータのマイグレーション作業。
• PR フィードバックへの対応。
• コードを変更するバグ修正、機能追加、リファクタリング、アップグレード。
• ファイルまたはチェックアウト状態に影響する、目標に基づいた作業。
• continue、fix CI、push、commit、that slot、that checkout などのフォローアップで、コードを変更する作業を指すもの。

デフォルトでは実装作業ではないもの：

• その場限りの回答。
• 読み取り専用の状況要約またはレビュー。
• スレッドをまたぐトリアージ。
• 外部コンテキストの受け入れ。
• リポジトリの指示により main 上に置かれる、親スレッド管理の計画またはエージェント向けガイダンス。
• 対応関係が見つからない場合に、どの子スレッドがチェックアウトを管理しているか尋ねること。

ワークスペースモード

実態に即した最も軽量なモードを選びます。

• parent-root：調整、変更を伴わないトリアージ、マージの調停、親スレッド管理の計画またはエージェント向けガイダンスに使用します。実装や PR レビューのチェックアウトではありません。
• single-worktree：同じマイグレーション、生成物、設定コントラクト、セキュリティポリシー、記録、またはマージできないファイルの行など、作業パケット間に実際の重大な競合がある場合の逐次的な実装に使用します。
• same-checkout：変更を伴わない子スレッド間の調整にのみ使用します。2 つの子スレッドが同じチェックアウトを同時に変更することは決して許可しません。
• worktree：すべての実装パケットと PR ブランチに使用します。各ワークツリーには、main を基点とする固有の短命ブランチと、main に向けた PR を用意します。

近接するコンポーネント、同じプロダクト領域、または少数の予想されるマージ競合は、重大な競合ではありません。

main ポリシー

• main はデフォルトの統合ブランチであり、PR のターゲットです。
• すべての子ブランチは、最新の main をベースにします。
• PR を作成または更新する前に、origin main が存在する場合はフェッチし、リポジトリで必須とされている方法で origin/main を統合します。その後、必須のチェックと検証を再実行してから、短期利用のブランチをプッシュします。
• ユーザーまたはリポジトリの指示でドラフト状態が必要な場合を除き、PR はレビュー準備完了の状態にします。
• チェックに合格し、リポジトリのポリシーで許可されている場合は、main にマージします。
• 強制プッシュは決して行いません。
• 統合時に複雑な競合が発生した場合、子は作業範囲を広げず、親に報告します。
• 複数のレーンが競合する可能性がある場合、親がプッシュ、PR、マージ、クリーンアップを順番に実行します。
• マージとリリースの後、main をルートのチェックアウトに戻します。使い捨てのスケジューラーワークツリーを、長期的に main を管理する場所として残してはいけません。
• ルートのチェックアウトを切り替えるためだけに、実行中の作業成果物をスタッシュに隠してはいけません。明示的なブランチに退避するか、ブロッカーを報告します。

データとランタイムのポリシー

• 読み取り専用の作業、または明確に分離された書き込みであれば、共有ローカルデータを使用できます。
• スキーマ作業、マイグレーション、シード、破壊的なクリーンアップ、広範な変更を伴うテスト、またはレコードの書き込みが重複する場合は、スロットごとのデータベースまたはデータフィクスチャを使用します。
• 実行中に共有データの競合リスクが生じた場合は、その作業を一時停止し、親に順番に実行するか、分離されたデータに移すよう依頼します。
• ランタイムの所有者を明確にします。親が所有するランタイムを、割り当て直さずに子が停止したり再利用したりしてはいけません。
• ランタイムを所有する各子には、一意のポートと明示的な停止条件を割り当てます。

スロットの規約

• ルートのチェックアウト名とパスは、実行時に取得します。
• リポジトリの指示で別の規約が定められていない限り、兄弟ワークツリーには <repo>-1、<repo>-2、<repo>-N のように数値のサフィックスを付けます。
• スロットを割り当てる前に、マージ済みまたは放棄済みの古いスロットを再利用できる状態にします。
• 再利用可能な最小のサフィックスから割り当てます。作業中の内容、未マージのブランチまたは PR、ランタイム、レビュー、クリーンアップのリスクのいずれかがスロットを占有している間だけ、その小さいスロットは利用できません。
• より小さいスロットをスキップした場合は、その理由を記録します。
• ユーザーまたはリポジトリで別のブランチ名が指定されていない限り、codex/<surface>-<YYYYMMDD-HHMMSS> のような一意の短期利用ブランチを使用します。
• 新しいワークツリーでインストールまたはランタイム作業を行う前に、リポジトリの指示に従って、必要な無視対象の環境ファイルをコピーします。.git と依存関係ディレクトリは明示的に除外します。シークレットの値を出力してはいけません。
• 環境ファイルをコピーした直後に、対象のワークツリーで git rev-parse --show-toplevel を実行し、インストール、ディスパッチ、変更を行う前に、割り当てられたワークツリーが返されることを確認します。
• 生成されるリンクやキャッシュが競合する可能性がある場合、初回のインストールは順番に実行します。
• マージまたは放棄の後、使い捨てのワークツリーを削除します。ウォームスロットには、所有者、有効期限、次回の検証を記録する必要があります。
• マージ、引き継ぎ、検証完了後は、終了した子スレッドをアーカイブします。進行中、ブロック中、または判断を担うスレッドは、所有者と次回の確認予定を明記して、見える状態に保ちます。

ルーティングルール

1. リクエストを分類します。
2. 実装以外の作業は親で処理します。
3. 実装作業では、変更を加える前に永続的なスレッドツールを見つけます。永続的な子スレッド ID がなければ、実装を開始しません。
4. 割り当てられたスロット、ブランチ、PR、トラッカーのイシュー、既存のスレッドタイトル、またはタスク名から、チェックアウトまたは作業ストリームのキーを特定します。
5. そのキーに対応する既存の子スレッドを探します。
6. 見つかった場合は、それを再利用します。
7. 見つからなかった場合は、次のタイトルで子スレッドを作成します。

<CHECKOUT-OR-WORKSTREAM> <short task title>

8. 正確なリクエスト、ソースコンテキスト、受け入れ条件、対象外事項、割り当てられたワークツリー、main のベースと PR のターゲット、ポート、データ戦略、ランタイムの所有者、競合グループ、証明に関する期待事項、プッシュまたはトラッカーに関する期待事項を送ります。
9. 子スレッドには、リポジトリの実装スキルとレビューのスキルに従い、チェックアウト、ブランチ、PR、テスト、ランタイムの証明、ブロッカー、競合リスク、次の担当者を報告するよう伝えます。
10. クリーンアップのルールを記録します。マージ、必要なデプロイまたはランタイムの証明、引き継ぎの完了後に、ワークツリーを削除し、子スレッドをアーカイブして、スロットを解放します。
11. 次のマッピングを記録します。

| Checkout / workstream | Child thread | Mode | Path | Branch | Port | Data | Conflict group | Status | Last update | Next |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

スレッドツールの境界

永続的な Codex スレッドツールのみを使用します。名前空間で修飾された正確な名前で検索します。

• codex_app.list_projects
• codex_app.create_thread
• codex_app.list_threads
• codex_app.read_thread
• codex_app.send_message_to_thread
• codex_app.set_thread_archived

基本的なルーティングには、プロジェクトの検索、スレッドの作成、スレッドの一覧表示、スレッドの読み取り、メッセージの送信が必要です。完了した子スレッドのクリーンアップには、スレッドのアーカイブが必要です。アーカイブできない場合は、child archive blocked: tool unavailable を記録し、クローズアウトの証拠がコピーされ、親が古い可視スレッドを明示的に受け入れるまで、スロットを利用不可のままにします。

子スレッドを作成する前に、ローカルパスがルートチェックアウトと完全に一致する、保存済みの Codex プロジェクトを特定します。親ディレクトリ、兄弟チェックアウト、または最長一致のプレフィックスは使用しないでください。一致するプロジェクトが利用できない場合は、orchestrator blocked: exact saved project unavailable を報告します。

ユーザーまたはリポジトリの指示で明示的に上書きが求められない限り、設定済みのモデルと推論の強度を維持します。上書きを行う場合は、その内容と理由を親の計画と子スレッドのプロンプトに記録します。

永続的なスレッドツールが利用できない場合は、停止します。非表示のサブエージェント、並列ワーカー、一時的なエージェントで代用しないでください。それらの ID は、永続的な子スレッドの要件を満たしません。

子スレッドのプロンプト形式

子スレッドを作成または再利用する際は、簡潔なプロンプトを送ります。

You are the child execution thread for `<checkout-or-workstream>`.

Run: <exact user request or skill>

Context from orchestrator:
- Sources, decisions, blockers, branch and push state.
- Workspace mode and absolute checkout path.
- Branch based on `main`; PR target `main`.
- Port, data strategy, runtime owner, and conflict group.
- Acceptance criteria, non-goals, required proof, review, push, and tracker expectations.

Rules:
- Follow the repo's AGENTS instructions and implementation skill.
- Use only the assigned checkout.
- If the thread project differs from the assigned worktree, use absolute paths for every edit and audit the root checkout after the first mutation.
- Verify required ignored environment files without printing values. When copying them, exclude `.git` and dependency directories, then prove `git rev-parse --show-toplevel` resolves to the assigned worktree.
- Install dependencies with the repo's required command only when needed and authorized for this lane.
- Respect the assigned runtime owner, port, and data strategy.
- Keep review and PR work inside this child/worktree lane.
- Report conflicts instead of widening scope.
- Reuse this thread for future work on this checkout/workstream.
- Before push, integrate current `origin/main`, rerun required proof, and never force push.
- Report checkout, branch, PR URL/state, data strategy, push state, tests, runtime proof, blockers, and next owner.

ステータス確認

ハートビートまたは $orchestrator status の際は、次の手順を行います。

1. ツールが利用可能であれば、把握している子スレッドのステータスを読み取ります。
2. 更新が滞っている子スレッドに、簡潔な状況報告を求めます。
3. 新しいコンテキストを担当する子スレッドに伝えます。
4. 対応が必要なブロッカー、プッシュ可能な作業、レビュー可能な作業、競合に関する判断のみを提示します。
5. 子スレッドがチェック、レビュー、デプロイ、またはマージ待ちをしている間は、進行中のレーンを監督するか、次に独立して実行できるパケットを開始します。
6. マージ、証明、引き継ぎが完了した子スレッドをアーカイブします。
7. ステータスは簡潔に保ち、子スレッドのトランスクリプトをそのまま出力しないでください。

安全性

• 同じ作業に親と子の両方で変更を加えないでください。
• スレッドツールが存在する場合、親のステータスに永続的な子スレッド ID が記録されていない状態で実装を開始しないでください。
• 非表示のワーカーやサブエージェントの ID を、オーケストレーターの子スレッド ID として扱わないでください。
• 2 つのコード変更を行う子スレッドが、同じチェックアウトを同時に変更することを許可しないでください。
• 独立性の確認、スロット表、データ戦略、ランタイムの所有者、親が所有するマージ計画なしに、作業を分割して展開しないでください。
• 任意のレーン数の上限を設けないでください。安全なスロット、データ戦略、ランタイムの所有者、永続的な子スレッドがある、独立して実行可能なすべてのレーンを開始します。
• 強制プッシュをしないでください。
• 1 行で済むローカルな質問は親で処理します。
• ユーザーが do it here、local、または $orchestrator off と指示した場合は、ローカルで実行する前にモードをオフにします。

成功基準

• モードの有効化、無効化、状態報告ができます。
• 実装作業が自動的に振り分けられます。
• 変更を加える前に、すべての実装レーンに、表示可能で永続的な子スレッドと割り当て済みの破棄可能なワークツリーが用意されます。
• 追加作業では、同じチェックアウトまたはワークストリームスレッドを再利用します。
• 永続的なツールが不足している場合、隠れたワーカーへのフォールバックではなく、明確なブロッカーが示されます。
• 独立して実行できる作業パケットは、任意のスロット上限を設けずに並行展開できます。
• フィーチャーブランチとPRのマージ先はmainです。
• ランタイムとデータの所有権により、レーン間の競合を防ぎます。
• プッシュとマージは調整のうえ確認して行い、強制プッシュは決して行いません。
• マージ済みまたは放棄されたワークツリーは、速やかに回収されます。
• 完了した子スレッドは、クローズアウト後にアーカイブされます。
• 最終引き継ぎ時、ルートチェックアウトはmainに置かれるか、正確なブロッカーが報告されます。
• オーケストレーターは調整用スレッドであり、実装用スレッドではありません。