Ported from oh-my-codex team. OMX runtime conventions ($macro invocation, omx team CLI, tmux panes, .omx/ state directory) are replaced with WorkBuddy idioms (TeamCreate, Agent tool, SendMessage, Task tools, .workbuddy/ memory).

Team Skill

team is WorkBuddy's coordinated multi-agent execution mode. There is no tmux runtime and no omx team CLI — coordination is built from the TeamCreate tool (team + shared task board), the Agent tool (teammates), the SendMessage tool (mailbox/dispatch), and the Task tools (single source of truth). Treat this skill as an operator workflow, not a generic prompt pattern.

In non-team surfaces (plain single-session chat without a created team), do not present team as directly available; first call TeamCreate, or stay on the nearest single-agent surface until the user explicitly wants the multi-agent runtime.

Team vs Native Subagents

• Use a single Agent tool call (or a few run in parallel) for bounded, in-session parallelism where one leader thread can fan out a few independent subtasks and wait for them directly, with no shared mutable files.
• Use team when you need durable shared task state, explicit handoffs, role separation (delivery vs. verification), cross-boundary ownership, or long-running parallel execution that must stay tracked across the session and survive beyond one local reasoning burst.
• Native Agent fan-out can complement team execution, but it does not replace the team runtime's stateful coordination contract (shared task board, mailbox, lifecycle control).

What This Skill Must Do

When the user triggers team, the leader (you) must: