7.1 Dynamic Workflows

Dynamic Workflows for Designers

A Dynamic Workflow is useful when the design task has a repeatable shape: inspect, compare, verify, synthesize, and return something a team can act on.

A Dynamic Workflow is Claude Code moving the plan out of the chat and into a script.

In a normal Claude Code session, Claude decides what to do next turn by turn. It reads files, edits code, runs checks, and brings the results back into the conversation. That is useful when you want to steer the work live.

In a Dynamic Workflow, Claude writes a JavaScript orchestration script for the task. A separate workflow runtime executes that script in the background. The script decides which agents run, what each agent investigates, how results are grouped, what gets verified, and what final answer comes back to you.

For designers, the simplest mental model is this:

A subagent is like asking one specialist to help. A Dynamic Workflow is like giving a production checklist to an entire temporary design team, then asking them to return only the reviewed result.

The important part is not only scale. The important part is where the plan lives. With subagents, the plan lives in Claude's conversation. With workflows, the plan lives in code. That makes the workflow repeatable, inspectable, resumable inside the same session, and much better suited to design audits, research sweeps, large migrations, and review pipelines.

Why This Matters for Design Work

Most design work is not a single prompt. It is a loop:

1. Understand the existing context.
2. Compare options.
3. Generate an artifact.
4. Review it against brand, usability, accessibility, and implementation constraints.
5. Fix what failed.
6. Produce a clean handoff.

Claude Code can already do that in a normal session. The limitation is that every intermediate result competes for the same context window. If ten agents inspect ten parts of a design system, all ten reports come back into the conversation. That can get noisy fast.

Dynamic Workflows change the operating model. The workflow script can fan out work across many subagents, keep intermediate findings in script variables, cross-check the results, filter weak claims, and return a final report. The designer sees the synthesized output instead of every scratch note.

That makes workflows especially useful when the task is:

• too broad for one conversation to coordinate cleanly;
• repeatable enough to save as a command;
• risky enough to need independent verification;
• large enough that many files, screens, or components need checking;
• structured enough that you can describe the phases before the run begins.

It is less useful when you want live creative back-and-forth. If you are exploring a hero layout and want to make subjective decisions every few minutes, stay in a normal Claude Code session. Workflows do not support mid-run user input except permission prompts. Use them when the process can run as a pipeline.

What Claude Code Gives You

As of June 2026, Dynamic Workflows are in research preview and require Claude Code v2.1.154 or later. They are available across paid Claude Code access paths, with provider availability depending on plan and environment.

You can use them in three main ways:

1. Run the bundled deep research workflow:

/deep-research What are the strongest current patterns for AI-assisted design QA?

2. Use the trigger word ultracode in your prompt to explicitly start a dynamic workflow:

Use ultracode to audit every component in this design system for token drift, accessibility gaps, and inconsistent responsive behavior.

3. Describe the task naturally and let Claude decide when a workflow is appropriate:

Run a design system audit across all 120 components. Check tokens, accessibility, and responsive behavior. Return a prioritized report.

The trigger word changed in late May 2026. Previously, including the word workflow in your prompt would activate a dynamic workflow. That caused false triggers: you might say "this is a good workflow" in conversation and accidentally launch one. The trigger word is now ultracode. You can still say "use a workflow for this" in natural language and Claude will understand your intent, but only ultracode guarantees a workflow fires. If you say "workflow" without meaning to, nothing happens.

For most designers, the second option (explicit ultracode trigger) is the best starting point when you know you want a workflow. The third option (natural language) works when you are unsure and want Claude to decide.

You manage workflow runs with:

/workflows

That view shows running and completed workflows, phases, agent counts, token usage, elapsed time, and individual agent results. A successful workflow can be saved as a reusable slash command. Project workflows live in:

.claude/workflows/

Personal workflows live in:

~/.claude/workflows/

For a design team, the project folder is the important one. It lets the team share the same audit or review workflow across a repository.

Subagents, Skills, and Workflows

