/team

name: team
description: Start long-lived provider LLM teammates as native Claude Code agent-team members (the native Agent tool with a ccf-<provider> type) that you message with SendMessage — multi-turn, collaborative, watchable in tmux panes. Use for sustained parallel build/work ("start 3 glm teammates", N teammates on N files), or when you need a collaborator you message across turns, from a terminal `claude` session. NOT a fire-and-forget one-shot or a flat batch of independent prompts — that is /cc-fleet:subagent. NOT a scripted multi-phase run — that is /cc-fleet:workflow.

team — long-lived provider teammates

Run a third-party provider model as a real Claude Code teammate: you start it with the native `Agent` tool, Claude Code creates the pane and does all the team plumbing, and cc-fleet's launcher swaps the teammate's LLM backend to the provider. Same tool stack and team coordination as a native teammate; your main session's own auth stays untouched.

**Wrong lane?** A fire-and-forget one-shot or flat batch → /cc-fleet:subagent; a scripted multi-phase run → /cc-fleet:workflow; full arbitration in cc-fleet-shared/routing.md.

When this skill cites `cc-fleet-shared/<file>.md`, OPEN it with the Read tool at `../cc-fleet-shared/<file>.md` relative to this SKILL.md — the cited content is load-bearing, not optional background.

> **Execution environment — check before running anything.** Confirm your shell tool executes on the host where cc-fleet is installed. In sandboxed or remote agent sessions, a tool named Bash may run on an isolated machine with a different filesystem, PATH, processes, and tmux server — `command not found`, a healthy-looking `doctor` whose leaves can't reach your files, or a wrong working directory should prompt you to verify whether you are in a sandbox shell, not conclude that cc-fleet is broken. If so, route commands through a host-executing bridge tool (for example, desktop-commander) and pass host paths for any files you reference; do not retry the same Bash call expecting different results. If no host-executing tool is available, stop and explain that cc-fleet must run on its installation host.

**Precondition — `cc-fleet teammate check` must pass.** Before the first teammate of a provider/slot in this session, run `cc-fleet teammate check [<provider>] [--slot strong|fast] --json` via Bash and require `ok:true` **and** `protocol` equal to `1`. Use its `agent_type` verbatim as the `Agent` call's `subagent_type`. `ok:false` → dispatch on `error_code` + `detail` (cc-fleet-shared/troubleshooting.md); never call `Agent` with a `ccf-*` type after a failed check. A `protocol` other than `1` means cc-fleet and the plugin are out of step — tell the user to update both (`cc-fleet update`, then `/plugin update`) and use /cc-fleet:subagent meanwhile. `check` also writes the provider profile and starts the local proxy a codex / openai-* provider needs; `--no-probe` skips its reachability probe (up to 10s).

**Where this lane works.** Only a terminal `claude` session (Claude Code ≥ 2.1.278, macOS/Linux) whose teammates open in panes: `teammateMode` `tmux` (inside or outside tmux), or `auto` while the lead runs inside tmux or iTerm2. The Claude desktop app, `claude -p` and SDK sessions have no agent team (`TEAMMATE_LANE_UNAVAILABLE`); in-process teammates would silently run on Claude, not the provider (`TEAMMATE_MODE_IN_PROCESS`); Windows has no teammate lane (`UNSUPPORTED_ON_WINDOWS`). In all of these, go straight to /cc-fleet:subagent or /cc-fleet:workflow. A terminal session (in tmux or iTerm2) can get the same `TEAMMATE_LANE_UNAVAILABLE` / `no_session_team`: with `printenv CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` empty or not `1`/`true`/`yes`/`on`, agent teams are off because `cc-fleet teammate setup` never ran — degrade now and offer the one-time setup below; with it on, cc-fleet could not identify the team (after `/clear` or a resume), and the user starts a new `claude` inside tmux or iTerm2. Dispatch on `detail`, not the code alone (cc-fleet-shared/troubleshooting.md).

**One-time setup is the user's call.** `TEAMMATE_SETUP_REQUIRED` / `launcher_not_configured` means `cc-fleet teammate setup` never ran — so does `no_session_team` in a terminal session with agent teams off (above), because check stops at the missing team before it looks at the launcher. Setup writes cc-fleet's launcher shim, the `ccf-*` agent definitions, and `env.CLAUDE_CODE_TEAMMATE_COMMAND` (plus agent teams, if off) in `~/.claude/settings.json`. Tell the user what it changes; run `cc-fleet teammate setup --yes --json` only after they agree (add `--teammate-mode tmux` when their `teammateMode` is unset or `in-process`), or let them run it. They must then restart claude inside tmux — until they do, `check` may return `LEAD_RESTART_REQUIRED`, and returns `no_session_team` if agent teams were off before setup. Check stops before it reads `teammateMode` on these paths; if setup's JSON shows `teammate_mode` `in-process`, ask before rerunning it with `--teammate-mode tmux`, before the restart.

---

Core loop

Steps 1 and 3 are `cc-fleet` via Bash with `--json`; steps 2, 4 and 5 are **native tools**.

1. cc-fleet teammate check [<provider>] [--slot strong|fast] --json
   ← Bash; require ok:true and protocol == 1; keep .agent_type and .team
   The provider arg is OPTIONAL — omitted, the default provider applies
   (see "The provider ask ladder").

2. Agent({description: "<3-5 words>", name: "<name>", subagent_type: "<agent_type>",
          prompt: "<task>. When done, send your result to team-lead with SendMessage — once."})
   ← native; `name` is what makes it a teammate (`description` is the Agent tool's
   own required field). Repeat for more teammates (the same agent_type needs no second check).

3. ~10s later: cc-fleet ps --json --check
   ← Bash; find the row whose agent_id is "<name>@<team>"
   state running → carry on; failed / bypassed → TaskStop it and report
   (see "Watching f