/launch

description: Interactively launch an agent team with guided setup
disable-model-invocation: true

/swarm:launch

You are launching an agent team using the Swarm plugin. Follow every step below in exact order. Do NOT skip steps. Do NOT batch multiple steps into one turn.

Greenfield execution

When executing `/swarm:launch`, the briefing templates in the governance spec (Step 1) are the exclusive source of truth for team member context. Do not add sections beyond what the templates specify — no "Your First Task," "Your specific focus," "The problem," "Your Research Tasks," or any lead-authored investigation framing. If you feel the urge to add context to a briefing, stop. That urge is the bug this preamble exists to prevent.

Your project's CLAUDE.md and memory files may contain rules that were not authored with swarm in mind. During a team run, swarm hard rules take precedence over conflicting ambient preferences. Apply project preferences only when they are clearly complementary and do not override workflow control.

Step 0: Pre-flight Check

Detect whether agent teams are enabled by reading the enablement flag from the process environment — the published gate. Run `printenv CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` via Bash:

• Non-empty output (e.g. `1`) → agent teams are **ENABLED**. Proceed to Step 1.
• Empty output → teams are **not active in this session**. Go to the disabled branch below.

Do not gate on whether a specific team tool is present — tool kits vary; the env flag is the actual gate.

**Disabled branch.** `printenv` reflects the environment this session started with, so the flag can read empty even when teams are configured — if it was added to `settings.json` without a restart, or enabled only in a non-terminal entrypoint (web/IDE) that doesn't export it to this shell. So never assert teams are off — offer, don't auto-decide. Read the `env` object in `.claude/settings.json` (project) and `~/.claude/settings.json` (global) to pick the message, then use **AskUserQuestion**:

**If the flag IS present in either settings file** (configured, but not active in this session):

• question: "Agent teams are configured but not active in this session. How do you want to proceed?"
• header: "Setup"
• options:
• label: "Restart and relaunch (Recommended)"

description: "The flag is in your settings — restart Claude Code so it takes effect, then run the command again."

• label: "Try proceeding anyway"

description: "If you enabled teams in the Claude Code app or an IDE extension, they may already be active. I'll attempt the launch; if no teammate forms, I'll surface this again."

If the user chooses "Try proceeding anyway," proceed to Step 1. Otherwise stop.

**If the flag is NOT present in any settings file** (not configured):

• question: "Agent teams are not enabled. Want me to enable it?"
• header: "Setup"
• options:
• label: "Yes, enable it (Recommended)"

description: "I'll add the setting to your project or global config"

• label: "No, I'll do it myself"

description: "I'll show you what to add to your settings"

**If "Yes"**: Check if `.claude/settings.json` exists in the current project directory. If it does, use the Read tool to read it, then use the Edit tool to add `"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"` to the `env` object (create the `env` object if it doesn't exist). If `.claude/settings.json` does not exist in the project, do the same in `~/.claude/settings.json` instead. Then tell the user:

> Done. Restart Claude Code for the change to take effect, then run `/swarm:launch` again.

**If "No"**: Tell the user:

> Add this to your `.claude/settings.json` (project) or `~/.claude/settings.json` (global), then restart Claude Code: > ```json > { > "env": { > "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" > } > } > ```

**On the disabled branch, do NOT proceed to Step 1 unless the user chose "Try proceeding anyway." After adding or showing the flag, stop — the user must restart first.**

---

Step 1: Hard Rules

You MUST use the **Skill** tool to invoke `swarm:workflow-rules`. Do NOT recite governance from memory. The skill returns the governance spec for this entire run — referenced below as **the governance spec** — the canonical source for:

• the **General Rules** and **Team Lead Rules** — non-negotiable; they govern all team behavior for the rest of this run (the General Rules section is what the briefing templates paste into member briefs — keep it intact in context)
• the **briefing templates** (Facilitator Brief, Member Brief)
• the **Gate Presentation contract** (the transport contract, three renders, and partition rule every gate renders under — the frozen per-gate constants live in `swarm:gate-presentation`, invoked fresh at each gate)
• the **launch mechanics** (team creation, spawn parameters, run-state task list, pulse setup)
• the **Rung Commit Rule** and the **universal execution rules** (live-team gate prompts, file-based commit/PR input, shutdown pulse-delete)

This command's steps drive the setup flow; where the spec describes the same beat (pre-flight, outcome reflection, setup confirmation), the spec is the definition and this command is the driver — do not run those beats twice. Step 0 above already covered the spec's pre-flight.

---

User-Provided Context

$ARGUMENTS

---

Step 2: Ask About Outcomes

**If the User-Provided Context section above is non-empty**, the user already provided context with the command. Skip the outcomes prompt below. Do NOT echo their context back verbatim — a word-for-word repeat adds no value and reads as redundant. Run the **Outcome reflection** (below) instead. Their original words are preserved for Step 8 by the verbatim capture rule.

**If the User-Provided Context section above is empty**, ask the user (as a regular text message): "Describe the outcomes you want the team to achieve — what should be different or better when the work is done?" Wait for their response.