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; me
Profile →npx skills add code-yeongyu/oh-my-openagent --skill teammode --agent codex
Same command for any agent — swap --agent for claude-code, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# 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 FIR
- When to use a team (and when to use plain subagents instead)
- Pick the transport FIRST - then tell the user
- You are the leader - orchestrate, do not implement
- Compose by part, ownership, or perspective - not by job title
- Run the script - never hand-write team state
- Create the team and its members
- Communication
- Let members work - do not rush them
- Worktrees - isolate members who would touch the same files
- Run a ulw-plan in parallel
- Archive, delete, and cleanup
- Stop rules
What does the teammode skill do?
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; me
How do I install it?
Run `npx skills add code-yeongyu/oh-my-openagent --skill teammode --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From code-yeongyu/oh-my-openagent, a repository with 67,209 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.