Designers will encounter all three terms. They solve different problems.

Use a skill when Claude needs to know how your design system works.

Use subagents when you need a few independent helpers in a live session.

Use a Dynamic Workflow when the whole process should be codified: fan out, inspect, verify, synthesize, and return a final answer.

Design Example: The Component Library Audit Workflow

Imagine you maintain a design system with 120 React components. Designers complain that the shipped components no longer match Figma. Engineers say the tokens are correct. Product managers see inconsistent UI in production.

This is a poor fit for a single chat turn. Claude would need to inspect many files, compare token usage, check accessibility, summarize exceptions, and avoid drowning you in raw findings.

This is a good Dynamic Workflow.

Prompt

Use ultracode to audit the component library under src/components against our design system rules.

Use CLAUDE.md, DESIGN.md, tokens.css, and the Storybook stories as source material.

Phases:
1. Inventory all components and group them by category.
2. Check token usage: color, typography, spacing, radius, shadows, and motion.
3. Check accessibility: keyboard behavior, labels, contrast, focus states, and semantic HTML.
4. Check responsive behavior in component stories where viewport variants exist.
5. Have a separate verifier agent review each high-severity finding.
6. Return a prioritized report with exact file paths, issue type, severity, evidence, and suggested fix.

Do not edit files. This is an audit only.

What the Workflow Does

Phase 1 creates the map. It identifies every component, story, token file, and documentation file.

Phase 2 fans out token checks. One group of agents checks colors. Another checks typography. Another checks spacing and radius. Another checks motion and transitions.

Phase 3 fans out accessibility checks. Agents inspect focus handling, labels, ARIA usage, keyboard paths, and contrast.

Phase 4 checks responsive behavior. Agents compare mobile, tablet, and desktop stories where available.

Phase 5 verifies findings. This is the important part. A workflow can force one agent's finding to be checked by another agent before it reaches the designer. That reduces false positives.

Phase 6 returns only the useful result: a ranked report.

Output Shape

# Component Library Audit

## Summary
- 120 components scanned.
- 18 confirmed issues.
- 6 high severity, 9 medium, 3 low.
- 11 suspected issues rejected by verifier agents.

## High Severity

### Button: focus ring invisible on dark backgrounds
- File: src/components/Button.tsx
- Evidence: focus state uses --color-focus-default, which has insufficient contrast against --color-surface-inverse.
- Verification: confirmed by independent accessibility verifier.
- Suggested fix: map inverse surfaces to --color-focus-inverse.

### Modal: escape key behavior inconsistent
- File: src/components/Modal.tsx
- Evidence: escape closes simple modal but not confirmation modal.
- Verification: confirmed in story interaction tests.
- Suggested fix: standardize close handler and document exception for destructive confirmation flows.

For a design system team, this is a better artifact than a chat transcript. It is closer to a design QA report.

Example Reusable Workflows for Design Teams

1. Design System Drift Audit

Purpose: Find where code has drifted away from the design system.

Best for: mature product teams with a component library, CSS variables, Tailwind config, or design token package.

Prompt:

Create and run a workflow called design-system-drift-audit.

Audit this repository for drift from our design system. Read CLAUDE.md, DESIGN.md, tokens, theme files, component stories, and production components.

Phases:
1. Build an inventory of tokens and components.
2. Find hard-coded colors, spacing, font sizes, shadows, radii, and z-index values.
3. Compare component variants against documented component rules.
4. Verify every drift finding with a second agent.
5. Rank issues by user-visible impact and migration effort.

Return a report with file paths, issue category, evidence, recommended token replacement, and confidence.
Do not make changes.

What makes it dynamic: the workflow adapts to the repository inventory. It does not need you to list every component manually. It discovers the system, fans out checks, then verifies findings.

Book angle: This belongs in a section about design systems at scale. It shows the designer moving from one-off prompting to an operational quality gate.

2. Competitive UX Research Workflow

