claudecode-omc 5.11.0 → 5.13.0

package/bundled/upstream/oh-my-claudecode/skills/team/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: team
-description: N coordinated agents on shared task list using Claude Code native teams
+description: N coordinated agents on shared task list using Claude Code implicit agent teams
 argument-hint: "[N:agent-type] [ralph] <task description>"
 aliases: []
 level: 4
@@ -8,7 +8,7 @@ level: 4
 
 # Team Skill
 
-Spawn N coordinated agents working on a shared task list using Claude Code's native team tools. Replaces the legacy `/swarm` skill (SQLite-based) with built-in team management, inter-agent messaging, and task dependencies -- no external dependencies required.
+Spawn N coordinated agents working on a shared task list using Claude Code's implicit agent team. Claude Code 2.1.178+ removed native `TeamCreate`/`TeamDelete`; with `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`, each session has one implicit team and teammates are spawned directly with the Agent/Task tool using distinct `name` values. This skill still preserves OMC's legacy tmux/CLI worker orchestration where documented (`omc team` / `/omc-teams`).
 
 The `swarm` compatibility alias was removed in #1131.
 
@@ -23,7 +23,7 @@ The `swarm` compatibility alias was removed in #1131.
 ### Parameters
 
 - **N** - Number of teammate agents (1-20). Optional; defaults to auto-sizing based on task decomposition.
