# dynamic-workflows

This skill should be used when an agent is deciding whether to author a dynamic workflow — a self-authored, ephemeral multi-agent harness — for a task. Use when the user asks about "dynamic workflows", "multi-agent harness", "fan-out", "subagents in parallel", "adversarial verification", "the ultracode trigger", "should I use a workflow", or when a task looks long-running, massively parallel, highly structured, or adversarial. Names the six composable patterns, the election rubric for when NOT to spend the extra compute, and the two governance invariants (INV-1 ephemeral-proposes, INV-2 quarantine).

- **Kind:** skill
- **Source:** https://github.com/Habitat-Thinking/ai-literacy-superpowers
- **Page:** https://forefy.com/skills/1842ebe6-894b-4e3a-8567-9624c8d3c8a1
- **API (JSON + files):** https://forefy.com/api/asr/1842ebe6-894b-4e3a-8567-9624c8d3c8a1

---

## SKILL.md

---
name: dynamic-workflows
description: This skill should be used when an agent is deciding whether to author a dynamic workflow — a self-authored, ephemeral multi-agent harness — for a task. Use when the user asks about "dynamic workflows", "multi-agent harness", "fan-out", "subagents in parallel", "adversarial verification", "the ultracode trigger", "should I use a workflow", or when a task looks long-running, massively parallel, highly structured, or adversarial. Names the six composable patterns, the election rubric for when NOT to spend the extra compute, and the two governance invariants (INV-1 ephemeral-proposes, INV-2 quarantine).
---

# Dynamic Workflows

A **dynamic workflow** is a self-authored, ephemeral multi-agent harness:
a small program an agent writes for one task, runs once, and discards. It
spawns subagents, gives each its own clean context window and model tier,
optionally isolates them in worktrees, and coordinates their results. The
capability and its patterns originate from Anthropic's "A harness for
every task: dynamic workflows in Claude Code" (Shihipar & Bidasaria,
2026); the runtime is triggered by the word `ultracode`.

This skill is **knowledge agents read, not a script they run** — a
sibling of [`harness-engineering`](../harness-engineering/SKILL.md) and
[`context-engineering`](../context-engineering/SKILL.md). It answers three
questions before any workflow is authored:

1. **When** is a workflow warranted? — see
   [`references/when-not-to-use.md`](references/when-not-to-use.md).
2. **Which** pattern fits? — see
   [`references/patterns.md`](references/patterns.md).
3. **How** does the plugin's governance constrain it? — see
   [`references/governance.md`](references/governance.md).

## Runtime scope — Claude Code only

Dynamic workflows are a **Claude Code runtime capability** and are **not
transferable** to GitHub Copilot CLI or any other coding agent — those
trees have no workflow runtime. This plugin ships to both the Claude Code
and Copilot CLI trees, so this skill is **knowledge everywhere, runtime
only on Claude Code**:

- **On Claude Code:** workflows can be authored and spawned; the patterns,
  election rubric, and templates are executable.
- **On Copilot CLI or any other agent:** there is no workflow runtime, so
  this skill is **guidance only** — the patterns and governance below are
  still worth reading, but no workflow can be spawned. An agent on such a
  tree must fall back to its existing static behaviour; it must never error
  or pretend to fan out.

Read the rest of this skill as a reasoning model that applies everywhere;
act on it as a runtime only where Claude Code provides one.

## Static harness vs. dynamic workflow

The plugin is, by default, a **static harness**: a fixed pipeline
(`spec-writer → GATE → tdd-agent → implementer → code-reviewer →
GUARDRAIL → integration-agent`) that must work for every task and
therefore tends toward the generic. A static harness is the right tool
for ordinary coding work, and it stays the default.

A dynamic workflow is the opposite: generated per task, disposable, and
able to hand each subagent a clean context window. That shape defeats
three failure modes the static pipeline is exposed to when one context
does too much:

| Failure mode | What it looks like |
| --- | --- |
| **Agentic laziness** | Declaring a multi-part job done after partial progress (35 of 50 constraints checked) |
| **Self-preferential bias** | An agent preferring its own output when asked to verify or judge it |
| **Goal drift** | Losing fidelity to the original objective across turns, worsened by lossy compaction |

Dynamic workflows are a **new execution substrate beneath the existing
agents** — they do not replace them, and they do not weaken governance.

## The six composable patterns

Authored workflows compose six patterns. Each is worked through with a
concrete micro-example in [`references/patterns.md`](references/patterns.md);
in brief:

- **classify-and-act** — route a task by type before doing it.
- **fan-out-and-synthesize** — split work across parallel subagents, then
  merge at a synthesis barrier.
- **adversarial verification** — a separate agent tries to refute a result
  before it is accepted.
