team

@team

Trigger: When a task is large enough to benefit from parallel execution with real background workers.

How it works

• omc team start spawns a tmux session with N worker panes
• Each worker pane runs the omc team worker process — polling for tasks
• The coordinator (you, in Cursor) assigns tasks via MCP tools
• Workers pick up tasks, execute them with codex, and write results back
• Results are visible in real time via omc team status or omc team attach

Coordinator Protocol (in Cursor chat)

1. Start the team (run in terminal first):

   omc team start --workers 3 --goal "implement the auth module"
   

2. Load the approved plan: load_plan with the latest approved plan ID.

3. Break into parallel-safe tasks (different files, no shared state):

   assign_task session_id="team-XXX" title="Implement JWT middleware" description="..." assigned_to="worker-1"
   assign_task session_id="team-XXX" title="Write auth routes" description="..." assigned_to="worker-2"
   assign_task session_id="team-XXX" title="Add auth tests" description="..." assigned_to="worker-3"
   

4. Monitor: get_team_status session_id="team-XXX" — or from terminal: omc team status

5. Adversarial verification — when implementation tasks are done, before @review:

   assign_task session_id="team-XXX" title="Adversarial review of worker-1 output"
     description="Your job is to BREAK worker-1's implementation. Find flaws, test edge cases,
     attempt to construct inputs that cause failures. Report every weakness found — do not
     be polite. A flaw you miss here reaches production."
     assigned_to="worker-2"
   

   • The adversarial worker must attempt to break the implementation, not just read it
   • It must try: null inputs, boundary values, concurrent access, wrong types, large inputs
   • It must check: error paths, missing auth checks, SQL injection, unhandled exceptions
   • Result must be: list of flaws found (with severity) or explicit "no flaws found after X attempts"