Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.
Dynamic Workflow Pattern
A reusable pattern for building a custom harness for a single task. Instead of running the task in the one default coding harness, Claude writes a small deterministic JavaScript program — a Claude Code Workflow — that spawns and coordinates subagents, each with its own clean context window, tuned to the task. Invoke it directly to decide whether a task warrants a workflow and to author one; it also serves as the sub-pattern library that /aep-gen-eval and /aep-executor read.
"Claude can now write its own harness on the fly, custom-built for the task at hand." — Thariq Shihipar & Sid Bidasaria, Anthropic, "A harness for every task: dynamic workflows in Claude Code"
Not `/aep-workflow-feedback`. That skill captures lessons about the AEP process; this one authors an orchestration script for a task.
When to reach for a workflow
The core judgment: a workflow trades significantly more tokens for isolated context windows + focused goals + a deterministic orchestrator instead of one long, drifting transcript. That trade is worth it — and only worth it — when a single context would go lazy, biased, or off-goal (the three failure modes it counters are tabulated in `references/pattern-catalog.md`). On the current generation a single context sustains a long story; duration alone is not a reason to split — adversarial verification and fan-out are.
Reach for a workflow when the task:
- spans many independent items — sort 1000+ rows, audit every claim, refactor
every callsite — where quality degrades if crammed into one prompt;
- needs adversarial verification by something other than its author (security
review, fact-check, eval);
- is taste-based and benefits from competing attempts (naming, design direction);
- needs routing of different inputs to different handling or model tiers.
Otherwise stay single-context: an ordinary coding task that fits one window, or a verification need a single /aep-gen-eval loop already covers, does not need a panel of agents. A workflow is a deliberate choice for one task, not a default wrapper around routine work.
Sub-patterns and their AEP touchpoints
Pick the shape that matches the task (they compose — a thorough review is fan-out → adversarial verify → loop-until-dry). Full intent, the primitive to use (parallel barrier vs pipeline no-barrier vs loop), skeletons, and architectural levers are in `references/pattern-catalog.md`.
| Sub-pattern | What it does | AEP touchpoint |
|---|---|---|
| Classify-and-route | A classifier agent decides task type / model tier, then routes. | /aep-dispatch routes by readiness_score and offers the "…with workflow" opt-in; a full classifier / model-tier router is the workflow generalization. |
| Fan-out-and-synthesize | Split into many small steps → one agent each → a barrier merges. | /aep-executor workflow mode runs one dispatched build wave this way (the narrow use); this skill is the general catalog + judgment. |
| Adversarial verification | For each output, a separate agent refutes it against a rubric. | /aep-gen-eval (generator/evaluator) is the canonical N=1 instance; a workflow generalizes it to N verifiers per finding. /aep-validate runs a fixed trio today — a workflow gives one per claim. |
| Generate-and-filter | Generate many candidates → dedupe → keep only rubric-passing ones. | Naming / design option generation before a calibration gate. |
| Tournament | N approaches compete; pairwise judging until a winner. | Taste-based decisions (naming, design direction) feeding a /aep-calibrate gate. |
| Loop-until-done | Keep spawning until a stop condition, not a fixed count. | /aep-autopilot's tick loop is the long-lived, OS-driven cousin. |
How to invoke
- Just ask. "Set up a workflow to…" / "Use a workflow to verify every claim…".
- `ultracode` keyword. Including
ultracodeforces Claude Code to author a
workflow for the request.
- Within AEP. "…with workflow" routes a dispatched build wave through
/aep-executor's workflow backend mode (one agent per locked story, hub-and-spoke gating) — see /aep-executor references (backends.md) → Mode: workflow.
Pair with other tools: /loop runs a repeatable workflow on an interval; /goal sets a hard completion requirement so it can't quit early (counters laziness); prompt with a token budget ("use 10k tokens") to cap spend; press s in the workflow menu to save to ~/.claude/workflows — treat a saved workflow as a template, not a script to run verbatim.
Standalone authoring
- Decide if it's worth it. Apply the sizing rule above. If one context window
suffices, stop here and just do the task.
- Pick a sub-pattern from the catalog (or compose several).
- Choose the primitive:
parallel(barrier — you need all results together),
pipeline (no barrier — items flow through stages independently, the default), or a loop (unknown amount of work).
- Add verification — a separate agent per finding when correctness matters;
default verifiers toward refuting, not rubber-stamping.
- Set guardrails — per-agent model tier, worktree isolation for parallel file
edits, a token budget, and (for triage of untrusted content) quarantine: agents that read untrusted public content must not take high-privilege actions.
- Author the script and launch it, then return the synthesized result to the
caller: a dispatched build wave to /aep-executor workflow mode; a verification / eval folded back into /aep-validate or /aep-gen-eval; standalone research / triage presented directly (pair with /loop if recurring).
Read `references/pattern-catalog.md` for skeletons.
Why this is a first-class pattern (not just /aep-executor's workflow mode, and why it sits beside /aep-gen-eval rather than inside it): rationale in `docs/decisions/workflow-rationale.md`.
