100%
🏗

Paste requirements and click Auto Workflow, choose a preset, or add nodes manually.

1 Select   2 Connect   3 Delete   Alt+Drag Pan   Scroll Zoom

Add nodes and connections to see your workflow output here...
Duplicate
Disconnect All
Delete
Copied to clipboard!

Workflow Designer Help

Getting Started

Quick Start

  1. Paste requirements into the Requirements field (or a Jira ticket URL)
  2. Click Auto Workflow to auto-build a workflow from keywords, or pick a Preset below
  3. Customize nodes by clicking them: change agent types, models, prompts, and tools
  4. Pick an export format tab at the bottom, then Copy the prompt into Claude Code

Auto Workflow stays disabled until you've pasted enough prose to auto-pick a workflow - roughly a sentence (at least 6 words once any URL or ticket key is set aside). A bare Jira key (like PROJ-42) prompts you to paste the full URL; a ticket URL on its own opens a workflow-type picker. Generate Refine Prompt is available as soon as the box isn't empty, and Generate Plan Prompt isn't gated by the input validator (it checks itself at click time), so you can refine or plan before Auto Workflow lights up.

Sharpen the Task

Which prep step should I use?

Three optional ways to sharpen a task - they solve different problems and can stack:

  • Generate Refine Prompt - when the requirements themselves are rough. Claude interviews you about edge cases, UX, and tradeoffs, then writes a refined spec you paste back into Requirements. Sharpens the what.
  • Generate Plan Prompt - when the requirements are solid but you want a codebase-aware approach. Claude explores your code and writes an implementation plan you paste into Workflow Context. Sharpens the how.
  • Clarify requirements first (toggle) - the same kind of clarification as Refine, but built into the workflow's planning step instead of a separate up-front prompt. It asks one focused round of questions at runtime and folds the answers into the plan and the durable record. Best when you want a single self-contained prompt rather than a multi-step prep flow.

For maximum quality on a big task, stack them: Refine to lock the spec, Plan to ground the approach, then build. For a lighter touch, just flip on Clarify. The three flow diagrams below walk through each step by step.

Generate Refine Prompt Flow

Use this when your requirements are rough or incomplete and you want Claude to interview you before building.

Paste requirements → click Generate Refine Prompt → copy into Claude Code → Claude asks clarifying questions via interview → writes refined spec to .claude/specs/ → paste refined spec back into Requirements → Auto Workflow or pick preset

Generate Plan Prompt Flow

Use this after you have solid requirements and want Claude to analyze your codebase before implementing.

Requirements ready → click Generate Plan Prompt → copy into Claude Code → Claude explores your codebase (files, patterns, architecture) → writes implementation plan to .claude/plans/ → paste plan into Workflow Context field → plan context is included in all exported prompts

Full Flow (Power Users)

For maximum quality, chain all three steps:

1. Paste rough requirements → Generate Refine Prompt → interview → refined spec 2. Paste refined spec → Generate Plan Prompt → codebase analysis → implementation plan 3. Paste plan → build workflow → Copy prompt → execute in Claude Code

Clarify Requirements First

The Clarify requirements first toggle (off by default) adds an in-flow clarification gate to the planning step - distinct from the Generate Refine Prompt step (see Which prep step should I use? above for how they differ). When on, the planning step probes the requirements for material ambiguity, asks you a focused set of questions in one round, then folds the answers into the plan and the durable record. It degrades gracefully when run non-interactively (CI or an SDK pipeline): it records the open questions as assumptions and risks and proceeds rather than blocking.

Build the Workflow

Editing Agent Prompts

Clicking a node exposes an editable Agent Prompt pre-filled with that agent type's role template, so you can tune the instructions instead of starting from a blank box. A status line tells you which state you're in:

  • Using the role template - the prompt still matches the agent type's default.
  • Full template attached - the complete template is in place.
  • Edited from the {Role} template - once you change it, the status shows you've diverged from the pristine default.

A Reset control restores the pristine template (and the reset is undoable). Agent Context is a separate field: its contents are appended to the agent's prompt, not a replacement for it. Use the Agent Prompt to shape the role, and Agent Context to layer on extra constraints or implementation details.

Review Loops (Skeptic & Verifier)

Right-click any Agent or Task node and pick Add skeptic review or Add verification to wrap a review-and-revise loop around that step in one undoable action:

  • Skeptic tries to refute the work by inspection - a role-aware adversarial critic that only sends work back for material Critical/High defects, never nitpicks.
  • Verifier proves the outcome meets the objective with evidence - it runs the code, calls the API, or drives a browser instead of just reading it.