- **generate-and-filter** — over-generate candidates, then prune.
- **tournament** — score independent attempts against a rubric, keep the
  winner.
- **loop-until-done** — iterate until a measurable completion test passes.

## Elect deliberately — the discipline

Workflows cost more tokens and suit complex, high-value tasks. Most
coding tasks do not need a panel of reviewers. Before authoring one, run
the four-question rubric in
[`references/when-not-to-use.md`](references/when-not-to-use.md): is the
task **long-running, massively parallel, highly structured, or
adversarial**? If none apply, use the static pipeline. A workflow should
be *elected*, never reflexive — over-orchestration is treated as a
regression.

Token budgets and model-tier routing for elected workflows live in the
project's `MODEL_ROUTING.md` (the *workflow election* section).

## The two governing invariants

Both are stated in full, for agents, in
[`references/governance.md`](references/governance.md):

- **INV-1 — Ephemeral proposes, durable curates.** A workflow is
  ephemeral; `HARNESS.md`, `AGENTS.md`, `CLAUDE.md`, and `MODEL_ROUTING.md`
  are durable and human-curated. A workflow may **propose** changes to
  them but may **never write them directly**. Discoveries flow through
  `REFLECTION_LOG.md → human curates → AGENTS.md`.
- **INV-2 — Quarantine.** Any workflow agent that reads untrusted or
  public content (web pages, external issues, third-party PRs) is withheld
  high-privilege tools. Acting on such information is done only by
  separate, trusted agents in the same workflow.

## The workflow template library

