workflow-composerlisted

# Authoring workflows for Claude Code's Workflow tool A workflow moves a multi-step plan out of the conversation and into code. Normally Claude is the orchestrator: it decides turn by turn what subagent to spawn, and every intermediate result lands back in its context. A workflow inverts that — a script holds the plan, the runtime executes it in isolation, and intermediate results stay in script variables. Only the leaf `agent()` calls spend model tokens; the loops, conditionals, and fan-out are plain deterministic JavaScript. ⚠ **Every `agent()` call is a Claude Code subagent, always — a workflow has no primitive that runs a process or reaches another model directly.** Routing a role to `codex:codex-rescue` or `workflow-toolbox:opencode-verifier` (see `references/model-and-agent-routing.md`) still spends a Claude turn: that agent itself shells out to an external CLI, and the host cannot see or reroute what happens inside its call once it starts. Recognise this before authoring, not after: composing a workflow that cannot do the job is wasted work. There are **two ways to author one**, and choosing correctly is the first decision: - **Toolkit path (`@workflow-toolbox`)** — for workflows that will be **kept, re-run, and maintained**. You write a typed TypeScript file against a tested pattern library and compile it to a self-contained `.js` artifact. This is the default for anything repeatable. See [the toolkit path](#the-toolkit-path-repeatable-workflows). - **Raw `.