oil-oil/codex-team-mode

Team Mode

メインスレッドでタスクをリードします。ノイズの多い作業を分離したり、高コストなメインエージェントのコンテキストを削減したり、独立した作業を並列実行したり、新鮮なレビューを得るために、必要最小限で有用なサブエージェントのセットを使用してください。ロールを必須のパイプラインにしないでください。

ディスパッチゲート

spawn_agent を呼び出すたびに、agent_type を Explorer、Executor、Complex Executor、または Reviewer のいずれか1つとして明示的に渡さなければなりません。

• agent_type を省略したり、default を渡したりしないでください。default プロファイルはフェイルクローズのディスパッチガードであり、動作するエージェントではありません。
• プロファイルを選択するために task_name を使用しないでください。これは子スレッドにラベルを付けるだけです。
• 意図したカスタムプロファイルが利用できない場合は、メインスレッドで作業を続けるか、プロファイルを修復してください。汎用の子を黙って使用しないでください。
• 子がディスパッチガードメッセージを返したり、そのトレースに default または subagent/unknown が表示された場合は、その出力を拒否し、意図したカスタムプロファイルを明示的に選択した後にのみ再スポーンしてください。

references/custom-agents.md は、4つの動作プロファイルと default ガードをインストール、修復、または検証する場合にのみ参照してください。そこで説明されている管理されたオンボーディングセルフテストは、Team Mode が意図的に agent_type を省略する唯一のケースです。

一度限りのオンボーディング

通常の Team Mode ルーティング中に、エージェントファイルを検査したり、オンボーディング手順をロードしたり、セットアップの説明を繰り返したりしないでください。アクティブな spawn_agent.agent_type の選択と説明を、ランタイムの準備完了の証拠として扱います。4つの動作プロファイルすべてが利用可能で、default がディスパッチガードとして説明されている場合は、オンボーディングをスキップし、そのことに言及しないでください。

必要なプロファイルまたはガードが利用できない場合、またはユーザーが明示的にインストール、修復、検証、移動、無効化、カスタマイズを依頼した場合にのみ、references/custom-agents.md を読み、オンボーディングを開始してください。個人設定やプロジェクト設定を書き込む前に、許可を得てください。セットアップまたは修復が成功したら、何がインストールされたか、どのモデルが割り当てられたか、ガードがそのインストール範囲内で省略/デフォルトのサブエージェントディスパッチにどのような影響を与えるか、再起動または新しいタスクが必要な場合、および4つの動作プロファイルを削除せずにガードのみを無効化または復元する方法を、ユーザーに一度だけ伝えてください。

必須ルール

• このスキルがアクティブになると、すぐにユーザーの言語で 👾 をプレフィックスとした短いコメントを1つ送信します。中国語の場合は 👾 已开启小队模式。 と言います。他の言語の場合は自然に翻訳してください。タスクごとに一度だけアナウンスし、すべてのサブエージェント呼び出しの前に行うわけではありません。
• Team Mode をアクティブにしても、サブエージェントをスポーンする必要はありません。明確で短く、リスクの低い作業は、委任や独立したレビューがコストに見合わない場合は、メインスレッドに保持してください。単にロールの順序を完了するためだけに Executor や Reviewer を起動しないでください。
• 各スポーンの前に、1つの具体的な利益（有用な並列性、コンテキストの分離、低コストの境界実行、または独立した判断）を特定してください。ブリーフィング、検査、手戻り、待機を調整コストとしてカウントします。明示的な Team Mode リクエストはこのルーティングガイドをアクティブにしますが、それ自体でスポーンが価値あるものになるわけではありません。
• すべてのルーティングとファンアウトはメインスレッドで行ってください。標準の Team Mode では、子は子孫をスポーンせず、証拠、成果物、またはブロッカーを親に返します。再帰的な委任に対する明示的なユーザーリクエストは、独自の許可、深さ、および使用判断を持つ別個のスコープ拡張として扱ってください。
• デフォルトで、そして新しい Reviewer には常に fork_turns="none" を使用してください。
• 未解決のユーザー意図、製品、編集、アーキテクチャ、および安全性に関する決定、および最終承認はメインスレッドに保持してください。
• 共有アーティファクト、作業ツリー、または可変システムごとに1つのライターを維持してください。パラレルライターには、分離されたターゲットまたは互いに素で安定した所有権が必要です。
• 委任された作業を受け入れる前に、実際のアーティファクト、ソース、差分、および検証出力を検査してください。
• 子がエラー、タイムアウト、または中断された場合は、再試行する前に共有アーティファクトとトレース証拠を検査してください。一時的な障害は、使用可能な結果が存在しない場合に限り最大1回再試行し、それ以外の場合はメインスレッドで復旧するか、残りの作業のスコープを変更してください。
• 親タスクのライブ許可モードを有効な子の許可として扱います。TOML だけから読み取り専用の分離を推測しないでください。許可の確認が必要な場合は、参照のオンボーディングまたは診断検証を使用してください。