A library of opinionated, habitat-aligned workflow *templates* ships with
this skill under [`workflows/`](workflows/). They are **templates to adapt
per task, never scripts to run verbatim** — each carries a literate
preamble stating its pattern, its token budget and per-role model tiers,
and the INV-1 boundary it respects. Adapt the prompts, model tiers, and
budgets to your task, and confirm the runtime primitives against the live
[workflow documentation](https://code.claude.com/docs/en/workflows) before
running.

| Template | Pattern | Use it for |
| --- | --- | --- |
| [`workflows/enforcer-fanout.workflow.js`](workflows/enforcer-fanout.workflow.js) | fan-out-and-synthesize + adversarial verification | One verifier subagent per harness constraint, skeptic-filtered — defeats the "35 of 50 checked" lazy stop |
| [`workflows/adversarial-review.workflow.js`](workflows/adversarial-review.workflow.js) | adversarial verification | Review in a context distinct from the implementer's — one verifier per CUPID/literate property |
| [`workflows/reflection-mining.workflow.js`](workflows/reflection-mining.workflow.js) | generate-and-filter + adversarial verification | Cluster reflections, vet candidates, shortlist promotions for a human (never writes durable memory) |
| [`workflows/deep-assessment.workflow.js`](workflows/deep-assessment.workflow.js) | fan-out-and-synthesize + adversarial verification | Long repo scans (assessment/audit) — fan out by area, verify each finding, synthesise a cited report |

Every template honours both invariants: it proposes, it never writes a
durable artefact (INV-1), and any untrusted-content reader is quarantined
from high-privilege tools (INV-2). The deterministic firewall at the plugin
root (`ai-literacy-superpowers/scripts/inv-firewall.sh`) enforces both on
every template at PR time.

## references

```

```

## references/governance.md

# Governance for Dynamic Workflows

Dynamic workflows are a new execution substrate, but they do not get new
authority. Two invariants bind every workflow this plugin authors. They
are non-negotiable: every template, and every agent operating in workflow
mode, must preserve them. Both are restated here in full so an agent
reasoning about a workflow can cite them directly.

## INV-1 — Ephemeral proposes, durable curates

> Dynamic workflows are **ephemeral and generated**. The project's
> durable artefacts are **curated**. A workflow may **propose** changes to
> a durable artefact but may **never write one directly**.

The four durable, human-curated artefacts a workflow must never write are:

- **`HARNESS.md`** — the declared constraints, verification slots, and GC
  rules.
- **`AGENTS.md`** — the curated, compounding rules the team has chosen to
  keep.
- **`CLAUDE.md`** — the project conventions and instructions.
- **`MODEL_ROUTING.md`** — the model-tier and token-budget routing policy.

Anything a workflow discovers that is worth keeping flows through the
existing human-curation gate:

```text
REFLECTION_LOG.md  →  human curates  →  AGENTS.md
```

A workflow appends to `REFLECTION_LOG.md` (or to a dedicated staging
artefact) and surfaces a vetted shortlist; a **human** decides what is
promoted into the durable rule set. This is "agents propose; humans
curate" applied at the harness layer rather than the rule layer. It is the
load-bearing principle of the whole dynamic-workflows alignment: it
protects the team's curated theory of the system (Naur) from ephemeral
churn.

**Why it is load-bearing.** If an ephemeral, per-task program could
rewrite the durable artefacts, the curated theory of the system would
erode one disposable workflow at a time, with no human in the loop. The
firewall keeps the durable layer authoritative.

> The deterministic *teeth* for INV-1 — a CI rule that greps workflow
> templates for direct writes to these four paths and fails the build if
> it finds one — is mechanised in a later slice (S2). This file states the
> invariant as knowledge; the CI rule enforces it.

## INV-2 — Quarantine

> Any workflow agent that reads **untrusted or public content** — web
> pages, external issues, third-party PRs, arbitrary fetched text — must
> **not** be granted high-privilege actions.

A subagent that ingests untrusted input is a potential carrier for
injected instructions. Quarantine confines the blast radius: the agent
that *reads* untrusted content is withheld high-privilege tools (no
writes, no shell, no merge, no network mutation), and any action implied
by that content is performed only by a **separate, trusted agent** in the
same workflow that did not ingest the untrusted text. Reading and acting
are split across the trust boundary so a prompt-injection in fetched
content cannot reach into a privileged capability.

> As with INV-1, the lint that enforces INV-2 on templates (verifying an
> untrusted-content reader declares no high-privilege tools) lands with the
> template library in S2. This file states the invariant for agents to
> cite and design against now.

## How the invariants compose

A well-formed workflow that touches untrusted input *and* discovers
something worth keeping does both: the untrusted reader stays low-privilege
(INV-2), and whatever the workflow concludes is written only as a proposal
to `REFLECTION_LOG.md` or a staging file for a human to curate (INV-1) —
never straight into `HARNESS.md`, `AGENTS.md`, `CLAUDE.md`, or
`MODEL_ROUTING.md`.

## Runtime scope and the Copilot contract

Dynamic workflows are a **Claude Code** runtime capability. This plugin
**ships the `dynamic-workflows` skill to both trees** — Claude Code and
**Copilot** CLI — and the skill is **never omitted** on either. The
behaviour degrades by runtime, not by deletion:

- **On Claude Code:** the workflows execute; the patterns, election rubric,
  and templates are runnable.
- **On Copilot CLI (or any agent without the workflow runtime):** the skill
  is **guidance** only — readable knowledge — and every workflow-mode falls
  back to its existing static behaviour. It never errors and it is never
  omitted; the knowledge (patterns, election rubric, INV-1/INV-2) is worth
  reading even where no workflow can be spawned.

This is the resolved degradation contract (Option A): **ship to both
trees**, guidance-only where the runtime is absent.

## references/patterns.md

# Dynamic Workflow Patterns

The six composable patterns an authored workflow draws on. Each section
names the pattern and works it through a concrete, task-shaped
micro-example — the example is what makes the pattern usable by an agent
reasoning about a real task, not just a definition to recite. Real
workflows compose several of these.

The exact runtime functions for spawning and coordinating subagents are
**not** reproduced here — consult <https://code.claude.com/docs/en/workflows>
as authoritative before authoring a template.

## classify-and-act

**Shape.** Inspect the task, decide its *type*, then dispatch the branch
that fits. The default branch does the ordinary thing; special branches
exist only for the cases that benefit.

**Micro-example.** A request arrives at the orchestrator. A cheap
classifier agent reads it and labels it: *routine single-file edit* →
the existing static pipeline (no extra compute); *naming or design
question* → a `tournament`; *flaky test / incident* → root-cause
investigation. The routine label is the common case and costs nothing
beyond the classification step.

## fan-out-and-synthesize

**Shape.** Split a job into independent units, run one subagent per unit
in parallel (each with a clean context window), then wait at a
*synthesis barrier* until all return before reporting. The barrier is
what defeats agentic laziness — there is no "good enough, stop at 35 of
50" because the report cannot form until all N results are in.

**Micro-example.** Enforcing 24 HARNESS.md constraints. Instead of one
context checking all 24 (and tiring), the workflow spawns 24 verifier
subagents, one per constraint. Each returns pass/fail with evidence. The
synthesis step asserts it received exactly 24 results, then composes the
report. A missing result is a visible error, not a silent drop.

## adversarial verification

**Shape.** After a result is produced, a *separate* agent — in a context
window distinct from the producer's — tries to refute it against a
rubric. Only claims that survive the refutation are accepted. The
separation is what defeats self-preferential bias.

**Micro-example.** An implementation passes its tests. A reviewing agent
that never saw the implementer's reasoning is handed the diff plus the
CUPID + literate-programming rubric and asked, "find where this fails
each property." Each property gets a dedicated verifier; findings are
synthesised, not collapsed into a single thumbs-up.

## generate-and-filter

**Shape.** Deliberately over-produce candidates, then prune to the ones
worth keeping. Cheap breadth first, selective depth second.

**Micro-example.** Mining `REFLECTION_LOG.md` for rules worth promoting.
Parallel agents cluster the log and emit *every* candidate rule they can
justify (generate). A second adversarial pass asks of each, "would this
rule actually have prevented a real past mistake?" and drops the ones
that would not (filter). The survivors become a shortlist a human curates
— the workflow never writes the durable rule file itself (INV-1).

## tournament

**Shape.** Produce several independent attempts from different angles,
score each against a rubric with judge agents, and keep the winner (often
grafting the best ideas from the runners-up).

**Micro-example.** Naming a new public API. Three agents each propose a
naming scheme from a different stance — consistency-with-existing-code,
readability-for-newcomers, future-extensibility. A rubric-bearing judge
scores all three and selects, explaining the trade-off. Beats
one-attempt-iterated when the solution space is wide and taste-based.

## loop-until-done

**Shape.** Repeat a step until a measurable completion test passes (or a
budget is exhausted), rather than stopping after a fixed number of
rounds. For unknown-size discovery, keep going until K consecutive rounds
surface nothing new.

**Micro-example.** A deep repository assessment fans out by area and
accumulates findings; after each round a completeness critic asks "what
area has not been scanned, what claim is unverified?" The loop continues
until a round adds nothing, then synthesises the cited report. A simple
"run three times" would miss the tail.

> **Threshold note.** Some patterns switch on at a count threshold (for
> example, fan-out mode for the enforcer once the constraint count is high
> enough). The *value* of that threshold is a per-project decision made in
> the slice that owns it — this reference deliberately states only that a
> threshold exists, not its number.

## references/when-not-to-use.md

# When *Not* to Use a Dynamic Workflow

A dynamic workflow spends more tokens and more wall-clock than a single
agent. It earns that cost only on tasks that genuinely need it. Most
coding tasks do not. This is the compute-discipline rubric (D8): the
mechanism that makes every workflow *elected*, not reflexive.

## The four-question election rubric

Before authoring a workflow, ask whether the task is any of:

1. **Long-running** — would a single context drift or run out of room
   before finishing? (Long repo scans, multi-stage migrations.)
2. **Massively parallel** — does it split into many independent units that
   could be checked at once? (One verifier per constraint, one reader per
   area.)
3. **Highly structured** — does it have a clear pipeline of stages with
   defined hand-offs, where isolating each stage in its own context helps?
4. **Adversarial** — does it benefit from a separate agent trying to
   refute the result? (Review, judging, self-preference-prone checks.)

**The default: if none of the four apply, use the static pipeline.** A
task that is an ordinary single-file change, a small fix, or a quick
lookup does not warrant a panel of subagents. Reaching for a workflow
anyway is over-orchestration — treated as a regression, because the
static pipeline must remain the default for ordinary work.

## How to decline

When a task fails the rubric, an agent should say so plainly and proceed
on the static path — "none of the four discriminators apply; this is a
routine change, so I am using the static pipeline rather than a workflow"
— and cite this file. Declining is the correct, expected outcome for the
common case, not a failure to be apologised for.

## When it *does* apply

If one or more questions apply, the task is a workflow candidate. Pick the
matching pattern from [`patterns.md`](patterns.md), set a token budget and
model tiering per the *workflow election* section of the project's
`MODEL_ROUTING.md`, and honour the two invariants in
[`governance.md`](governance.md) — above all INV-1: the workflow proposes,
it never writes a durable artefact.

> **Threshold note.** Some patterns (for example, switching the enforcer
> into fan-out mode) turn on once a count crosses a threshold. That a
> threshold exists is part of the rubric; its *numeric value* is decided
> per project in the slice that owns the behaviour, and is deliberately
> not fixed here.

## What this rubric is *not*

This is **advisory guidance an agent reads**, not a CI gate. The plugin
does not deterministically enforce "a workflow was elected, not
reflexive" — there is no check that fails a build for skipping the rubric.
The discipline lives in the agent's reasoning and in human review, in
keeping with "agents propose; humans curate."

## workflows

```

```

## workflows/adversarial-review.workflow.js

```js

```

## workflows/deep-assessment.workflow.js

```js

```

## workflows/enforcer-fanout.workflow.js

```js

```

## workflows/package.json

```json
{
  "type": "module",
  "private": true,
  "description": "Marks the dynamic-workflows templates as ES modules so their `export const meta` + top-level await parse as the Claude Code workflow runtime expects. These are templates to adapt, not a runnable package — there are no dependencies and nothing is installed."
}
```

## workflows/reflection-mining.workflow.js

```js

```