Agent Teams support

If CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set, use Agent Teams when a lifecycle stage fans out into parallel, coordinated work (e.g. build + test + review running together, or a multi-repo ship). This enables:

• Stage agents share context mid-flight (the test agent surfaces a regression → the build agent pivots before review starts)
• You can steer priorities in real time ("land the API change first, then docs")
• Agents report progress as each stage completes, so you sequence the merge

Team setup (only when the flag is enabled, and only for genuinely parallel stages):

TeamCreate("flow-lifecycle")
Agent(team_name="flow-lifecycle", name="stage-build", ...)
Agent(team_name="flow-lifecycle", name="stage-test", ...)

Steer with SendMessage / broadcast; share work via TaskCreate/TaskUpdate.

If the flag is NOT set, fall back to standard fire-and-forget subagents (the default), or just route the stage to its single canonical command inline.

Runtime Context

Before routing, compute where the user is on the lifecycle:

"${CLAUDE_PLUGIN_ROOT:-$HOME/Projects/claude-ops/claude-ops}/bin/flow-state"

This prints: mode (PROJECT / AD-HOC), current .planning/ phase (if any), open PRs, and deploy state — the "you are here" marker. Read it first so mode-sensitive routes (build / ship / review) resolve correctly.

The canonical map lives in FLOW.md (same dir). Read it when you need the full per-stage ownership table; the dispatch table below is the routing copy.

FLOW — One Lifecycle Entrypoint

The one rule: pick the abstraction level from repo state, then delegate to the canonical tool.

• PROJECT-MODE (git root has .planning/): drive the GSD phase state machine; GSD phases call gstack/ops tools as sub-steps.
• AD-HOC-MODE (no .planning/): run the gstack stateless lifecycle.
• OPS (/ops:*): always available in either mode.

Route $ARGUMENTS (first token = intent) using this table:

Routing notes

• $REST = $ARGUMENTS with the leading intent token removed.
• Mode resolution: use the MODE= line from flow-state. PROJECT when the git root has .planning/; AD-HOC otherwise. "multi-project" = the user named >1 repo/project or asked for portfolio-wide work.
• Delegation only. This skill never does the work itself — it invokes the canonical command via the Skill tool (or prints the route if the target is a personal/plugin slash-command the model should call next). After routing, the target skill's own ## CLI/API Reference governs execution.
• Ambiguity: if intent spans two stages, prefer the earliest unfulfilled stage for the current flow-state position.
• ops passthrough: for any ops* intent, forward the entire $ARGUMENTS to /ops:ops — it has its own sub-router; do not pre-parse it.

Bare /flow

If $ARGUMENTS is empty: Read FLOW.md, then run bin/flow-state, and present the lifecycle map with the current position highlighted. Offer the next canonical stage as the suggested action. Do not auto-advance.

CLI/API Reference

Router only — no direct tool calls. bin/flow-state is the sole helper (detects mode + position). All execution is delegated to the canonical target skill after routing.