team

Team スキル

使用するタイミング

明示的な $team リクエスト、または耐久性のある tmux ワーカー、共有タスク状態、メールボックス調整、ワークツリー分離が役立つ omx team ... の起動時のみ使用してください。AGENTS.md#durable-runtime-invariants-canonical-ssot を読んでください。このカードに耐久性ルールをコピーしないでください。

入力と前提条件

• 起動形式: omx team [N:agent-type] "<task>"（例: omx team 3:executor "implement X"）。
• tmux -V、$TMUX を持つリーダーセッション、および使用する omx 実行ファイルが必要です。Codex App やプレーンな非 tmux セッションでは、Team が利用可能であるふりをせず、実行環境の境界を説明してください。
• 起動前に、最近の .omx/context/{slug}-*.md でタスクの根拠を確認してください。存在しない場合は簡潔なスナップショットを作成します。目標、根拠、制約、未知の点、影響が予想される箇所を含めてください。
• ネストされた Team 実行は起動しないでください。ワーカーの役割は慎重に選んでください。必要な場合のみ OMX_TEAM_WORKER_CLI=codex|claude|auto または OMX_TEAM_WORKER_CLI_MAP=... を使用してください。
• エージェントごとの推論は agentReasoning で設定します。受け付ける値は low、medium、high、xhigh、max です。max はそのまま渡され、能力に依存します。ultra はサポートされておらず、max の別名でもありません。
• 無効な設定値は組み込みの役割デフォルトにフォールバックします。明示的な生の -c model_reasoning_effort=... は不透明な値として扱われ、優先されます。両方のソースが存在する場合、明示的な生の推論設定は、継承された Team の推論設定および環境の推論設定より優先されます。max を xhigh にダウングレードしたり、再試行したりしないでください。組み込みの役割デフォルトは変更されません。

運用手順

1. ランタイムを開始し、起動の証拠を記録します: Team started: <name>、tmux ターゲット、ワーカーペイン、リーダーの ACK メールボックス。
2. 現在のランタイム動作: ランタイムが管理するタスクファイルと API が運用上のインターフェースです。耐久性のある所有権と安全性のルールは templates/AGENTS.md に残ります。
3. ランタイムは .omx/state/team/<name>/config.json、manifest.v2.json、tasks/task-<id>.json、ワーカーの ID とインボックス、メールボックスファイル、ディスパッチキューを作成します。ワーカーには OMX_TEAM_WORKER、OMX_TEAM_STATE_ROOT、OMX_TEAM_LEADER_CWD が渡されます。
4. 耐久性のあるインボックス/タスク状態と CLI API を通じて割り当てを配信します。ワーカーカードには、ACK、クレーム、遷移、メールボックス、アイドル状態のコマンドが定義されています。
5. 次の機械可読な操作を優先してください:

   omx team api send-message --input '{"team_name":"<name>","from_worker":"leader-fixed","to_worker":"worker-1","body":"<short trigger>"}' --json
   omx team api read-task --input '{"team_name":"<name>","task_id":"<id>"}' --json
   omx team api transition-task-status --input '{"team_name":"<name>","task_id":"<id>","from":"in_progress","to":"completed","claim_token":"<token>"}' --json
   

6. omx team status <name> --json または omx team await <name> --timeout-ms 30000 --json で監視します。ワーカーがブロックされているか古くなっている場合は、メールボックスや状態ファイルを確認してください。
7. pending=0、in_progress=0、failed=0（または明示的に確認された失敗パス）になるまで Team を実行し続けてください。ユーザーが明示的に中止した場合を除き、その後にのみ omx team shutdown <name> を実行してください。
8. シャットダウンの証拠と状態のクリーンアップを確認してください。ワーカーがまだ書き込みを行っている間は、完了を主張しないでください。

Team と Ultragoal

リーダーが所有する .omx/ultragoal/goals.json が存在する場合、ワーカーはタスクの証拠のみを返します。リーダーは最新の Codex get_goal スナップショットでチェックポイントを作成します:

omx ultragoal checkpoint --goal-id <id> --status complete --evidence "<Team evidence>" --codex-goal-json <fresh-get-goal-json-or-path>

Team の起動は明示的かつ独立した操作のままです。隠れた Codex ゴールは作成しません。

ディスパッチと復旧

• ディスパッチが worker_notify_failed:<worker> を報告した場合は、tmux list-panes で確認し、ペインをキャプチャしてから、簡潔なトリガーを一度送信し、メールボックスと状態を再確認してください。
• Claude のペインでは、作業中に Enter を連打しないでください。まずランタイムの状態を確認してください。
• ワーカーが omx team api ... ENOENT を報告した場合は、シャットダウンや状態の削除が早すぎなかったか確認してください。すべての遷移が完了するまで状態を保持してください。
• クリーンな再試行のために、既知の古いワーカーペインのみを終了し、正確に古い Team ルートのみを削除してから再起動してください。リーダー/HUD ペインを誤って終了させないでください。

終了と証拠

Team 名、起動コマンド、ペイン/ACK の証拠、タスク数、ワーカーの検証、失敗やブロッカー、シャットダウンの結果、クリーンアップした状態パスを報告してください。ワークツリーや CLI マップの選択を含め、最終的な統合と検証はリーダーのレーンで行ってください。