From ops
ONE entrypoint for the whole dev lifecycle — ideate, spec, plan, design, build, review, test, ship, deploy, monitor, retro. Routes to the single canonical command per stage (gstack / GSD / claude-ops) and picks project-mode (GSD phase machine) vs ad-hoc-mode (gstack stateless) from repo `.planning/` state. Bare `/flow` prints the lifecycle map + your current "you are here" position.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ops:flow [stage|intent] [args][stage|intent] [args]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
If `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set, use **Agent Teams** when a
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:
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.
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.
The one rule: pick the abstraction level from repo state, then delegate to the canonical tool.
.planning/): drive the GSD phase state
machine; GSD phases call gstack/ops tools as sub-steps..planning/): run the gstack stateless lifecycle./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 |
$REST = $ARGUMENTS with the leading intent token removed.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.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.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./flowIf $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.
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.
npx claudepluginhub lifecycle-innovations-limited/claude-ops --plugin opsCreates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.