Purpose: Research competing products and convert findings into design opportunities.

Best for: product designers planning a redesign, onboarding flow, pricing page, dashboard, or conversion funnel.

Prompt:

Use ultracode to research competitor onboarding patterns for B2B analytics tools.

Research five current competitors. For each one, gather evidence from public pages, docs, screenshots, changelogs, and credible reviews.

Phases:
1. Identify competitors and source types.
2. Extract onboarding patterns: signup, activation, empty states, template selection, data import, collaboration invite, and upgrade prompts.
3. Cross-check claims against at least two sources where possible.
4. Convert verified patterns into design opportunities for our product.
5. Return a cited research brief with confirmed patterns, weak signals, and recommendations.

What makes it dynamic: the workflow can split research by competitor, then synthesize by pattern. It can reject claims that only appear in one weak source.

Book angle: This is not "Claude browses the web." It is a research desk with source checking. That makes it appropriate for design strategy, not just UI production.

3. Multi-Screen Prototype Critique Workflow

Purpose: Critique a prototype across information architecture, visual hierarchy, interaction quality, accessibility, and implementation feasibility.

Best for: designers preparing a prototype review before showing stakeholders.

Prompt:

Use ultracode to critique the prototype in prototypes/new-dashboard.

Use these review lenses:
1. Information architecture and task flow.
2. Visual hierarchy and spacing.
3. Interaction states and empty/error/loading states.
4. Accessibility and keyboard usability.
5. Engineering feasibility and component reuse.

Assign independent agents to each lens. Then have a synthesis agent merge findings into:
- top 5 issues to fix before stakeholder review;
- top 5 strengths to preserve;
- unclear decisions that need human judgment;
- recommended next iteration plan.

Do not edit files.

What makes it dynamic: each lens runs independently, then the workflow merges them. This avoids one generic critique that misses the details.

Book angle: This fits the design review chapter. It teaches designers to turn critique into a repeatable operating model.

4. Figma-to-Code Migration Planning Workflow

Purpose: Plan a migration from design files or static mockups into production components.

Best for: teams moving a legacy design system into code, or replacing static handoff with component-driven design.

Prompt:

Use ultracode to plan a Figma-to-code migration for the checkout redesign.

Inputs:
- Existing Figma export in design/checkout-export
- Current React components in src/components
- Design tokens in packages/tokens
- Product requirements in docs/checkout-redesign.md

Phases:
1. Inventory screens, components, states, and repeated patterns.
2. Match Figma elements to existing production components.
3. Identify missing components or variants.
4. Estimate migration sequence by dependency and risk.
5. Verify the plan against accessibility and responsive requirements.
6. Return a migration plan with milestones, component gaps, risks, and first implementation slice.

Do not implement. Planning only.

What makes it dynamic: the workflow can compare multiple sources, split the mapping work screen by screen, and produce a plan that accounts for component dependencies.

Book angle: This belongs in design-to-production. It reframes migration as structured analysis before code generation.

5. Visual QA Release Gate Workflow

Purpose: Run a pre-release design QA sweep before a product launch.

Best for: landing pages, onboarding flows, dashboards, product launches, and marketing sites.

Prompt:

Use ultracode as a visual QA release gate for the pages under app/(marketing).

Phases:
1. Inventory user-facing pages and key responsive breakpoints.
2. Run or inspect available screenshots, tests, Storybook stories, and Playwright results.
3. Check layout stability, text overflow, spacing consistency, image loading, dark/light mode behavior, accessibility, and brand token usage.
4. Have verifier agents confirm high-severity issues.
5. Return a launch readiness report: blockers, important fixes, acceptable risks, and recommended follow-up tasks.

Only edit files if I explicitly approve after the report.

What makes it dynamic: release QA has many small checks. A workflow can parallelize them, keep noise out of the main context, and return a launch-focused decision artifact.

Book angle: This is the bridge between design quality and shipping discipline.

Use Case 1: Design System Governance

