--- name: flow description: "OPS on-demand: This skill should be used when the user asks to \"/ops:flow\", \"dev lifecycle\", or \"where…" argument-hint: '[stage|intent] [args]' allowed-tools: - Bash - Read - Grep - Glob - Skill - Agent - TeamCreate - SendMessage effort: medium maxTurns: 20 --- ## 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: ```bash "${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 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: | Intent keywords | Resolves to | | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | (empty), map, here, where | print map (`Read FLOW.md`) + `bin/flow-state` output. **Stop — do not delegate.** | | ideate, brainstorm, office-hours | `/office-hours` | | hard-truths, yolo | `/ops:ops-yolo` | | spec, specify, scope, issue | `/spec $REST` | | plan, roadmap, phase-plan | **project** → `gsd-plan-phase`; **ad-hoc** → `/autoplan` | | ultraplan, deep-plan | `gsd-ultraplan-phase` | | design, ui, mockup, html | `/design-consultation $REST` | | build, execute, implement, code | **project** → `gsd-execute-phase`; **multi-project** → `gsd-master-orchestrator`; **ad-hoc** → direct edits in an isolated worktree | | feature-dev, fd, feature, architect-feature | `/feature-dev $REST` (overlay — optional structured pipeline before/alongside build; does not replace GSD execute) | | review, code-review, cr | `/review` — **project** also runs `gsd-code-review` | | security, cso, sec-review | `/cso` | | test, qa | `/qa $REST` — **project** also runs `gsd-verify-work` | | ios-qa, ios-test | `/ios-qa` | | ship, land | **project** → `gsd-ship`; **ad-hoc single-repo** → `/ship`; **multi-repo salvage** → `/ops:ops-merge` | | deploy, release, rollout | `/ops:ops-deploy` then `/canary` | | canary | `/canary` | | monitor, fires, incidents | `/ops:ops-fires` | | status, health | `/ops:ops-status` | | retro, reflect | `/retro` | | learn | `/learn` | | ops, inbox, comms, marketing, finops, voice, home, daemon | `/ops:ops $ARGUMENTS` (hand the whole arg string to the ops sub-router) | | projects, portfolio | `/ops:ops-projects` | ### 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.