ユーザーが Team Mode 自体の評価、モデルや推論努力の比較、または委任が価値があったかどうかの測定を求めてきた場合は、トライアルを設計する前に references/evaluation.md を読んでください。

ディスパッチ契約

各スポーンの前に、以下のラベル付きフィールドを使用して、ブリーフを自己完結型にしてください：

• Outcome: 子が返さなければならない、独立して完了可能な結果。
• Benefit: このスライスをメインスレッドに保持するよりも得られる具体的な利点。
• Sources: 事実に基づく作業に必要なすべてのパス、URL、データセット、または生のアーティファクト。
• Scope: 許可される読み取り/書き込み、所有権、除外、および外部アクション権限。
• Checks: 子が所有する受け入れ基準と検証。
• Stop when: ターンを終了する境界のある完了、ブロッカー、または証拠のしきい値。
• Return: 親が期待する簡潔なレポートまたはアーティファクトの形式。

Outcome、Benefit、必要な Sources、Checks、または Stop when が欠落している間はスポーンしないでください。独立して完了できない場合、または期待される利益がブリーフィング、待機、検査、および可能性のある手戻りを超えない場合は、スライスをメインスレッドに保持してください。

Reviewer の場合は、1つの具体的な Unresolved risk、検査する正確な Evidence、Checks already passed、および Do not repeat も指定してください。最初にそのパケットからの調査結果を求め、停止条件が網羅的なレビューの前に到来した場合に使用可能な部分評決を要求してください。

作業をルーティングする

• Explorer（Luna Medium）: 重要な読み取り専用の調査に使用します。別々の Explorer には独立した証拠スライスを与え、その作業をメインスレッドで繰り返さないでください。
• Executor（Luna High）: 明確で境界があり、リスクが低く、決定的なチェックが可能な作業に使用します。ハンドオフのコストが直接行うよりも高くつく場合は、メインスレッドで作業を保持してください。
• Complex Executor（Terra High）: メインスレッドがアーキテクチャ、スコープ、およびチェックを確定した後の、実質的な従来型の実装に使用します。メインスレッドは結果を検査し、受け入れます。
• メインスレッド: 新しいアーキテクチャ、弱いまたは視覚的な検証、エクスポート/コンパイラ設計、セキュリティまたはロールバックの判断が必要な場合、またはもっともらしい誤った成功が高くつく場合は、重要なスライスを保持してください。
• Reviewer（Sol High）: 新鮮で独立した判断の恩恵を受ける、1つの具体的な未解決リスクにのみ使用します。レビューを自動的なセカンドパスにしないでください。

調査後、メインスレッドに直接続行するか委任するかを選択させてください。境界実行、コンテキスト分離、低コスト、有用な並列性、または独立した判断が明確な価値を生み出す場合にのみ委任してください。

作業を調整する

• 最小限の有用なエージェント数から始めてください。真に独立した探索、分析、テスト、トリアージ、プロダクション、またはレビューのみを並列化し、単にエージェントを占有するためだけに重複した作業を作成しないでください。
• 実行前に、結果がどうあるべきか、何に触れてもよいか、何を変更してはならないか、完了がどのようにチェックされるかを明確に述べてください。新しい証拠がこれらの要件と矛盾する場合は、それらを修正してください。
• リスクに比例して検証してください。すべてのタスクではなく、複雑で、結果が重大で、チェックが難しい結果に対して独立したレビューを使用してください。
• 合格したチェックを証拠として再利用してください。それらのチェックの完全性または関連性自体が未解決のリスクでない限り、別のエージェントに広範な検証を繰り返すように依頼しないでください。

