Paste requirements and click Auto Workflow, choose a preset, or add nodes manually.
1 Select 2 Connect 3 Delete Alt+Drag Pan Scroll Zoom
/plan mode directly.claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp --scope usercurl -sSL https://coterm.datadoghq.com/mcp-cli/install.sh | bashdatadog_mcp_cli login and claude mcp add -s user datadog -- ~/.local/bin/datadog_mcp_cli --endpoint-path "/api/unstable/mcp-server/mcp?toolsets=core,alerting,apm"gh CLI (built-in). Bitbucket repos can use the same Atlassian MCP above. GitLab repos need glab CLI or a GitLab MCP.
Before planning, agents scan committed .workflow records and inherit the relevant decisions, gotchas, and surface area. The read side of the durable record; a no-op on greenfield work.
Agents save progress to disk so a long run survives context compaction. Ephemeral working state in ~/.claude, nothing is committed.
Also writes a committable spec + state document the agents maintain: a resumable handoff while work is in progress, an auditable artifact once it is done. Lives in your repo, versioned with the code.
Tip: use Handoff under Saved Workflows to export a resume package for another engineer.
Paste requirements and click Auto Workflow, choose a preset, or add nodes manually.
1 Select 2 Connect 3 Delete Alt+Drag Pan Scroll Zoom
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.
Three optional ways to sharpen a task - they solve different problems and can stack:
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.
Use this when your requirements are rough or incomplete and you want Claude to interview you before building.
Use this after you have solid requirements and want Claude to analyze your codebase before implementing.
For maximum quality, chain all three steps:
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.
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:
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.
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:
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.
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.
Two sidebar sections give agents the right context across one or many repositories:
.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:
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:
Agents know their place in the pipeline and produce output the next one can act on immediately - no copy-pasting between steps.
The first three are different ways Claude Code can run the same workflow - pick by how you want the work executed:
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.
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:
Click the Output node to set it. No preset defaults to Pull Request - commit/push/PR is always an explicit choice.
Two sidebar toggles control how a run persists its context:
~/.claude. Nothing is committed; it keeps a long run alive across compaction..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.
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.
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.
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).
These optional MCP servers and tools unlock better results from both workflows and prompt library prompts:
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.typescript-language-server, pyright, gopls). Gives agents go-to-definition and find-references for deeper code analysis.Some things the designer handles for you automatically:
swift-falcon), used for memory paths and file exports.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.