agile-team

name	agile:team
description	Team lifecycle gateway: create, delete, list, add, remove, kill, get, status, prune, message — manages team creation, member spawning, monitoring, messaging, and teardown. Supports pipeline mode (chain multiple commands in one prompt) and batch add (multiple members with 'name1,name2 with agent-type; name3 with agent-type2' syntax).
argument-hint	create|delete|list|add|remove|kill|get|status|prune|message [args]
user-invocable	true
disable-model-invocation	false
allowed-tools	Read, Glob, Grep, Bash, Skill, TeamCreate, TeamDelete, Agent, SendMessage, TaskList, TaskGet, TaskUpdate, AskUserQuestion

/agile:team

Team lifecycle gateway for agile-scoped team operations. All team management flows through this skill instead of calling individual team skills directly.

Routing

Step 0: Pipeline Detection

Before single-command routing, check if $ARGUMENTS contains multiple commands chained together.

Detection: Split $ARGUMENTS on newlines. For each line, strip any leading /agile:team prefix (users naturally repeat it when chaining). A line starts a new command if its first whitespace-delimited token (after prefix stripping) is a valid subcommand. Lines that don't start with a valid subcommand are continuations of the previous command (joined with a space).

Pipeline mode activates when 2+ commands are detected after this parsing.

Pipeline execution rules:

1. Execute each command sequentially in order
2. Auto-context forwarding: If a create command produces a team name, subsequent commands in the pipeline inherit that team name automatically (no need to repeat it)
3. Deferred standby: Standby gates (the "STOP and wait" behavior in create and add) are suppressed for all commands except the last command in the pipeline. This allows create to flow into add without blocking.
4. Error short-circuit: If any command returns status: "error", stop the pipeline immediately. Report which step failed and the error, then STOP.
5. Aggregated output: Collect results from each command into a pipeline result:

   {
     "status": "pipeline_complete",
     "steps": [
       { "command": "create epic-kotlin", "result": { "status": "created", ... } },
       { "command": "add epic-kotlin ...", "result": { "status": "added", ... } }
     ],
     "standby": true
   }
   

If only 1 command is detected, proceed with normal single-command routing below.

Single-Command Routing

1. Extract the first whitespace-delimited token from $ARGUMENTS as the subcommand

• Let remaining = text after the subcommand token, trimmed of leading/trailing whitespace

2. Help detection — if ANY of these match, read modules/help.md and execute in overview mode, then STOP:

• $ARGUMENTS is empty or whitespace-only (user typed /agile:team with no args)
• Subcommand is help or --help

3. Validate subcommand is one of: create, delete, list, add, remove, kill, get, status, prune, message

• If invalid: return

  {
    "status": "error",
    "code": "INVALID_SUBCOMMAND",
    "message": "Unknown subcommand '{token}'. Valid: create, delete, list, add, remove, kill, get, status, prune, message",
    "hint": "Did you mean '{closest_match}'?"
  }
  

4. Subcommand-specific help — if subcommand is valid but remaining is empty:

• Zero-arg subcommands (list, prune): Skip this step — route directly to the module
• Optional-arg subcommands (delete, status): Skip this step — route directly to the module (they accept an optional team name and auto-detect if omitted)
• Other subcommands (create, add, remove, kill, get, message): Read modules/help.md and execute in subcommand-specific mode (pass the subcommand name), then STOP

5. Pre-read shared reference: Read references/team-detection.md (used by 9/10 modules; list scans all teams directly but still benefits from naming rules)

6. Read modules/{subcommand}.md for operation instructions

7. Execute the module instructions — remaining is the module's argument string

Argument Passing

The dispatcher does NOT parse parameters — each module handles its own input parsing. The remaining text after the subcommand token is passed verbatim to the module as its argument string.

For full argument serialization rules, see references/invocation-contract.md. For structured return format, see references/output-contract.md.

Subcommands

Subcommand	Description	Zero-Arg?
create	Create a new team (TeamCreate only)	No
delete	Full team teardown (task audit + shutdown + TeamDelete)	Yes
list	List all teams across ~/.claude/teams/	Yes
add	Spawn teammates (hybrid scoring + selection + spawning)	No
remove	Graceful remove a member (shutdown_request + wait + reassign)	No
kill	Force remove a member (immediate, no waiting)	No
get	Rich member profile (config + tasks + expertise + activity)	No
status	Team member status + progress dashboard	Yes
prune	Shut down idle members whose work is complete	Yes
message	Send direct message to a member or broadcast to all members	No

Human-First Gate (MANDATORY)

When the human directly invokes /agile:team create or /agile:team add, every agent on the team — including the team lead — MUST enter standby. This means:

1. No implementation work — no code changes, no file edits, no builds
2. No task distribution — no assigning, decomposing, or dispatching tasks
3. No subagent spawning — no dispatching background agents for any purpose
4. No proactive exploration — no reading code, no analyzing epics, no "preparing"

The team exists but is inert. Every member waits silently for the user's next explicit command. The user decides what happens next — whether that's /agile:team add, task assignment, or something else entirely. The team does not anticipate or pre-empt the user's intent.

Convention Boundary

This dispatcher pattern is justified because all 10 subcommands share the same team detection logic, team naming conventions, and reference documents. Use this pattern only when (a) 3+ subcommands share reference documents AND (b) all subcommands operate on the same domain entity.