Flow

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:

# FLOW_TARGET: the project you are actually working on. Default to the shell's
# cwd, but pass an explicit path when the harness's tool cwd is not the project
# (see the mode-resolution note below).
FLOW_TARGET="${FLOW_TARGET:-$PWD}"
FLOW_STATE=""
for _d in "${CLAUDE_PLUGIN_ROOT:-}" \
          "$HOME/Developer/repos/claude-ops/claude-ops" \
          "$HOME/external-skills/claude-ops" \
          "$HOME/.claude/plugins/marketplaces/ops-marketplace/claude-ops" \
          "$HOME/Projects/claude-ops/claude-ops"; do
  [ -n "$_d" ] && [ -x "$_d/bin/flow-state" ] && { FLOW_STATE="$_d/bin/flow-state"; break; }
done
[ -n "$FLOW_STATE" ] || { echo "flow: no executable bin/flow-state found" >&2; exit 1; }
"$FLOW_STATE" "$FLOW_TARGET"

Both failures are fail-closed on purpose. If no helper resolves, or the target path is not a directory, stop and say so — do not route. MODE is what decides GSD vs gstack, so routing without it silently picks the wrong half of the lifecycle, which is worse than an error.

Use ${CLAUDE_PLUGIN_ROOT:-}, not $CLAUDE_PLUGIN_ROOT: the bare form aborts under set -u, and an unguarded ${CLAUDE_PLUGIN_ROOT}/bin/flow-state expands to the absolute path /bin/flow-state when the variable is unset.

Always pass the target path explicitly. flow-state defaults to $PWD, and on some harnesses the shell tool does NOT run in the directory the user launched from — Hermes, for example, runs terminal commands in $HOME. A bare flow-state there inspects the home directory, finds no .planning/, and reports MODE=AD-HOC for every project. PROJECT-MODE then never triggers, so the GSD phase state machine is silently unreachable and every request falls through to the ad-hoc gstack lifecycle. Resolve the project directory first (the repo the user named, or the one under discussion) and pass it.

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 LIFECYCLE-MAP.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

Load ops-rules before acting. Public repo (no personal data). Outbound: one draft → one approval → one send. If AskUserQuestion / Workflow are missing, follow Rule 10 in ops-rules (Hermes: numbered options / two-turn Telegram card; delegate_task).

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: