--- name: team description: Split an approved plan into parallel tmux panes in the current window so the user can watch agents work. Prefer this visual flow by default; use `omp team` only when the user explicitly wants background execution or runtime messaging/status APIs. argument-hint: " " --- # Team — tmux-based parallel agent execution `/team` launches independent Copilot CLI agents in parallel tmux panes. **Default behavior:** use the **split-window** flow so the user sees agents working in the current tmux window. Use **runtime mode** (`omp team`) only when the user explicitly asks for background execution, detached monitoring, or runtime APIs like status, nudging, or worker messaging. Two modes available: | Mode | Command | Panes visible in | Best for | |------|---------|-------------------|----------| | **Split** | `team-launch.sh` | Current window | **Default**. Visual demo, watching agents work | | **Runtime** | `omp team N:copilot "task"` | Separate tmux session | Explicit background jobs, task tracking, nudging, messaging | When a Ralph, Ultrawork, or UltraQA loop is active, both modes automatically keep idle workers moving: a pane idle for at least 30 seconds receives the standard continuation prompt, with a hard maximum of three prompts for that pane launch. With no loop active, there is no automatic idle prompting. `team status` and `team collect` remain read-only. ## When to use - Work has **independent lanes** (no shared files, no ordering constraints) - You want parallel execution in split terminals ## Default mode — Split window (`team-launch.sh`) Use this unless the user asks for background execution. ### When to choose it - The user wants to **see** the agents working - You want panes in the **current tmux window** - You are demoing or smoke-testing the skill ### Step 1 — Write lanes JSON Write a temporary file at `/tmp/team-lanes-.json`: ```json [ { "id": "lane-a", "name": "Short name", "prompt": "Complete self-contained task prompt..." }, { "id": "lane-b", "name": "Another lane", "prompt": "Another task prompt..." } ] ``` Lane IDs and the `--session` value must use only letters, digits, dots, underscores, or hyphens; start each lane ID with a letter or digit. Use a fresh session name because the launcher creates a new private delivery directory and refuses to reuse an existing one. ### Step 2 — Launch Resolve the launcher (installed plugin if present, else a dev checkout) and run it with `--no-monitor`. That mode splits the panes, launches the agents, sends each lane's prompt, then returns (~20–30s) — it does NOT block on the long completion-monitor loop. Run it in the **foreground** (no `&`/`nohup`): a backgrounded launcher gets killed by your shell-tool cleanup before it sends the prompts, leaving the agents idle. For development or smoke tests, `OMP_TEAM_CONTROL_CLI` may name one absolute, executable `omp` path. Otherwise the launcher prefers the adjacent built CLI and only falls back to `omp` on `PATH` when its package version matches. A missing or mismatched control CLI warns but does not terminate already-launched worker panes. ```bash if [ -f ~/.copilot/installed-plugins/oh-my-copilot/oh-my-copilot/.github/skills/team/scripts/team-launch.sh ]; then bash ~/.copilot/installed-plugins/oh-my-copilot/oh-my-copilot/.github/skills/team/scripts/team-launch.sh \ --session "team-" --lanes --no-monitor else bash .github/skills/team/scripts/team-launch.sh \ --session "team-" --lanes --no-monitor fi ``` The script (with `--no-monitor`): 1. Splits the **current window** into panes 2. Launches `omp --madmax` in each 3. Auto-accepts folder trust prompts 4. Waits for readiness, sends each lane's prompt 5. Returns — the agents keep working in the panes for the user to watch (omit `--no-monitor` to instead block and print a completion summary) ### Step 3 — Collect (you drive the loop — do NOT go idle) Each worker was told to write its final result to a file; the launcher prints the exact collect command to use (it may contain an absolute CLI path). Completion is a real file write — not a guess from the live pane — so it's reliable. **You must actively poll** until every lane has delivered, then synthesize. Do not stop after launching and wait. Collection accepts only the launcher's validated manifest and regular, non-linked result files inside that delivery directory. Run the launcher’s printed command verbatim; its control CLI and delivery path are the same ones used to register the live panes. Returns `{ dir, total, doneCount, allDone, lanes: [{ id, name, status, output }] }` where `status` is `working` | `done` | `dead`. Procedure: 1. Call collect. If `allDone` is false, `sleep 25` and call it again. Keep looping — the workers run live in the panes. 2. A `done` lane's `output` is the worker's delivered result; a `dead` lane's pane exited without delivering (note it as failed/needs review). 3. When `allDone` is true, read every lane's `output` and **synthesize the combined results back to the user** (per lane: what it produced). Keep the loop bounded (e.g. stop after ~15 min and report whatever delivered). ## Optional mode — Runtime (`omp team`) Choose this only when the user explicitly wants the team to run in the background or needs runtime features. ### When to choose it - The user asked for a **background** team - You need `omp team status`, shutdown, or runtime task APIs - You do **not** need the panes in the current tmux window ### Launch ```bash omp team :copilot "" --name ``` The runtime automatically: 1. Creates a tmux session with split panes 2. Launches `copilot --allow-all-tools` in each pane 3. Auto-accepts folder trust prompts 4. Waits for readiness, then sends the task prompt 5. Tracks task state and heartbeats; active loops enable bounded idle prompting ### Monitor and cleanup ```bash omp team status # check progress (same passed to --name) tmux attach -t omp-team- # watch panes live omp team shutdown # kill when done ``` ## Prerequisites - `tmux` installed and session running - `omp` on PATH - `jq` for JSON parsing (split mode only) ## Task / prompt guidelines Each task must be **self-contained**. The agent has no context from this session. Include: - Exact files or directories to work in - What to do (fix, upgrade, etc.) - How to verify (run tests, etc.) - Commit message to use ### Good example > In src/auth/login.ts, replace bcrypt with argon2. Update the import, change the verify call, run `npm test -- --grep auth`. Commit: "refactor: switch to argon2". ### Bad example > Fix the auth module. (Too vague) ## Composition Use `/ralplan` before `/team` to produce the plan. Use `/verify` after completion. ## Limitations - Each pane is an independent session — no shared state - Workers can message each other via `omp team api send-message` (runtime mode only) - If tasks depend on each other, use `/ralph` instead ## Cost/token note This skill can drive multiple tool calls or long-running output. Use `omp cost [--today] [--session ]` for local hook-ledger estimates only; it is not provider billing. Keep injected summaries concise and prefer bounded output when rerunning noisy commands.