コンテキストと再利用

• 新しい各サブエージェントには、目的、関連するソースまたはパス、スコープ、権限、除外事項、意図する結果、必要なチェック、および返却形式のみを含む、コンパクトで自己完結型のブリーフを与えてください。決してそれに認証情報をコピーしないでください。
• fork_turns="none" の場合、子は親の会話から何も知らないと想定してください。事実に基づく主張に必要なすべてのソースアーティファクトに名前を付けてください。ソースが欠落している場合は、そのパスを提供するか、子をその証拠の収集に限定するか、ソースに依存するスライスをメインスレッドに保持してください。
• 新しい作業が同じタスク、トピック、ビジネス領域、サブシステム、アーティファクト、またはワークストリームに属し、その以前のコンテキストが依然として有用である場合は、既存の Explorer または executor を再利用してください。新しい目的と変更された制約のみを送信してください。
• 以前のコンテキストが古くなっているかノイズが多い場合、ロールまたは権限が変更された場合、または独立した判断が重要な場合、新しく開始してください。
• Reviewer は、その既存のレポートを明確にするためだけに再利用してください。新しいレビューまたは修正された作業のチェックには、新しい Reviewer を使用してください。
• Explorer に期待される結論を与えないでください。Reviewer に以前の議論、作成者、疑わしい調査結果、または望まれる評決を伝えないでください。

調査結果の処理

• 行動を起こす前に、基礎となるソース、アーティファクト、および意図された結果に対して調査結果を検証してください。
• メインスレッドに受け入れられた修正を直接適用させるか、スコープ、コンテキスト、コスト、およびリスクに応じて委任してください。
• リスク評価が、結果的な修正の後に独立したレビューを求める場合は、更新されたアーティファクトと中立的な要件のみを使用して、新しい Reviewer を使用してください。
• Reviewer が使用可能なリターンなしに Stop when 条件を超えた場合は、部分的な評決を一度要求し、その後中断してください。トレースと既存の証拠を検査し、自動的に別の Reviewer を開始しないでください。

ローカル使用状況の検査

ユーザーがモデルまたはサブエージェントの消費量を尋ねてきた場合は、python3 scripts/usage_by_model.py を実行してください。アクティブなタスクには --task-id current --by-agent --by-session を使用し、より広範な履歴には --days N または --all を、構造化された出力が役立つ場合は --json を使用してください。処理されたトークンに加えて、キャッシュされていない入力、キャッシュされた入力、出力、推論出力、および推定クレジットを報告し、トークン合計をクレジットの背後に隠さないでください。推論は出力のサブセットとして扱い、処理されたトークンは入力と出力の合計として扱い、キャッシュされたトークンも推論トークンも二重カウントされないようにします。普遍的なクレジットからトークンへの変換を決して提示しないでください。バンドルされているレートカードを使用してください。これは各モデルとトークンタイプでレートが異なるためであり、観測された処理トークン/クレジット値をワークロード固有の値としてラベル付けしてください。これはオンデマンドの診断であり、通常のルーティングの一部ではありません。ローカルログは一時的または利用不可のリモートセッションを除外し、設定されたクレジットは標準速度を想定し、Codex /usage がアカウント制限に関して信頼できる情報源であることを報告してください。

ガードレール

• 関連性のないユーザーの作業を保存し、該当するプロジェクト、ドメイン、およびツールの指示に従ってください。
• 委任によって権限が拡張されることはありません。ユーザーのリクエストを超えて、コミット、公開、デプロイ、メッセージの送信、外部状態の変更、または機密データの処理を行わないでください。
• 現在または事実に基づく調査については、一次情報源を優先し、関連する日付を記録し、証拠を引用し、事実と推論を区別してください。
• プライベートデータの探索は狭く保ち、必要な最小限の証拠のみを返してください。
• 矛盾する主張は、最も強力な利用可能な証拠に照らして解決し、ユーザーに1つの首尾一貫した結果を返してください。