Codex-only team orchestration: run a named team of cooperating Codex workers with durable, script-managed state. MUST USE when the user asks Codex to create, run, coordinate, inspect, archive, or delete a team of agents/threads/sessions, or to work on something as a team in parallel. FIRST inspects the active tool surface (checking tool_search for deferred tools) and tells the user the route: native MultiAgentV2 agents (flat spawn_agent with task_name) when available, Codex App threads as the fa
SkillScore74Maintained
Automatic
◆AI Engineer pack
Last verified 8/7/2026
What it changes
Passed 16 of 22 test cases with the skill, and 5 of 22 without it.
Without skill22%
With skill74%
Checks it passed that the model alone missed
Sets fork_turns to "none".
Invokes interrupt_agent for active members.
Passes --transport codex_app to team.mjs init.
and 12 more in the full report
13 fixed4 passed either way5 still failing1 broke
Pass-rate lift
+52 pp
Tokens
+236%
Agent turns
0%
Response time
-57%
Model gemini-3.6-flashMeasured 8/7/2026v117 of 23 cases passed with skill · 22 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 13
Prompt
You are referencing a Codex App thread with ID `th_12345` in a report to the user. What link protocol format must accompany the raw thread ID?
What was checked, without and with the skill
Checked
Without skill
With skill
Includes the deep link codex://threads/th_12345 next to the thread ID.
Missed
Passed
case-15 · gemini-3.6-flash · 8/7/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md288 lines6 filesincludes scripts
Teammode
Run a named team of cooperating Codex workers under one leader, with durable state on disk.
This is a Codex-only workflow. It never depends on an external terminal runner - it
coordinates through Codex's own collaboration tools plus a bundled state script, on ONE of
two transports chosen up front: native MultiAgentV2 agents, or Codex App threads as the
fallback.
When to use a team (and when to use plain subagents instead)
Use a TEAM when EITHER holds:
the work does NOT split into perfectly isolated pieces, but doing it in parallel is clearly
more convenient - members will need to see and react to each other's findings; or
one task still needs exploration, yet its GOAL is already clear - parallel investigation under
a fixed objective.
Use plain fire-and-forget subagents ($ulw / one-off spawn_agent workers) - NOT a team - when
EITHER holds:
the work IS perfectly isolated, so there is no coordination cost worth paying; or
the GOAL is still ambiguous, where one mind should resolve direction before any fan-out.
A team buys cross-member coordination at a real overhead cost; only spend it when coordination
is the thing you actually need.
Pick the transport FIRST - then tell the user
Before creating any team state, decide which transport this session can run.
Inspect your active tool list and select:
MultiAgentV2 (preferred) - select when the flat V2 collaboration tools are ALL active:
flat spawn_agent whose schema requires task_name, plus send_message, followup_task,
wait_agent, list_agents, and interrupt_agent. Members are durable native agents
addressed by task name / agent path (/root/<task_name>). The namespaced
multi_agent_v1.* surface never qualifies as a team transport.
Codex App threads (fallback) - select when flat V2 is not available but the
codex_app.* thread tools are (create_thread, read_thread, send_message_to_thread,
set_thread_title, set_thread_archived).
Neither set visible - if a tool_search tool is active, search for the missing sets
(e.g. spawn_agent, codex_app) before concluding: some environments defer tools behind
tool search. A hit is only a lead: revalidate that the visible result is the COMPLETE,