When to use which. Reach for a Skeptic on high-stakes or expensive-to-undo steps where a confident-but-wrong output is costly: the plan (a wrong direction is the most expensive mistake to make), security-sensitive code, or anything subtle. Reach for a Verifier on any step with a runnable outcome - a built feature, an API integration, a UI, a data migration - placed late, right before delivery.

Why they're powerful. They are complementary: the Skeptic catches what reasoning can see (logic, design, security), the Verifier catches what only execution reveals (it reads fine - but does it actually run?). Together they give defense in depth - doubt early, prove late - which is exactly how a careful senior engineer works. One click drops in the whole reviewer + Decision gate + back-edge that routes failures back to the step to fix, with a bounded revision count so it retries and then stops rather than spinning. It reuses the same loop machinery the presets use, so it renders correctly in every export format. Right-click again to Remove it, or use the Decision node's send-back target dropdown to re-point the failure branch to a different node. The Delivery Swarm preset shows both in one flow.

Canvas Tips

  • Ctrl+Z / Cmd+Z: Undo (also available as toolbar buttons)
  • Ctrl+Shift+Z / Cmd+Shift+Z: Redo
  • 1 2 3: Switch between Select, Connect, and Delete modes
  • Delete / Backspace: Delete selected node or connection
  • Alt+Drag: Pan the canvas
  • Scroll: Zoom in/out
  • Right-click a node for its context menu: add a Skeptic review or Verification loop, duplicate, disconnect, or delete
  • Auto Layout re-arranges nodes using the Sugiyama layered algorithm
  • Fit zooms to show all nodes
  • Quick Patterns in the palette (Fork 2/3/4, Fan-Out) scaffold a parallel agent group in one click
  • You are not limited to presets - add any nodes from the palette and wire them up however you like; the generators handle the scaffolding

Toolbar Features

  • Undo / Redo buttons (or keyboard shortcuts) let you reverse adding, deleting, connecting, disconnecting, and dragging nodes. 50-step history.
  • Validation indicator shows a green check or amber warning count. Click it to see issues like disconnected nodes, empty prompts, or incomplete decision gates.
  • Token estimate appears next to the Copy button showing the approximate size of the generated prompt.
  • Clone button in Saved Workflows duplicates the current workflow under a new name for creating variants.

Give Agents Context

Jira Integration

Paste a full Jira URL (not just the ticket key) - bare or inline in your requirements - and enable Atlassian MCP in the sidebar. The exported prompts instruct the orchestrator to resolve the ticket up front and read it thoroughly - its acceptance criteria, comments, and attachments - and to follow any helpful links in the ticket or requirements (designs, docs, related pages). The orchestrator (which builds the plan) and every step keep the agency to pull wider context (the parent epic, sub-tasks, linked issues, Confluence) when it would genuinely help, but never as a requirement. This is automatic and content-driven (no dropdown needed). For URL-only input, you'll be asked to pick a workflow preset since there aren't enough keywords to auto-generate.

Multiple Repos & Rules Files

Two sidebar sections give agents the right context across one or many repositories:

  • Repositories - list each repo with its branch; the prompts tell agents to check out the right branch and pull before starting.
  • Repo Context Paths - point agents at a repo's own rules and product docs so they honor more than the per-task spec. Rules / constitution paths (e.g. .claude/rules, CONVENTIONS.md) are binding constraints on how to build; Product docs (e.g. docs/, ADRs) are goals the work must not contradict. The lists are sticky - they persist across workflows in the same repo.

Multi-repo rules - handled for you. On its own, Claude Code only auto-loads CLAUDE.md and .claude/rules/ for the repo the session launched in, so it would miss the others. The generated multi-repo prompt closes that gap: it tells each agent to read every in-scope repo's own CLAUDE.md and .claude/rules/ before changing it, and any Rule Paths you list (e.g. .claude/rules) are resolved within each repo and scoped to it. So with three repos selected and .claude/rules listed once, each repo's own rules are honored for changes made in that repo - no per-repo entry needed, and no environment variable required.

The setup below is an optional reliability boost - it makes Claude Code also auto-load each added repo's CLAUDE.md at startup - but the prompt's explicit per-repo read works no matter how the session was launched:

CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../repo-b ../repo-c

