authoring-workflowslisted

# Authoring dynamic workflows A dynamic workflow moves the "what runs next" decision out of the LLM and into a deterministic JavaScript script that a runtime executes in the background. Use this skill when you are about to write one. The discipline here is small: **be honest about whether you need a workflow, pick the paradigm by its shape, and write to the runtime's own validation contract — the harness is the authoritative gate, so you don't reimplement it.** ## 1. The honest test — do you even need a workflow? A workflow earns its keep when a task needs **tens-to-hundreds of agents** coordinated, with intermediate results kept *out* of your context. It is overkill otherwise. - A two-line bugfix does **not** need a five-agent review panel. - A single lookup does **not** need a fan-out. - If the work is one reasoning chain with one deliverable, dispatch a single sub-agent — not a workflow. Reach for a workflow only when at least one of these is true: the work fans out into many independent units, the intermediate output would flood your context, or you want a reusable quality pattern (adversarial cross-review, judge panel). If none hold, stop here. ## 2. Paradigm decision tree Pick by the **shape** of the work, not by taste. (Full semantics in `references/mechanism.md`; full pattern catalog in `references/patterns.md`.) - **Independent tasks AND you need ALL results together** → **fan-out** (`parallel()`, a barrier). Template: `assets/templates/fan-out.js`. - **M