Use when the user asks for parallel team-style execution of multiple features in one project — orchestrates a team lead + N dev workers, one feature per worktree, each gated on x-qa E2E tests, with blocker escalation to human via SendMessage. Hard requires `plugin.omc` (TeamCreate/SendMessage primitives) and `.x-skills/x-qa/profile.json` (E2E gate).
76
—
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Before any phase:
Pin capabilities per ../x-shared/capability-loading.md. HARD requirement: plugin.omc == true. Refuse with a clear message otherwise.
Read ../x-omo/SKILL.md for the OMO catalog (used inside dev workers via x-do, not directly here).
Read gotchas.md.
Verify the x-qa skill is installed: check that skills/x-qa/SKILL.md exists in the plugin tree (the skill itself, not just a profile). If missing, refuse with: x-team requires the x-qa skill. Ensure x-skills plugin is up-to-date (≥ version that includes x-qa). Then verify <repo-root>/.x-skills/x-qa/profile.json exists. If missing, surface:
x-team requires an x-qa profile. Run
/x-skills:x-qa initfirst. Offer to invoke it inline; block until profile ready.
Isolation prerequisite check. When any entry in <repo-root>/.x-skills/x-qa/profile.json has launch.uses_isolate_profile == true AND --no-isolate was NOT passed, ALSO require <repo-root>/.worktree-isolate/profile.json to exist. If missing, refuse with:
x-team requires an x-worktree-isolate profile because your x-qa profile sets
uses_isolate_profile: true. Runx-worktree-isolate initfirst, or pass--no-isolateto skip per-feature docker isolation (NOT recommended for parallel docker-compose stacks — workers will fail atdocker compose upwith "address already in use").
Detection: jq -e '[.entry_points[].launch.uses_isolate_profile] | any' <profile> returns true. Skip the check entirely when --no-isolate is set.
Verify git rev-parse --is-inside-work-tree succeeds and the user's main branch is clean (git status --porcelain empty), or warn explicitly.
| Form | Behavior |
|---|---|
/x-skills:x-team "<request>" | Decompose into N features, provision team, run. |
/x-skills:x-team --features <N> "<request>" | Force feature count (else auto-decompose). |
/x-skills:x-team --max-features <N> "<request>" | Cap parallel concurrency (default 3). NEVER drops features — extra features are queued and promoted as in-flight slots free up. |
/x-skills:x-team --base <branch> "<request>" | Base branch for worktrees (default: current HEAD). |
/x-skills:x-team --auto-merge | On feature pass, auto-merge to base. Default OFF. |
/x-skills:x-team --resume <team-slug> | Resume an interrupted run. |
/x-skills:x-team --no-isolate | Skip x-worktree-isolate per-feature (passes the equivalent flag through to x-worktree). |
Per references/decomposition-rules.md:
--features <N> not given: use native Grep / OMO explore to scan project, propose feature split, ask user via AskUserQuestion (header: "Feature split"). Allow edit/cancel.name (short slug)spec (full description)acceptance (bullet list)branch slug: feat-<name>-<6hex>--max-features (default 3), run in waves of --max-features parallel: provision the first wave's worktrees now, queue the rest as pending. NEVER drop features — the monitor loop's advance_queue() (see references/monitor-loop.md) provisions each pending feature's worktree and spawns its worker as in-flight slots free up. Surface the wave plan to the user.Slug: <sanitized request 30char>-<6hex> e.g. ship-q2-features-a1b2c3.
TeamCreate {
"team_name": "ship-q2-features-a1b2c3",
"description": "<original user request, truncated 200>"
}The current session becomes team-lead@<slug>.
For each feature in this wave (parallel):
Skill: x-skills:x-worktree <base-branch> <feature-branch>Pass --no-isolate if --no-isolate flag is set on x-team invocation.
Capture each envelope:
WORKTREE_PATH=<abs>BRANCH=<feat-...>ISOLATE_APPLIED=true|false|skippedIf any worktree provisioning fails: abort the wave, run TeamDelete, surface to user.
For each feature:
TaskCreate {
"subject": "<feature name>",
"description": "<full spec + acceptance>",
"activeForm": "Implementing <feature name>"
}
→ task_id
TaskUpdate { "taskId": "<id>", "owner": "worker-<n>" }Initialize feature-map:
Bash: scripts/feature-map-init.sh --team-slug <slug> --request "<req>" --base <branch> --features-json <features.json>Spawn ALL workers in parallel via Task() with team_name, name, and working_directory. Inject references/worker-preamble.md with substitutions filled in:
Task {
"subagent_type": "executor",
"team_name": "<slug>",
"name": "worker-<n>",
"working_directory": "<WORKTREE_PATH_n>",
"prompt": "<filled-in worker preamble + feature spec + acceptance criteria>"
}Update feature-map: phase: running.
See references/monitor-loop.md. Per inbound SendMessage, classify by summary prefix (kind) and extract structured payload from the first ```json … ``` fence in content — OMC's SendMessage has no metadata field. Recognized prefixes: feature_done, blocker, feature_blocked, progress_note. Per kind:
feature_done → idempotence guard: skip if feature_map.status == done or merged_at non-null. Otherwise optionally invoke merge-feature.sh --branch <branch> --base <feature_map.base_branch> --worktree <wt>. Update map. Wave-next: spawn next pending feature if any.blocker → AskUserQuestion, relay back via SendMessage with summary: blocker_resolution:{TASK_ID} and a JSON-fence payload. Update map.blocker.feature_blocked → mark failed in map. Continue (do not abort sibling features).Concurrency: keep at most --max-features workers in in_progress simultaneously. As features reach terminal state, advance the queue.
When all features are terminal (done or failed):
For each active worker:
SendMessage {
"type": "shutdown_request",
"recipient": "worker-<n>",
"content": "All features complete; shutting down"
}Wait up to 30s per worker for shutdown_response. Then:
TeamDelete { "team_name": "<slug>" }Update feature-map: phase: complete (or aborted if user cancelled).
Print to user:
✓ x-team complete
Team: <slug>
Features: <n>
Done: <m>
Failed: <k>
Auto-merged: <a>
Awaiting human merge: <b>
Awaiting merge:
- <feature-name> @ <branch> (worktree: <path>) — QA: pass (<p>/<t>)
Merge: git merge --no-ff <branch>
Failed:
- <feature-name> @ <branch> — see <qa_report> for failures
Inspect: cd <worktree>
Feature map: .x-skills/x-team/teams/<slug>/feature-map.jsonIf --auto-merge and any merges failed (conflict, protected branch): list separately with reasons.
plugin.omc == true.x-skills/x-qa/profile.json existsgit ≥ 2.5--allow-dirty)If all features pass + auto-merge: surface merged branches list. If features pass without auto-merge: print merge commands for human. If any feature blocked: surface blocker reasons, ask user how to proceed.
../x-shared/capability-loading.md, invocation-guide.md, context-envelope.md../x-worktree/SKILL.md (provisioning)../x-qa/SKILL.md (E2E gate inside workers)../x-do/SKILL.md (impl inside workers)See gotchas.md.
Task: {{ARGUMENTS}}
6381b15
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.