Dynamic Workflows can become a recurring governance mechanism. Instead of asking Claude once to "check the buttons," the team saves a workflow that checks token usage, component variants, accessibility states, responsive behavior, and documentation drift every time the design system changes.

Designer value: fewer regressions and less manual inspection.

Best output: a ranked design system drift report.

When to run it: before merging component library changes, before quarterly design system reviews, or after major token updates.

Use Case 2: Evidence-Based Design Research

Design research often suffers from weak evidence. A workflow can split research across sources, compare claims, and return only findings that survive verification.

Designer value: stronger research briefs with fewer hallucinated claims.

Best output: a cited competitor or pattern research report.

When to run it: before redesigning onboarding, pricing, search, dashboards, account setup, or any flow with mature competitors.

Use Case 3: Prototype Review from Multiple Lenses

A single critique often overweights one perspective. A workflow can assign separate agents to UX flow, visual hierarchy, accessibility, engineering feasibility, and brand consistency, then merge the results.

Designer value: more balanced critique before stakeholder review.

Best output: top fixes, strengths to preserve, and a prioritized iteration plan.

When to run it: before presenting a prototype, before handing work to engineering, or after generating a first-pass AI prototype.

Use Case 4: Large-Scale UI Migration

When moving static designs into production code, the hard part is not generating one component. The hard part is mapping screens, states, existing components, missing variants, dependencies, and risks.

Designer value: a migration plan that avoids rebuilding everything blindly.

Best output: component mapping, missing variant list, implementation slices, and risk register.

When to run it: during redesigns, design system adoption, framework upgrades, or Figma-to-code transitions.

Use Case 5: Launch-Ready Visual QA

A launch surface can fail in small ways: text overflows, focus states disappear, a mobile breakpoint collapses, a marketing image fails, or a component uses a stale color token. A workflow can check these systematically.

Designer value: a repeatable release gate that protects visual quality.

Best output: launch readiness report with blockers, important fixes, and acceptable risks.

When to run it: before publishing a landing page, product dashboard, onboarding flow, documentation site, or campaign page.

Practical Rules for Designers

Use a Dynamic Workflow when:

• the task has clear phases;
• the same process will be repeated;
• many files, pages, components, or sources need checking;
• independent verification matters;
• the output should be a report, plan, or prioritized backlog.

Do not use a Dynamic Workflow when:

• you need live creative conversation;
• the task is small enough for one Claude turn;
• you are still deciding the direction;
• you cannot afford the token cost;
• you need approval between every stage.

Start small. Run one workflow as an audit before letting workflows edit files. Once the report shape is useful, save it as a reusable command.

Cost and Safety Notes

Dynamic Workflows can be expensive because they spawn many agents. Each agent uses the session model unless the workflow routes a stage to a different model. Before a large run, check:

/model

For design tasks, ask Claude to use cheaper models for broad inventory work and stronger models for synthesis or final judgment:

Use a smaller model for inventory and extraction phases. Use the strongest model only for final synthesis and high-severity verification.

Also remember:

• workflow scripts do not directly read files or run shell commands; the agents do that work;
• workflow agents inherit your tool allowlist;
• file edits inside workflow agents are auto-approved;
• shell, web, and MCP calls outside the allowlist can still prompt;
• stopping a workflow does not necessarily lose completed work inside the same session;
• resuming works inside the same Claude Code session, not after exiting and starting fresh.

For designers, the safest default is audit first, edit second.

My Take

Dynamic Workflows are not just "more subagents." They are a different contract. A subagent helps you in the current conversation. A workflow turns a process into a repeatable machine.

That matters for design because the hardest design work is often not producing the first artifact. It is checking the artifact from enough angles that you trust it: brand, layout, accessibility, responsiveness, implementation, and user flow. A workflow can encode that review pattern so you do not have to remember it every time.

The tradeoff is cost and flexibility. If you are sketching direction, stay conversational. If you are auditing a design system, preparing a launch, or researching a market, use a workflow.