Export & Delivery

How the Prompts Work

Whatever format you export, every agent's section is workflow-aware - it carries everything that agent needs to act, with no manual glue between steps:

  • Role & methodology - what the agent owns, as numbered steps with clear deliverables
  • Tool awareness - which tools it should reach for
  • Dependencies - the upstream output it consumes and the downstream consumers it must satisfy
  • Success gates - the next decision's criteria baked into the agent's own prompt, so it self-checks before handing off
  • Full requirements - the complete story/ticket, never truncated
  • Memory read/write (when enabled) - recover from compaction at the start, persist progress and a handoff at the end

Agents know their place in the pipeline and produce output the next one can act on immediately - no copy-pasting between steps.

Export Formats

The first three are different ways Claude Code can run the same workflow - pick by how you want the work executed:

  • Workflow: one orchestration prompt that Claude Code runs in a single session - it adopts each role in turn and works through the steps in order (launching parallel Task calls only where marked). Simplest, and best for most cases.
  • Sub-Agents: each step is delegated to its own sub-agent via the Task tool, in sequence (parallel steps launched concurrently). Every agent gets a fresh, isolated context - better for long or context-heavy workflows where you don't want one window holding everything.
  • Agent Teams: agents run concurrently as a team and coordinate through a shared handoff file, instead of one orchestrator driving them in turn. Best for genuinely parallel work. Preview.
  • Agent SDK: Python using the Anthropic Agent SDK - wire the workflow into your own pipeline or automation.
  • Claude.ai: a simplified conversational prompt for Claude.ai, with no CLI tools.

Rule of thumb: start with Workflow; switch to Sub-Agents when context size or step isolation matters; reach for Agent Teams when steps are truly independent and benefit from running at the same time. The hint bar above the prompt nudges you toward Agent Teams when your workflow has parallel agents with several steps each.

Delivery (Output node format)

Agents make code changes whether or not you add an Output node; the node's Format decides what happens to the work at the end:

  • Leave Uncommitted (default) - make the changes, commit nothing. Same as having no Output node.
  • Commit - feature branch, commit + push, no PR.
  • Pull Request - feature branch, commit + push, open a PR (git provider auto-detected: GitHub, Bitbucket, GitLab).
  • Report - produce a written report; leave any code uncommitted.
  • Documentation - produce docs in the project's conventions; leave any code uncommitted.

Click the Output node to set it. No preset defaults to Pull Request - commit/push/PR is always an explicit choice.

Memory, Records & Handoff

Durable Record

Two sidebar toggles control how a run persists its context:

  • Enable workflow memory - ephemeral agent scratch state under ~/.claude. Nothing is committed; it keeps a long run alive across compaction.
  • Keep a durable record - a committable spec + state document. It is a strict superset that builds on memory, written to .workflow/{slug}.md in your repo so it versions with the code.

The orchestrator (the top-level agent driving the workflow and spawning its steps) owns the record: it creates it at kickoff, folds in each step's findings as the run proceeds, and finalizes it for commit - compressing the running per-agent commentary into a clean spec without dropping the why or the decisions.

A breadcrumb index at .workflow/_index.md keeps one entry per record, grouped by capability. It is scanned first (scan-then-open) so future work reads only the relevant records instead of all of them. Supersession lineage keeps history one hop away: a re-worked capability leaves the old record marked superseded with the new one linked, so the index always points at current behavior.

Ground in Prior Records

The Ground in prior records toggle (on by default) is the read side. Before planning, the orchestrator scans .workflow/_index.md if it exists, opens only the records relevant to the files and capability the change touches (preferring current ones), and folds their decisions and gotchas into the plan. It is self-gating - a no-op on greenfield repos with no records yet. Producing a record is opt-in; benefiting from existing ones is automatic.

Together, Keep a durable record (the write side) and Ground in prior records (the read side) form a flywheel: every run leaves behind its decisions, gotchas, and a tested spec, and the next run reads them before planning - so workflows in the same repo get sharper and stop repeating the same mistakes over time, with nobody curating anything by hand. The more you run, the better-grounded each new workflow starts.

Handoff

The Handoff button under Saved Workflows downloads a single resume package (.md) so another engineer can pick up in-progress work: how to resume, the durable-record path, the ready-to-run prompt, and the full workflow definition. The live run state travels with your git branch and the durable record, not this file - so enable Keep a durable record before running for a truly resumable handoff.

More

Prompt Library

