Agent skill · operations · code-yeongyu
teammode
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 fallback, or a plain-subagent split when neither set exists. The main session is always the leader; members are defined by a concrete part, ownership area, or perspective - never a vague job role; a bundled cross-platform script writes the .omo/teams state plus an auto-generated member field manual. Use a team when the work is not perfectly isolated but parallelizing helps; use plain subagents when scope is perfectly isolated or the goal is ambiguous. Triggers: team mode, teammode, make a team, run as a team, team of agents, coordinate threads, parallel Codex threads, archive the team.
Why this skill is useful
Adds a bundled cross-platform script for managing team state and coordination that isn't available in public documentation.
What it needs
Requires codex installed locally. About 12k tokens when loaded. Last updated 2026-08-07. 67,387 stars on the source repository.
What this skill does
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 spawnagent 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: 1. MultiAgentV2 (preferred) - select when the flat V2 collaboration tools are ALL active: flat spawnagent whose schema requires taskname, plus sendmessage, followuptask, waitagent, listagents, and interruptagent. Members are durable native agents addressed by task name / agent path (/root/<taskname>). The namespaced multiagentv1. surface never qualifies as a team transport. 2. Codex App threads (fallback) - select when flat V2 is not available but the codexapp. thread tools are (createthread, readthread, sendmessagetothread, setthreadtitle, setthreadarchived). 3. Neither set visible - if a toolsearch tool is active, search for the missing sets (e.g. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills code-yeongyu/teammode