Workflow patterns behind Claude Dynamic Workflows

A community README has been published breaking down the key concepts behind Claude Dynamic Workflows, a runtime system for orchestrating multiple subagents in a controlled, deterministic manner. The educational resource explains seven conceptual layers of the workflow system, including runtime primitives like `agent()`, `pipeline()`, and `parallel()`, as well as an "Ultracode" mode that makes multi-step orchestration the default for substantive tasks. The breakdown aims to make the workflow skill easier to scan and understand for developers tackling complex jobs such as research, audits, and large-scale code migrations where a single agent or context window is insufficient.

A community README that explains the key ideas surfaced in dynamic-workflows-skill/SKILL.md : what dynamic workflows are, when they are used, how their runtime primitives work, and which orchestration patterns appear most important. Important This repository is unofficial and intended as an educational breakdown of a Claude Dynamic Workflows skill. The goal is to make the material easier to scan, understand, and discuss. dynamic-workflows-skill/SKILL.md — the workflow skill file collected in this repository. README.md — a guided explanation of the most important parts of that skill. The skill describes a workflow runtime for orchestrating many subagents in a controlled, deterministic way. Rather than using a single model call for everything, it presents workflows as executable orchestration logic for decomposition, verification, synthesis, and scaling. In practical terms, the system appears designed for tasks such as research, review, migration, audits, and other jobs where one context window or one agent is not enough. The skill is long, but it becomes much easier to understand if you split it into seven conceptual layers: Purpose and opt-in rules — why workflows exist and when they are allowed. Ultracode mode — how the system changes when exhaustive orchestration is enabled. Workflow file structure — how a script is declared with meta and phases. Runtime primitives — the core functions such as agent , pipeline , and parallel . Execution rules — concurrency limits, barriers, arguments, budgets, and nested workflows. Patterns — reusable orchestration shapes like adversarial verification or loop-until-dry. Resume semantics — how runs can continue from cached prefixes after interruption. The opening section frames workflows as a tool for deterministic multi-agent orchestration. They are meant for tasks that need parallel decomposition, staged verification, or broad coverage across a large work surface. A major theme is explicit opt-in . The skill repeatedly says workflows should only run when the user clearly requested that level of orchestration, invoked a workflow-specific command, or when a higher-level mode already authorizes it. This matters because workflows are presented as expensive: they can fan out into many subagents and consume substantial tokens. The system therefore treats them as a powerful mode, not the default answer to every task. One of the most interesting parts of the skill is the description of Ultracode . In this mode, workflow orchestration becomes the default for substantive tasks, and token cost is treated as secondary to thoroughness. The skill suggests that Ultracode is not just “think harder.” It appears closer to a standing permission model that allows multi-step workflow authoring and execution by default, especially for harder tasks like understand - design - implement - review. That is an important conceptual shift: the system starts to resemble a programmable runtime, not just a single assistant responding turn by turn. The skill shows that each workflow script begins with a literal export const meta = { ... } block. This metadata gives the workflow a name, description, and optional phase definitions. A key implementation detail is that the meta object must be a pure literal. In other words, it should not be dynamically assembled from variables, function calls, or template expressions. The phase system is also important. Phase titles in meta.phases are expected to match the runtime phase calls exactly so the progress UI can group related work correctly. The skill revolves around a small set of runtime primitives that define the orchestration model. agent appears to be the basic unit for spawning a subagent. It can return either free text or structured output when a schema is attached. The options shown in the skill imply a fairly rich runtime: labels, phase assignment, model override, worktree isolation, and even custom subagent types. pipeline is arguably the most important primitive in the document. The skill explicitly frames it as the default for multi-stage work. Its main idea is that each item moves through stages independently, without waiting for all other items to finish the previous stage. That means verification for one branch can begin while another branch is still reviewing. parallel is described very differently: it is a barrier . All tasks in the batch must complete before execution continues. The skill emphasizes that this should only be used when the next step truly needs the full set of prior results together, such as global deduplication or cross-item comparison. phase seems to organize work into progress groups for the UI, while log emits higher-level status updates. These primitives matter because the runtime is not just executing work; it is also exposing the structure of that work to the user. The skill also shows three orchestration-level controls: args for parameterizing workflows with real JSON values. budget for token-aware scaling and hard ceilings. workflow for invoking another workflow as a sub-step. Together, these make the system feel more like a programmable execution environment than a prompt template. A major design principle in the skill is simple: default to pipeline . Barriers are treated as exceptional, not normal. The text gives a clear test for when a barrier is justified: only when a later stage truly needs all previous results at once. Examples include deduplicating all findings before expensive verification, early exit when total results are zero, or prompts that explicitly compare one item to the rest. The skill also explains why unnecessary barriers are bad. They waste wall-clock time by forcing fast tasks to sit idle while waiting for slower ones. Another important rule is bounded scale. Concurrent agent calls are capped per workflow, and total agent count is capped across the workflow lifetime. That suggests the runtime is designed to prevent uncontrolled explosion even when users pass in very large item lists. The most interesting part of the skill is the pattern catalog. These patterns are useful because they reveal the mindset behind the orchestration system. Instead of accepting a finding at face value, the workflow spawns independent skeptics and asks them to refute it. A claim survives only if enough verifiers fail to refute it. This is a strong sign that verification is treated as a first-class concern, not an optional cleanup pass. The skill distinguishes between redundant verification and diverse verification. Rather than asking three identical critics the same thing, it recommends using different lenses such as correctness, security, performance, or reproducibility. This is a subtle but important idea: diversity of evaluators may catch different failure modes that repeated identical checks would miss. Another pattern is the judge panel. The workflow generates several independent attempts, scores them, and synthesizes from the winner while borrowing good ideas from the runners-up. This suggests workflows are not just for finding bugs; they can also be used to explore solution spaces where there is no single obvious first attempt. This pattern is for open-ended discovery tasks. Instead of stopping after a fixed count, the system keeps running until several consecutive rounds produce nothing new. That is useful for audits, bug hunts, and research sweeps where the total number of real findings is unknown in advance. The skill also describes multi-modal sweep and completeness critic patterns. The first spreads search across different perspectives or search angles; the second asks what was missed, such as unread sources, unverified claims, or skipped modalities. Together, these patterns show an architecture that tries to maximize coverage without trusting any single search path. The last major section covers resumability. A workflow run can apparently be resumed using a runId , and unchanged prefixes of prior agent calls can return cached results immediately. This is particularly interesting because it hints at workflow development as an iterative process. You do not always rerun the entire graph; you can keep the stable prefix and only re-execute the edited tail. The skill also explains some unusual restrictions through this lens: APIs like Date.now and Math.random are blocked because they would break deterministic resume behavior. The biggest takeaway is that modern agent systems may be evolving away from “one model, one response” and toward explicit orchestration frameworks with decomposition, verification, budgeting, and resume semantics built in. If you are opening dynamic-workflows-skill/SKILL.md for the first time, this is the fastest path: - Read the opening section on workflow purpose and opt-in. - Read the Ultracode section. - Skim the meta block and runtime primitive definitions. - Focus carefully on pipeline vs parallel . - Read the quality patterns section. - Finish with the Resume section. That sequence gives the best mental model with the least cognitive overload. - This README is an explanatory guide, not an official specification. This repository is best treated as a community note-taking and analysis project. Its value comes from organization, interpretation, and examples rather than from treating the skill as an official public standard.