Click the Prompts button in the toolbar for a library of ready-to-use prompts. Use the search box to filter by title or description. Star your favorites and they float to the top. Prompts that need your input (like a file path or bug description) show a popup before copying so the prompt is ready to paste.

Prompts that benefit from cross-repo search or Jira/Confluence context include guidance for using those tools when available.

The Live Monitors category contains prompts that watch things for you over time: CI builds, PR reviews, deploys, incidents. They run on a recurring interval, track changes across iterations, and self-terminate when done (build goes green, PR merges, service recovers).

Recommended Integrations

These optional MCP servers and tools unlock better results from both workflows and prompt library prompts:

  • Atlassian MCP: built into Claude Code. Lets agents fetch Jira tickets and Confluence pages at runtime. Toggle on/off in the sidebar.
  • Claude in Chrome: the Claude browser extension. Lets agents drive a real Chrome tab - open a PR and read its diff, navigate your running app, and confirm a UI actually renders and behaves as specified. Powers the Verifier's browser checks and the PR-review and UI prompts in the library.
  • Code search MCP: any cross-repo code-search server (for example Sourcebot, Sourcegraph, or Kilo Code). Typically exposes tools to discover repos, browse trees, search code, and read files across all your repositories. None is required; toggle the hint on/off in the sidebar.
  • Datadog MCP: install with curl -sSL https://coterm.datadoghq.com/mcp-cli/install.sh | bash, then datadog_mcp_cli login, then claude mcp add -s user datadog. Enables the Observability prompts in the Prompt Library. Bug Fix workflows also use it automatically to check production logs and error context during investigation. Toggle it on in the sidebar to add a production-telemetry grounding hint to exported workflows.
  • LSP: install a language server for your stack (e.g. typescript-language-server, pyright, gopls). Gives agents go-to-definition and find-references for deeper code analysis.

Under the Hood

Some things the designer handles for you automatically:

  • Smart workflow detection - Auto Workflow scores your requirements across 13 intent categories to build a bespoke shape: build, research (read-only spike), review (read-only audit), or analysis (measure / forecast cost). It tolerates plurals and verb forms, and defaults to building when intent is ambiguous - a read-only shape (research / review / analysis / docs / tests) is chosen only when the task asks to produce a read-only deliverable, so a build whose acceptance criteria are thick with "tests pass" language still gets an implementer. It wraps a Skeptic on the plan and a Verifier on complex builds, and tells you what it detected so you can rephrase or pick a preset.
  • Acceptance-criteria extraction - bullet or numbered criteria in your requirements become Decision-gate conditions downstream.
  • Secret scanner - every input is checked for API keys, credentials, and connection strings before anything is copied to your clipboard.
  • Input validation - catches bare Jira keys, URL-only input without Atlassian MCP, and too few keywords to generate from.
  • Auto-naming - leave the name blank and you get a stable two-part name (e.g. swift-falcon), used for memory paths and file exports.
  • Preset-aware placeholders - picking a preset retargets the Requirements box with a template for that workflow type.

Power User Tips

  • Enable workflow memory for long runs that need to survive compaction, and Keep a durable record when you want a committable handoff - see the Durable Record section above
  • Add Repository paths to scope agents to specific codebases
  • Use Decision nodes with revision loops to add quality gates (review / revise cycles)
  • Parallel groups run agents concurrently, great for independent tasks like "backend + frontend"
  • Node settings shape the prompt: a Task node's description and acceptance criteria become a Tasks section (an empty Task stays out of the prompt); a Parallel fork's Strategy sets the join (Wait for All / First Complete / Race); an Input node's Source can frame the text as a User Story or PRD. These emit only when you pick a non-default, so presets stay byte-identical
  • Each agent's Agent Context field lets you add context that's included in that agent's prompt section
  • Workflows auto-save to localStorage. Use Save / Load for named snapshots, or Export JSON to share with teammates
  • Right-click an Agent or Task node to wrap a Skeptic (refutes by inspection) or Verifier (proves it runs) review loop around it - see Review Loops above
  • An Output node's Format is the single delivery control (uncommitted / commit / PR / report / docs) - see Delivery above
  • The Delivery Swarm preset is the showcase to adapt: parallel discovery and build with a Skeptic on the plan and a Verifier on the integration

Want the full picture? The README on GitHub covers the design philosophy, every preset and node type, the memory protocol, and the rest of what is under the hood.

Prompt Library