-- **agent-type** - OMC agent to spawn for the `team-exec` stage (e.g., executor, debugger, designer, codex, gemini). Optional; defaults to stage-aware routing. Use `codex` to spawn Codex CLI workers or `gemini` for Gemini CLI workers (requires respective CLIs installed). See Stage Agent Routing below.
+- **agent-type** - OMC agent to spawn for the `team-exec` stage (e.g., executor, debugger, designer, codex, gemini, antigravity). Optional; defaults to stage-aware routing. Use `codex` to spawn Codex CLI workers, `gemini` for Gemini CLI workers (enterprise/API-key tier), or `antigravity` for Antigravity CLI (`agy`) workers (Google's successor to the Gemini CLI; requires respective CLIs installed). See Stage Agent Routing below.
 - **task** - High-level task to decompose and distribute among teammates
 - **ralph** - Optional modifier. When present, wraps the team pipeline in Ralph's persistence loop (retry on failure, architect verification before completion). See Team + Ralph Composition below.
 
@@ -39,7 +39,9 @@ The `swarm` compatibility alias was removed in #1131.
 /team 2:codex "review architecture and suggest improvements"
 # With Gemini CLI workers (requires: npm install -g @google/gemini-cli)
 /team 2:gemini "redesign the UI components"
-# Mixed: Codex for backend analysis, Gemini for frontend (use /ccg instead for this)
+# With Antigravity CLI workers (requires: install per https://antigravity.google)
+/team 2:antigravity "redesign the UI components"
+# Mixed: Codex for backend analysis, Gemini/Antigravity for frontend (use /ccg instead for this)
 ```
 
 ## Architecture
@@ -50,45 +52,40 @@ User: "/team 3:executor fix all TypeScript errors"
               v
       [TEAM ORCHESTRATOR (Lead)]
               |
-              +-- TeamCreate("fix-ts-errors")
-              |       -> lead becomes team-lead@fix-ts-errors
+              +-- Use the session's implicit Claude Code team
+              |       -> no TeamCreate call; lead remains current session
               |
               +-- Analyze & decompose task into subtasks
               |       -> explore/architect produces subtask list
               |
-              +-- TaskCreate x N (one per subtask)
-              |       -> tasks #1, #2, #3 with dependencies
+              +-- Create task list entries from the implementation plan
+              |       -> TODO/task entries #1, #2, #3 with dependencies
               |
-              +-- TaskUpdate x N (pre-assign owners)
+              +-- Update task-list entries (pre-assign owners)
               |       -> task #1 owner=worker-1, etc.
               |
-              +-- Task(team_name="fix-ts-errors", name="worker-1") x 3
+              +-- Task(name="worker-1") x 3
               |       -> spawns teammates into the team
               |
               +-- Monitor loop
-              |       <- SendMessage from teammates (auto-delivered)
-              |       -> TaskList polling for progress
-              |       -> SendMessage to unblock/coordinate
+              |       <- teammate messages (auto-delivered by the active team surface)
+              |       -> task-list/TodoWrite review for progress
+              |       -> message teammates through the active team surface to unblock/coordinate
               |
               +-- Completion
-                      -> SendMessage(shutdown_request) to each teammate
-                      <- SendMessage(shutdown_response, approve: true)
-                      -> TeamDelete("fix-ts-errors")
+                      -> request shutdown from each teammate through the active team surface
+                      <- shutdown acknowledgement from teammates
+                      -> clear OMC team state (no TeamDelete call)
                       -> rm .omc/state/team-state.json
 ```
 
-**Storage layout (managed by Claude Code):**
+**Native Claude Code team model (2.1.178+):**
 
 ```
-~/.claude/
-  teams/fix-ts-errors/
-    config.json          # Team metadata + members array
-  tasks/fix-ts-errors/
-    .lock                # File lock for concurrent access
-    1.json               # Subtask #1
-    2.json               # Subtask #2 (may be internal)
-    3.json               # Subtask #3
-    ...
+- No per-team ~/.claude/teams/<name>/ directory is created by this skill.
+- No TeamCreate/TeamDelete calls are available.
+- `team_name` is accepted by native Claude Code only as ignored legacy metadata; do not rely on it for routing.
+- Spawn teammates directly via Agent/Task with `name="worker-N"`.
 ```
 
 ## Goal Workflow Relationship
@@ -131,7 +128,7 @@ Each pipeline stage uses **specialized agents** -- not just executors. The lead
   - Agents: `analyst` extracts requirements, optionally `critic`.
   - Exit: acceptance criteria and boundaries are explicit.
 - **team-exec**
-  - Entry: `TeamCreate`, `TaskCreate`, assignment, and worker spawn are complete.
+  - Entry: task list assignment and worker spawn are complete.
   - Agents: workers spawned as the appropriate specialist type per subtask (see routing table).
   - Exit: execution tasks reach terminal state for the current pass.
 - **team-verify**
@@ -177,7 +174,7 @@ The lead writes handoffs to `.omc/handoffs/<stage-name>.md`.
 
 1. **Lead reads previous handoff BEFORE spawning next stage's agents.** The handoff content is included in the next stage's agent spawn prompts, ensuring agents start with full context.
 2. **Handoffs accumulate.** The verify stage can read all prior handoffs (plan → prd → exec) for full decision history.
-3. **On team cancellation, handoffs survive** in `.omc/handoffs/` for session resume. They are not deleted by `TeamDelete`.
+3. **On team cancellation, handoffs survive** in `.omc/handoffs/` for session resume. They are not deleted by native Claude Code team cleanup; no `TeamDelete` call exists in Claude Code 2.1.178+.
 4. **Handoffs are lightweight.** 10-20 lines max. They capture decisions and rationale, not full specifications (those live in deliverable files like DESIGN.md).
 
 #### Example
@@ -226,28 +223,11 @@ Use `explore` or `architect` (via MCP or agent) to analyze the codebase and brea
 - Each subtask needs a concise `subject` and detailed `description`
 - Identify dependencies between subtasks (e.g., "shared types must be fixed before consumers")
 
-### Phase 3: Create Team
+### Phase 3: Initialize Team State
 
-Call `TeamCreate` with a slug derived from the task:
+Use the session's implicit Claude Code team. Do **not** call `TeamCreate`; Claude Code 2.1.178+ removed that tool and automatically gives the session one implicit team when `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is enabled.
 
-```json
-{
-  "team_name": "fix-ts-errors",
-  "description": "Fix all TypeScript errors across the project"
-}
-```
-
-**Response:**
-
-```json
-{
-  "team_name": "fix-ts-errors",
-  "team_file_path": "~/.claude/teams/fix-ts-errors/config.json",
-  "lead_agent_id": "team-lead@fix-ts-errors"
-}
-```
-
-The current session becomes the team lead (`team-lead@fix-ts-errors`).
+Derive a slug such as `fix-ts-errors` for OMC state, prompt labels, handoffs, and human-readable reporting only. Native Claude Code may accept `team_name` as legacy metadata, but it is ignored for routing.
 
 Write OMC state using the `state_write` MCP tool for proper session-scoped persistence:
 
@@ -272,7 +252,7 @@ state_write(mode="team", active=true, current_phase="team-plan", state={
 | ---------------- | ------- | --------------------------------------------------------------------------------------- |
 | `active`         | boolean | Whether team mode is active                                                             |
 | `current_phase`  | string  | Current pipeline stage: `team-plan`, `team-prd`, `team-exec`, `team-verify`, `team-fix` |
-| `team_name`      | string  | Slug name for the team                                                                  |
+| `team_name`      | string  | OMC slug for state, handoffs, and reporting; ignored by native Claude Code routing |
 | `agent_count`    | number  | Number of worker agents                                                                 |
 | `agent_types`    | string  | Comma-separated agent types used in team-exec                                           |
 | `task`           | string  | Original task description                                                               |
@@ -299,10 +279,10 @@ If `active=true` and `current_phase` is non-terminal, resume from the last incom
 
 ### Phase 4: Create Tasks
 
-Call `TaskCreate` for each subtask. Set dependencies with `TaskUpdate` using `addBlockedBy`.
+Create task list entries for each subtask using TodoWrite or the active task-list surface. Task-list tools are for tracking only; they do not create native teams.
 
 ```json
-// TaskCreate for subtask 1
+// Task-list entry for subtask 1
 {
   "subject": "Fix type errors in src/auth/",
   "description": "Fix all TypeScript errors in src/auth/login.ts, src/auth/session.ts, and src/auth/types.ts. Run tsc --noEmit to verify.",
@@ -325,7 +305,7 @@ Call `TaskCreate` for each subtask. Set dependencies with `TaskUpdate` using `ad
 }
 ```
 
-For tasks with dependencies, use `TaskUpdate` after creation:
+For tasks with dependencies, update the active task-list entries after creation:
 
 ```json
 // Task #3 depends on task #1 (shared types must be fixed first)
@@ -347,12 +327,11 @@ For tasks with dependencies, use `TaskUpdate` after creation:
 
 ### Phase 5: Spawn Teammates
 
-Spawn N teammates using `Task` with `team_name` and `name` parameters. Each teammate gets the team worker preamble (see below) plus their specific assignment.
+Spawn N teammates directly using the Agent/Task tool with distinct `name` values. Each teammate gets the team worker preamble (see below) plus their specific assignment. Do **not** call `TeamCreate`, and do **not** rely on `team_name`; Claude Code 2.1.178+ ignores it for native routing.
 
 ```json
 {
   "subagent_type": "oh-my-claudecode:executor",
-  "team_name": "fix-ts-errors",
   "name": "worker-1",
   "prompt": "<worker-preamble + assigned tasks>"
 }
@@ -362,17 +341,16 @@ Spawn N teammates using `Task` with `team_name` and `name` parameters. Each team
 
 ```json
 {
-  "agent_id": "worker-1@fix-ts-errors",
-  "name": "worker-1",
-  "team_name": "fix-ts-errors"
+  "agent_id": "worker-1",
+  "name": "worker-1"
 }
 ```
 
 **Side effects:**
 
-- Teammate added to `config.json` members array
+- Teammate is spawned into the session's implicit Claude Code team
 - An **internal task** is auto-created (with `metadata._internal: true`) tracking the agent lifecycle
-- Internal tasks appear in `TaskList` output -- filter them when counting real tasks
+- Internal tasks may appear in task-list output -- filter them when counting real tasks
 
 **IMPORTANT:** Spawn all teammates in parallel (they are background agents). Do NOT wait for one to finish before spawning the next.
 
@@ -380,9 +358,9 @@ Spawn N teammates using `Task` with `team_name` and `name` parameters. Each team
 
 The lead orchestrator monitors progress through two channels:
 
-1. **Inbound messages** -- Teammates send `SendMessage` to `team-lead` when they complete tasks or need help. These arrive automatically as new conversation turns (no polling needed).
+1. **Inbound messages** -- Teammates message `team-lead` when they complete tasks or need help. These arrive through the active team/conversation surface.
 
-2. **TaskList polling** -- Periodically call `TaskList` to check overall progress:
+2. **Task-list polling/review** -- Periodically check TodoWrite or the active task-list surface for overall progress:
    ```
    #1 [completed] Fix type errors in src/auth/ (worker-1)
    #3 [in_progress] Fix type errors in src/api/ (worker-2)
@@ -392,8 +370,8 @@ The lead orchestrator monitors progress through two channels:
 
 **Coordination actions the lead can take:**
 
-- **Unblock a teammate:** Send a `message` with guidance or missing context
-- **Reassign work:** If a teammate finishes early, use `TaskUpdate` to assign pending tasks to them and notify via `SendMessage`
+- **Unblock a teammate:** Send a message with guidance or missing context through the active team surface
+- **Reassign work:** If a teammate finishes early, update the task-list entry to assign pending work to them and notify through the active team surface
 - **Handle failures:** If a teammate reports failure, reassign the task or spawn a replacement
 
 #### Task Watchdog Policy
@@ -433,8 +411,8 @@ This enables:
 
 When all real tasks (non-internal) are completed or failed:
 
-1. **Verify results** -- Check that all subtasks are marked `completed` via `TaskList`
-2. **Shutdown teammates** -- Send `shutdown_request` to each active teammate:
+1. **Verify results** -- Check that all real tasks (non-internal) are marked `completed` in TodoWrite or the active task-list surface
+2. **Shutdown teammates** -- Send `shutdown_request` to each active teammate through the active team surface:
    ```json
    {
      "type": "shutdown_request",
@@ -443,18 +421,7 @@ When all real tasks (non-internal) are completed or failed:
    }
    ```
 3. **Await responses** -- Each teammate responds with `shutdown_response(approve: true)` and terminates
-4. **Delete team** -- Call `TeamDelete` to clean up:
-   ```json
-   { "team_name": "fix-ts-errors" }
-   ```
-   Response:
-   ```json
-   {
-     "success": true,
-     "message": "Cleaned up directories and worktrees for team \"fix-ts-errors\"",
-     "team_name": "fix-ts-errors"
-   }
-   ```
+4. **Clean up native team state** -- Claude Code 2.1.178+ has no `TeamDelete`; after teammates acknowledge shutdown, clear OMC state and any local task bookkeeping.
 5. **Clean OMC state** -- Remove `.omc/state/team-state.json`
 6. **Report summary** -- Present results to the user
 
@@ -463,15 +430,15 @@ When all real tasks (non-internal) are completed or failed:
 When spawning teammates, include this preamble in the prompt to establish the work protocol. Adapt it per teammate with their specific task assignments.
 
 ```
-You are a TEAM WORKER in team "{team_name}". Your name is "{worker_name}".
+You are a TEAM WORKER in OMC team "{team_name}". Your name is "{worker_name}".
 You report to the team lead ("team-lead").
 You are not the leader and must not perform leader orchestration actions.
 
 == WORK PROTOCOL ==
 
-1. CLAIM: Call TaskList to see your assigned tasks (owner = "{worker_name}").
+1. CLAIM: Check TodoWrite or the active task-list surface for tasks assigned to you (owner = "{worker_name}").
    Pick the first task with status "pending" that is assigned to you.
-   Call TaskUpdate to set status "in_progress":
+   Mark it `in_progress` using the active task-list surface:
    {"taskId": "ID", "status": "in_progress", "owner": "{worker_name}"}
 
 2. WORK: Execute the task using your tools (Read, Write, Edit, Bash).
@@ -480,11 +447,11 @@ You are not the leader and must not perform leader orchestration actions.
 3. COMPLETE: When done, mark the task completed:
    {"taskId": "ID", "status": "completed"}
 
-4. REPORT: Notify the lead via SendMessage:
+4. REPORT: Notify the lead through the active team/conversation surface:
    {"type": "message", "recipient": "team-lead", "content": "Completed task #ID: <summary of what was done>", "summary": "Task #ID complete"}
 
-5. NEXT: Check TaskList for more assigned tasks. If you have more pending tasks, go to step 1.
-   If no more tasks are assigned to you, notify the lead:
+5. NEXT: Check TodoWrite or the active task-list surface for more assigned tasks. If you have more pending tasks, go to step 1.
+   If no more tasks are assigned to you, notify the lead through the active team/conversation surface:
    {"type": "message", "recipient": "team-lead", "content": "All assigned tasks complete. Standing by.", "summary": "All tasks done, standing by"}
 
 6. SHUTDOWN: When you receive a shutdown_request, respond with:
@@ -492,7 +459,7 @@ You are not the leader and must not perform leader orchestration actions.
 
 == BLOCKED TASKS ==
 If a task has blockedBy dependencies, skip it until those tasks are completed.
-Check TaskList periodically to see if blockers have been resolved.
+Check TodoWrite or the active task-list surface periodically to see if blockers have been resolved.
 
 == ERRORS ==
 If you cannot complete a task, report the failure to the lead:
@@ -504,17 +471,18 @@ Do NOT mark the task as completed. Leave it in_progress so the lead can reassign
 - NEVER run tmux pane/session orchestration commands (for example `tmux split-window`, `tmux new-session`)
 - NEVER run team spawning/orchestration skills or commands (for example `$team`, `$ultrawork`, `$autopilot`, `$ralph`, `omc team ...`, `omx team ...`)
 - ALWAYS use absolute file paths
-- ALWAYS report progress via SendMessage to "team-lead"
-- Use SendMessage with type "message" only -- never "broadcast"
+- ALWAYS report progress to "team-lead" through the active team/conversation surface
+- Use direct team/conversation messages with type "message" only -- never "broadcast"
 ```
 
 ### Agent-Type Prompt Injection (Worker-Specific Addendum)
 
 When composing teammate prompts, append a short addendum based on worker type:
 
-- `claude_worker`: Emphasize strict TaskList/TaskUpdate/SendMessage loop and no orchestration commands.
+- `claude_worker`: Emphasize strict TodoWrite/task-list updates, active team/conversation messages, and no orchestration commands.
 - `codex_worker`: Emphasize CLI API lifecycle (`omc team api ... --json`) and explicit failure ACKs with stderr.
 - `gemini_worker`: Emphasize bounded file ownership and milestone ACKs after each completed sub-step.
+- `antigravity_worker`: Same expectations as `gemini_worker`; emphasize bounded file ownership and milestone ACKs after each completed sub-step.
 
 This addendum must preserve the core rule: **worker = executor only, never leader/orchestrator**.
 
@@ -554,12 +522,12 @@ This addendum must preserve the core rule: **worker = executor only, never leade
 
 ### Shutdown Protocol (BLOCKING)
 
-**CRITICAL: Steps must execute in exact order. Never call TeamDelete before shutdown is confirmed.**
+**CRITICAL: Steps must execute in exact order. Never clear OMC team state before shutdown is confirmed or timed out.**
 
 **Step 1: Verify completion**
 
 ```
-Call TaskList — verify all real tasks (non-internal) are completed or failed.
+Verify via TodoWrite or the active task-list surface — all real tasks (non-internal) are completed or failed.
 ```
 
 **Step 2: Request shutdown from each teammate**
@@ -590,29 +558,23 @@ Call TaskList — verify all real tasks (non-internal) are completed or failed.
 }
 ```
 
-After approval:
-
-- Teammate process terminates
-- Teammate auto-removed from `config.json` members array
-- Internal task for that teammate completes
+After approval, the teammate terminates or stops accepting new work. Claude Code 2.1.178+ does not expose per-team config membership or TeamDelete cleanup; track acknowledgements in OMC state/reporting instead.
 
-**Step 4: TeamDelete — only after ALL teammates confirmed or timed out**
+**Step 4: Clear OMC team state — only after ALL teammates confirmed or timed out**
 
-```json
-{ "team_name": "fix-ts-errors" }
-```
+Claude Code 2.1.178+ has no `TeamDelete`. Clear OMC team state and local task bookkeeping after the blocking shutdown pass completes.
 
-**Step 5: Orphan scan**
+**Step 5: Orphan scan for OMC tmux/CLI workers only**
 
-Check for agent processes that survived TeamDelete:
+For legacy OMC tmux/CLI worker runs (`omc team` / `/omc-teams`), check for worker processes that survived cleanup:
 
 ```bash
 node "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-orphans.mjs" --team-name fix-ts-errors
 ```
 
-This scans for processes matching the team name whose config no longer exists, and terminates them (SIGTERM → 5s wait → SIGKILL). Supports `--dry-run` for inspection.
+This scans for OMC worker processes matching the team name and terminates stale orphans (SIGTERM → 5s wait → SIGKILL). Supports `--dry-run` for inspection.
 
-**Shutdown sequence is BLOCKING:** Do not proceed to TeamDelete until all teammates have either:
+**Shutdown sequence is BLOCKING:** Do not clear OMC team state until all teammates have either:
 
 - Confirmed shutdown (`shutdown_response` with `approve: true`), OR
 - Timed out (30s with no response)
@@ -631,7 +593,8 @@ Tasks are tagged with an execution mode during decomposition:
 | --------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `claude_worker` | Claude agent           | Full Claude Code tool access (Read/Write/Edit/Bash/Task). Best for tasks needing Claude's reasoning + iterative tool use.                                                                  |
 | `codex_worker`  | Codex CLI (tmux pane)  | Full filesystem access in working_directory. Runs autonomously via tmux pane. Best for code review, security analysis, refactoring, architecture. Requires `npm install -g @openai/codex`. |
-| `gemini_worker` | Gemini CLI (tmux pane) | Full filesystem access in working_directory. Runs autonomously via tmux pane. Best for UI/design work, documentation, large-context tasks. Requires `npm install -g @google/gemini-cli`.   |
+| `gemini_worker`      | Gemini CLI (tmux pane)      | Full filesystem access in working_directory. Runs autonomously via tmux pane. Best for UI/design work, documentation, large-context tasks. Requires `npm install -g @google/gemini-cli` (enterprise/API-key tier). |
+| `antigravity_worker` | Antigravity CLI (tmux pane) | Full filesystem access in working_directory. Runs autonomously via tmux pane. Same strengths as gemini_worker; Google's successor to the Gemini CLI. Install per the [official instructions](https://antigravity.google) (`agy` binary). |
 
 ### How CLI Workers Operate
 
@@ -646,7 +609,7 @@ Tmux CLI workers run in dedicated tmux panes with filesystem access. They are **
 **Key difference from Claude teammates:**
 
 - CLI workers operate via tmux, not Claude Code's tool system
-- They cannot use TaskList/TaskUpdate/SendMessage (no team awareness)
+- They cannot use Claude Code's native task-list or team messaging surfaces
 - They run as one-shot autonomous jobs, not persistent teammates
 - The lead manages their lifecycle (spawn, monitor, collect results)
 
@@ -661,7 +624,7 @@ Tmux CLI workers run in dedicated tmux panes with filesystem access. They are **
 | UI/frontend implementation       | designer Claude agent          | Design expertise, framework idioms                  |
 | Large-scale documentation        | writer Claude agent            | Writing expertise + large context for consistency   |
 | Build/test iteration loops       | Claude teammate                | Needs Bash tool + iterative fix cycles              |
-| Tasks needing team coordination  | Claude teammate                | Needs SendMessage for status updates                |
+| Tasks needing team coordination  | Claude teammate                | Needs team/conversation status updates              |
 
 ### Example: Hybrid Team with CLI Workers
 
@@ -690,7 +653,7 @@ This is especially useful when the task scope is unclear and benefits from exter
 
 ## Monitor Enhancement: Outbox Auto-Ingestion
 
-The lead can proactively ingest outbox messages from CLI workers using the outbox reader utilities, enabling event-driven monitoring without relying solely on `SendMessage` delivery.
+The lead can proactively ingest outbox messages from CLI workers using the outbox reader utilities, enabling event-driven monitoring alongside native team/conversation delivery.
 
 ### Outbox Reader Functions
 
@@ -746,37 +709,36 @@ if (status.taskSummary.pending === 0 && status.taskSummary.inProgress === 0) {
 | `shutdown_ack`  | Worker acknowledged shutdown -- safe to remove from team                                    |
 | `heartbeat`     | Update liveness tracking (redundant with heartbeat files but useful for latency monitoring) |
 
-This approach complements the existing `SendMessage`-based communication by providing a pull-based mechanism for MCP workers that cannot use Claude Code's team messaging tools.
+This approach complements native team/conversation messaging by providing a pull-based mechanism for MCP workers that cannot use Claude Code's team messaging tools.
 
 ## Error Handling
 
 ### Teammate Fails a Task
 
-1. Teammate sends `SendMessage` to lead reporting the failure
+1. Teammate reports the failure to the lead through the active team/conversation surface
 2. Lead decides: retry (reassign same task to same or different worker) or skip
-3. To reassign: `TaskUpdate` to set new owner, then `SendMessage` to the new owner
+3. To reassign: update the active task-list entry with the new owner, then message the new owner through the active team surface
 
 ### Teammate Gets Stuck (No Messages)
 
-1. Lead detects via `TaskList` -- task stuck in `in_progress` for too long
-2. Lead sends `SendMessage` to the teammate asking for status
+1. Lead detects via TodoWrite or the active task-list surface -- task stuck in `in_progress` for too long
+2. Lead messages the teammate asking for status through the active team surface
 3. If no response, consider the teammate dead
-4. Reassign the task to another worker via `TaskUpdate`
+4. Reassign the task to another worker through the active task-list surface
 
 ### Dependency Blocked
 
 1. If a blocking task fails, the lead must decide whether to:
    - Retry the blocker
-   - Remove the dependency (`TaskUpdate` with modified blockedBy)
+   - Remove the dependency by updating the active task-list entry's `blockedBy` metadata
    - Skip the blocked task entirely
-2. Communicate decisions to affected teammates via `SendMessage`
+2. Communicate decisions to affected teammates through the active team surface
 
 ### Teammate Crashes
 
-1. Internal task for that teammate will show unexpected status
-2. Teammate disappears from `config.json` members
-3. Lead reassigns orphaned tasks to remaining workers
-4. If needed, spawn a replacement teammate with `Task(team_name, name)`
+1. Internal tracking for that teammate will show unexpected status
+2. Lead reassigns orphaned tasks to remaining workers
+3. If needed, spawn a replacement teammate with `Task(name="worker-N", subagent_type="...")`
 
 ## Team + Ralph Composition
 
@@ -833,46 +795,44 @@ See Cancellation section below for details.
 
 ## Idempotent Recovery
 
-If the lead crashes mid-run, the team skill should detect existing state and resume:
+If the lead crashes mid-run, the team skill should detect existing OMC state and resume:
 
-1. Check `${CLAUDE_CONFIG_DIR:-~/.claude}/teams/` for teams matching the task slug
-2. If found, read `config.json` to discover active members
-3. Resume monitor mode instead of creating a duplicate team
-4. Call `TaskList` to determine current progress
-5. Continue from the monitoring phase
+1. Read `state_read(mode="team")` for the active OMC team slug, phase, and worker labels
+2. Use OMC handoffs and task-list/TodoWrite state to determine current progress
+3. Resume monitor mode instead of spawning duplicate teammates
+4. Continue from the last recorded stage
 
-This prevents duplicate teams and allows graceful recovery from lead failures.
+This prevents duplicate worker spawns and allows graceful recovery from lead failures.
 
 ## Comparison: Team vs Legacy Swarm
 
-| Aspect                  | Team (Native)                                                      | Swarm (Legacy SQLite)                  |
-| ----------------------- | ------------------------------------------------------------------ | -------------------------------------- |
-| **Storage**             | JSON files in `~/.claude/teams/` and `~/.claude/tasks/`            | SQLite in `.omc/state/swarm.db`        |
-| **Dependencies**        | `better-sqlite3` not needed                                        | Requires `better-sqlite3` npm package  |
-| **Task claiming**       | `TaskUpdate(owner + in_progress)` -- lead pre-assigns              | SQLite IMMEDIATE transaction -- atomic |
+| Aspect                  | Team (Native Claude Code 2.1.178+)                              | Swarm (Legacy SQLite)                  |
+| ----------------------- | ---------------------------------------------------------------- | -------------------------------------- |
+| **Storage**             | OMC state/handoffs plus Claude Code's current task-list surface   | SQLite in `.omc/state/swarm.db`        |
+| **Dependencies**        | `better-sqlite3` not needed                                      | Requires `better-sqlite3` npm package  |
+| **Task claiming**       | Lead pre-assigns named workers through task-list/TodoWrite state  | SQLite IMMEDIATE transaction -- atomic |
 | **Race conditions**     | Possible if two agents claim same task (mitigate by pre-assigning) | None (SQLite transactions)             |
-| **Communication**       | `SendMessage` (DM, broadcast, shutdown)                            | None (fire-and-forget agents)          |
-| **Task dependencies**   | Built-in `blocks` / `blockedBy` arrays                             | Not supported                          |
-| **Heartbeat**           | Automatic idle notifications from Claude Code                      | Manual heartbeat table + polling       |
-| **Shutdown**            | Graceful request/response protocol                                 | Signal-based termination               |
-| **Agent lifecycle**     | Auto-tracked via internal tasks + config members                   | Manual tracking via heartbeat table    |
-| **Progress visibility** | `TaskList` shows live status with owner                            | SQL queries on tasks table             |
-| **Conflict prevention** | Owner field (lead-assigned)                                        | Lease-based claiming with timeout      |
-| **Crash recovery**      | Lead detects via missing messages, reassigns                       | Auto-release after 5-min lease timeout |
-| **State cleanup**       | `TeamDelete` removes everything                                    | Manual `rm` of SQLite database         |
-
-**When to use Team over Swarm:** Always prefer `/team` for new work. It uses Claude Code's built-in infrastructure, requires no external dependencies, supports inter-agent communication, and has task dependency management.
+| **Communication**       | Native implicit-team messages / conversation turns                | None (fire-and-forget agents)          |
+| **Task dependencies**   | Lead-managed dependencies in task-list/TodoWrite state            | Not supported                          |
+| **Heartbeat**           | Lead detects via missing messages/status                          | Manual heartbeat table + polling       |
+| **Shutdown**            | Graceful request/response protocol plus OMC state clear           | Signal-based termination               |
+| **Agent lifecycle**     | Tracked by named Agent/Task spawns and OMC state                  | Manual tracking via heartbeat table    |
+| **Progress visibility** | Task list/TodoWrite state with named worker ownership             | SQL queries on tasks table             |
+| **Conflict prevention** | Owner labels (lead-assigned)                                      | Lease-based claiming with timeout      |
+| **Crash recovery**      | Lead detects via missing messages, reassigns                      | Auto-release after 5-min lease timeout |
+| **State cleanup**       | Clear OMC team state after teammate shutdown                      | Manual `rm` of SQLite database         |
+
+**When to use Team over Swarm:** Always prefer `/team` for new native Claude Code work. It uses Claude Code's implicit agent team, requires no external dependencies, supports inter-agent coordination, and has task dependency management.
 
 ## Cancellation
 
 The `/oh-my-claudecode:cancel` skill handles team cleanup:
 
 1. Read team state via `state_read(mode="team")` to get `team_name` and `linked_ralph`
-2. Send `shutdown_request` to all active teammates (from `config.json` members)
+2. Request shutdown from all active named teammates through the active team surface
 3. Wait for `shutdown_response` from each (15s timeout per member)
-4. Call `TeamDelete` to remove team and task directories
-5. Clear state via `state_clear(mode="team")`
-6. If `linked_ralph` is true, also clear ralph: `state_clear(mode="ralph")`
+4. Clear state via `state_clear(mode="team")`
+5. If `linked_ralph` is true, also clear ralph: `state_clear(mode="ralph")`
 
 ### Linked Mode Cancellation (Team + Ralph)
 
@@ -882,7 +842,7 @@ When team is linked to ralph, cancellation follows dependency order:
 - **Cancel triggered from Team context:** Clear Team state, then mark Ralph as cancelled. Ralph's stop hook will detect the missing team and stop iterating.
 - **Force cancel (`--force`):** Clears both `team` and `ralph` state unconditionally via `state_clear`.
 
-If teammates are unresponsive, `TeamDelete` may fail. In that case, the cancel skill should wait briefly and retry, or inform the user to manually clean up `~/.claude/teams/{team_name}/` and `~/.claude/tasks/{team_name}/`.
+If teammates are unresponsive, record the timeout, avoid spawning more work, and clear OMC state only after the shutdown wait completes or the user force-cancels.
 
 ## Runtime V2 (Event-Driven)
 
@@ -923,8 +883,8 @@ Optional settings live in `.claude/omc.jsonc` (project) or `~/.config/claude-omc
 ```
 
 - **ops.maxAgents** - Maximum teammates (default: 20)
-- **ops.defaultAgentType** - CLI provider when a `/team` invocation does not specify one (`claude` | `codex` | `gemini`, default: `claude`)
-- **ops.monitorIntervalMs** - How often to poll `TaskList` (default: 30s)
+- **ops.defaultAgentType** - CLI provider when a `/team` invocation does not specify one (`claude` | `codex` | `gemini` | `antigravity` | `grok` | `cursor`, default: `claude`)
+- **ops.monitorIntervalMs** - How often to review TodoWrite or the active task-list surface (default: 30s)
 - **ops.shutdownTimeoutMs** - How long to wait for shutdown responses (default: 15s)
 
 > **Note:** Team members do not have a hardcoded model default. Each teammate is a separate Claude Code session that inherits the user's configured model. Since teammates can spawn their own subagents, the session model acts as the orchestration layer while subagents can use any model tier.
@@ -933,7 +893,7 @@ Optional settings live in `.claude/omc.jsonc` (project) or `~/.config/claude-omc
 
 > **Scope:** Applies to `/team` only. Task-based delegation uses `delegationRouting` (see separate docs). The two systems coexist by design.
 
-Declare which provider (`claude`, `codex`, `gemini`) and which model tier should back each canonical role. Routing is resolved **once** at team creation and persisted in `TeamConfig.resolved_routing` — spawn, scale-up, and restart all read from the snapshot, so a role's worker CLI and model are stable for the lifetime of the team.
+Declare which provider (`claude`, `codex`, `gemini`, `antigravity`, `grok`, `cursor`) and which model tier should back each canonical role. Routing is resolved **once** at team creation and persisted in `TeamConfig.resolved_routing` — spawn, scale-up, and restart all read from the snapshot, so a role's worker CLI and model are stable for the lifetime of the team.
 
 ### Example — user target mapping
 
@@ -946,6 +906,7 @@ Declare which provider (`claude`, `codex`, `gemini`) and which model tier should
       "planner": { "provider": "claude", "model": "HIGH" },
       "analyst": { "provider": "claude", "model": "HIGH" },
       "executor": { "provider": "claude", "model": "MEDIUM" },
+      "debugger": { "provider": "cursor" },
       "critic": { "provider": "codex" },
       "code-reviewer": { "provider": "gemini" },
       "test-engineer": { "provider": "gemini", "model": "MEDIUM" },
@@ -960,9 +921,10 @@ Declare which provider (`claude`, `codex`, `gemini`) and which model tier should
 | `planner`       | claude          | `HIGH` (opus)             |
 | `analyst`       | claude          | `HIGH` (opus)             |
 | `executor`      | claude          | `MEDIUM` (sonnet)         |
+| `debugger`      | cursor          | cursor-agent default      |
 | `critic`        | codex           | codex default             |
 | `code-reviewer` | gemini          | gemini default            |
-| `test-engineer` | gemini          | `MEDIUM` (sonnet)         |
+| `test-engineer` | antigravity     | antigravity default       |
 
 ### Canonical roles
 
@@ -972,12 +934,14 @@ User-friendly aliases normalize via `normalizeDelegationRole()` — e.g. `review
 
 ### Spec fields (`TeamRoleAssignmentSpec`)
 
-- **provider** — `"claude" | "codex" | "gemini"`. Omitted → defaults to `claude`.
+- **provider** — `"claude" | "codex" | "gemini" | "antigravity" | "grok" | "cursor"`. Omitted → defaults to `claude`.
 - **model** — tier name (`"HIGH" | "MEDIUM" | "LOW"`) or an explicit model ID. Tiers resolve through `routing.tierModels`.
 - **agent** — optional Claude agent name (e.g. `"critic"`, `"executor"`). Only honored when the resolved provider is `claude`.
 
 `orchestrator` is pinned to `claude`; only `model` is user-configurable. Any other key on `orchestrator` is rejected by the validator.
 
+`cursor` launches `cursor-agent` as an interactive executor/refactor worker. Do not route reviewer/verdict roles (`critic`, `code-reviewer`, `security-reviewer`, `test-engineer`) to Cursor unless its CLI gains a compatible verdict-output mode; the runtime intentionally skips the structured verdict contract for Cursor panes.
+
 ### Env override
 
 ```bash
@@ -988,7 +952,7 @@ Precedence: `OMC_TEAM_ROLE_OVERRIDES` > `.claude/omc.jsonc` (project) > `~/.conf
 
 ### Fallback when a CLI is missing
 
-If the CLI for a configured provider is absent from `PATH` at spawn time, `buildLaunchArgs()` throws, the team lead emits a visible `SendMessage` warning, and the runtime falls back to a deterministic Claude assignment pre-computed by `buildResolvedRoutingSnapshot` (same tier + same agent, `provider: "claude"`). Fallback is loud by design — silent fallback is a test failure. Probe provider availability with `omc doctor --team-routing`.
+If the CLI for a configured provider is absent from `PATH` at spawn time, `buildLaunchArgs()` throws, the team lead emits a visible team/conversation warning, and the runtime falls back to a deterministic Claude assignment pre-computed by `buildResolvedRoutingSnapshot` (same tier + same agent, `provider: "claude"`). Fallback is loud by design — silent fallback is a test failure. Probe provider availability with `omc doctor --team-routing`.
 
 ### Stickiness — resolved once, reused everywhere
 
@@ -1002,10 +966,7 @@ An empty `team.roleRouting` preserves pre-patch behavior: every worker is Claude
 
 On successful completion:
 
-1. `TeamDelete` handles all Claude Code state:
-   - Removes `~/.claude/teams/{team_name}/` (config)
-   - Removes `~/.claude/tasks/{team_name}/` (all task files + lock)
-2. OMC state cleanup via MCP tools:
+1. Native Claude Code 2.1.178+ has no per-team `TeamDelete` cleanup. After shutdown is confirmed or timed out, clear OMC state via MCP tools:
    ```
    state_clear(mode="team")
    ```
@@ -1013,9 +974,10 @@ On successful completion:
    ```
    state_clear(mode="ralph")
    ```
-3. Or run `/oh-my-claudecode:cancel` which handles all cleanup automatically.
+2. For legacy OMC tmux/CLI workers, run the documented `omc team shutdown` / cleanup path.
+3. Or run `/oh-my-claudecode:cancel` which handles OMC state cleanup automatically.
 
-**IMPORTANT:** Call `TeamDelete` only AFTER all teammates have been shut down. `TeamDelete` will fail if active members (besides the lead) still exist in the config.
+**IMPORTANT:** Clear OMC team state only AFTER all teammates have been shut down or timed out.
 
 ## Git Worktree Integration
 
@@ -1052,19 +1014,19 @@ MCP workers can operate in isolated git worktrees to prevent file conflicts betw
 
 ## Gotchas
 
-1. **Internal tasks pollute TaskList** -- When a teammate is spawned, the system auto-creates an internal task with `metadata._internal: true`. These appear in `TaskList` output. Filter them when counting real task progress. The subject of an internal task is the teammate's name.
+1. **Internal/lifecycle task entries may pollute task-list output** -- If Claude Code reports internal lifecycle entries for spawned teammates, filter them when counting real task progress. The subject of an internal task is often the teammate's name.
 
-2. **No atomic claiming** -- Unlike SQLite swarm, there is no transactional guarantee on `TaskUpdate`. Two teammates could race to claim the same task. **Mitigation:** The lead should pre-assign owners via `TaskUpdate(taskId, owner)` before spawning teammates. Teammates should only work on tasks assigned to them.
+2. **No atomic claiming** -- Unlike SQLite swarm, native task-list/TodoWrite state does not provide transactional claiming. Two teammates could race to claim the same task. **Mitigation:** The lead should pre-assign owners before spawning teammates. Teammates should only work on tasks assigned to them.
 
-3. **Task IDs are strings** -- IDs are auto-incrementing strings ("1", "2", "3"), not integers. Always pass string values to `taskId` fields.
+3. **Task IDs are strings when exposed by task-list tools** -- IDs may be auto-incrementing strings ("1", "2", "3"), not integers. Always pass string values to `taskId` fields when using task-list tools.
 
-4. **TeamDelete requires empty team** -- All teammates must be shut down before calling `TeamDelete`. The lead (the only remaining member) is excluded from this check.
+4. **No TeamDelete cleanup** -- Claude Code 2.1.178+ removed `TeamDelete`; use shutdown messages plus OMC state cleanup.
 
 5. **Messages are auto-delivered** -- Teammate messages arrive to the lead as new conversation turns. No polling or inbox-checking is needed for inbound messages. However, if the lead is mid-turn (processing), messages queue and deliver when the turn ends.
 
-6. **Teammate prompt stored in config** -- The full prompt text is stored in `config.json` members array. Do not put secrets or sensitive data in teammate prompts.
+6. **Do not put secrets in teammate prompts** -- Prompts can be retained in logs, state, or conversation history. Keep credentials and sensitive data out of teammate prompts.
 
-7. **Members auto-removed on shutdown** -- After a teammate approves shutdown and terminates, it is automatically removed from `config.json`. Do not re-read config expecting to find shut-down teammates.
+7. **Shutdown acknowledgements are state/reporting events** -- After a teammate approves shutdown and terminates, track that acknowledgement in OMC state/reporting. Do not expect a Claude Code team membership config to update.
 
 8. **shutdown_response needs request_id** -- The teammate must extract the `request_id` from the incoming shutdown request JSON and pass it back. The format is `shutdown-{timestamp}@{worker-name}`. Fabricating this ID will cause the shutdown to fail silently.
 
@@ -1072,7 +1034,7 @@ MCP workers can operate in isolated git worktrees to prevent file conflicts betw
 
 10. **Broadcast is expensive** -- Each broadcast sends a separate message to every teammate. Use `message` (DM) by default. Only broadcast for truly team-wide critical alerts.
 
-11. **CLI workers are one-shot, not persistent** -- Tmux CLI workers have full filesystem access and CAN make code changes. However, they run as autonomous one-shot jobs -- they cannot use TaskList/TaskUpdate/SendMessage. The lead must manage their lifecycle: write prompt_file, spawn CLI worker, read output_file, mark task complete. They don't participate in team communication like Claude teammates do.
+11. **CLI workers are one-shot, not persistent** -- Tmux CLI workers have full filesystem access and CAN make code changes. However, they run as autonomous one-shot jobs -- they cannot use Claude Code's native task-list or team messaging surfaces. The lead must manage their lifecycle: write prompt_file, spawn CLI worker, read output_file, mark task complete. They don't participate in team communication like Claude teammates do.
 
 ## Parallel session caveats