workflow
Orchestrate a MULTI-PHASE, dependent, or resumable run over many provider subagents from a JS script, off the main context (`cc-fleet workflow`). Use for fan-out→barrier→synthesis, per-item pipelines, loop-until-dry, or a run that must survive a kill and `--resume` from its journal. NOT a flat fan-out of independent tasks (that is /cc-fleet:subagent — cheaper, no script); NOT interactive collaboration (that is /cc-fleet:team); NOT trivial single-shot work for the main session.
npx skills add ethanhq/cc-fleet --skill workflow --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Orchestrates a multi-phase, dependent, or resumable run across many provider subagents from a JavaScript script, executing off the main session context. Uses for fan-out—barrier—synthesis, per-item pipelines, loop-until-dry, or runs that must survive a kill and resume from its journal. Not a flat fan-out of independent tasks, not interactive collaboration, and not trivial single-shot work for the main session.
How it works
- Defines a workflow as a JavaScript script run by cc-fleet workflow run; orchestration plan lives in script variables. The API mirrors the native Claude Code Workflow tool, with the addition of provider on agent().
- The script can nível multi-phase structures: fan-out to provider subagents, barrier synchronization, per-item pipelines, or sustained runs with journaled resume capabilities. The run is executed in a cc-fleet process OFF the main session context.
- Skills and options within agent() include provider (optional), model, schema, timeout, max_budget_usd, max_turns, isolation, profile, tools, skills, mcp, and others. A leaf failure rejects the promise; in parallel/pipeline contexts, failures degrade to null as defined by dispatch tables.
- Supports parallel(thunks) to run leaves concurrently with a barrier, and pipeline(items, ...stages) for staged processing without inter-stage barriers. The workflow(path, args?) can run another JS inline on the same engine (one level deep).
- Budget semantics cover USD and tokens, with strict gating on max_budget_usd and related surfaces. Phase labeling and log emission are supported, as well as wait/stop/restart controls for running jobs.
When to use it
- Use for multi-phase or dynamic orchestration over many provider subagents: fan-out + barrier, per-item pipelines, loop-until-dry, branch-on-result, with a board run-tree.
- Do not use for a single flat batch of independent one-shots; do not use for trivial one-shot main-session work.
What it can touch
- The script interacts with provider subagents via agent() and may reference tools, skills, mcp, and various agent options as described in the SKILL.
- The run supports status, wait, stop, restart, watch, and log visibility commands to monitor and manage execution.
Caveats
- The workflow is off-main-session; ensure the execution environment has access to cc-fleet and its subagents. The script cannot use Date, Math.random, eval, Function, setTimeout, require, fs, or dynamic imports; pass time or randomness through args. Leaf failures are dispatched via error_code semantics; specific codes require actions such as STOP, re-pinning default provider, or refreshing provider data.
# workflow — multi-phase JS orchestration over provider subagents **Wrong lane?** A flat one-shot fan-out of independent tasks → /cc-fleet:subagent; interactive collaboration you message back and forth → /cc-fleet:team; arbitration in cc-fleet-shared/routing.md. When this skill cites `cc-fleet-shared/<file>.md`, OPEN it with the Read tool at `../cc-fleet-shared/<file>.md` relative to this SKILL.md — the cited content is load-bearing, not optional background. > **Execution environment — check before running anything.** Confirm your shell tool executes on the host where cc-fleet is installed. In sandboxed or remote agent sessions, a tool named Bash may run on an isolated machine with a different filesystem, PATH, processes, and tmux server — `command not found`, a healthy-looking `doctor` whose leaves can't reach your files, or a wrong working directory should prompt you to verify whether you are in a sandbox shell, not conclude that cc-fleet is broken. If so, route commands through a host-executing bridge tool (for example, desktop-commander) and pass host paths for any files you reference; do not retry the same Bash call expecting different results. If no host-executing tool is ava
- When to use it
- The provider ask ladder (ask at most once per task)
- The script API (mirrors the native Workflow tool)
- What a workflow script can NOT use (determinism — the journal depends on it)
- Running it
- Waiting on a run: arm wait in a backgrounded Bash (push, not poll)
- Leaf failures — dispatch on errorcode (do not parse prose)
- Resume (content-hash journal)
- Non-goals (state plainly, don't oversell)
- Worked example — research sweep (fan-out → pipeline → loop)
- Anti-patterns
cc-fleet workflow status "$RUN" --json # manifest + every tagged leaf (run→phase→agent)
cc-fleet workflow list --json # all runs, newest first
cc-fleet workflow stop "$RUN" # reap a running run (engine + in-flight leaves)
cc-fleet workflow stop "$RUN" --leaf <job|label> # hold ONE agent in place (run keeps going); --phase <title> holds a phase
cc-fleet workflow restart "$RUN" --leaf <job|label> # re-run a held/running agent in place; --phase <title> a phase;
cc-fleet workflow wait "$RUN" --timeout 3m --json # block silently until the run settles ("Waiting on a run" below)
or watch the board's Dynamic Workflows view: live log, token/cost columns, prompt/answer drill-in.
x/r there are level-scoped: run row = the run, Phases pane = the phase, agent pane = the leaf
may show it briefly. Not an error/retry/backoff — the run waits on it indefinitely.
If held persists across polls, resume it with restart --leaf/--phase or tell theWhat does the workflow skill do?
Orchestrate a MULTI-PHASE, dependent, or resumable run over many provider subagents from a JS script, off the main context (`cc-fleet workflow`). Use for fan-out→barrier→synthesis, per-item pipelines, loop-until-dry, or a run that must survive a kill and `--resume` from its journal. NOT a flat fan-out of independent tasks (that is /cc-fleet:subagent — cheaper, no script); NOT interactive collaboration (that is /cc-fleet:team); NOT trivial single-shot work for the main session.
How do I install it?
Run `npx skills add ethanhq/cc-fleet --skill workflow --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From ethanhq/cc-fleet, a repository with 201 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.