Atomic’s built-in coding agent workflow examples

Compare selected workflows built into Atomic by use case, control flow, and review gates. This guide covers the goal and ralph implementation loops, the open-claude-design design workflow, and six reusable control-flow patterns. Agent count is not the important difference. Each workflow gathers evidence, makes continuation decisions, and returns control differently.

Three detailed workflows at a glance

Atomic exposes its built-ins through one workflow registry and does not assign product categories. This comparison groups three workflows by practical engineering job.

Six reusable pattern workflows

Use these bundled patterns when a focused control shape fits better than a complete end-to-end engineering loop:

• classify-and-act classifies a task and routes it to a category-specific action, with human selection when confidence is low.
• fan-out-and-synthesize runs bounded independent artifact branches, then synthesizes their evidence at an explicit barrier.
• adversarial-verification challenges a candidate with fresh-context, rubric-based verifiers and reduces their evidence through a bounded repair loop.
• generate-and-filter generates independent candidates, deduplicates and filters them by rubric, optionally judges them, and returns a shortlist.
• tournament compares whole-task attempts through pairwise bracket judging and returns an auditable winner.
• loop-until-done repeats evidence-producing work and independent evaluation against a durable ledger until completion or an inspectable iteration-limit failure.

Atomic source evidence: built-in workflow guide · bundled manifest

goal: ledger-based work against a concrete contract

Use it when: you can delegate a crisp objective with known acceptance criteria and want bounded autonomous attempts, durable receipts, and reviewer-gated completion. Choose it for the ledger and compact orchestrator-turn structure—not only because a task is large.

How it runs

1. The workflow normalizes the objective and immutable acceptance criteria, then initializes a per-run ledger.
2. An orchestrator performs one turn and records a receipt. Later turns can continue the orchestrator session.
3. Completion, evidence, and risk reviewers inspect the work in parallel with fresh review contexts.
4. Ordinary TypeScript reduces their decisions to complete, continue, blocked, or needs-human. The bounded loop then stops or starts another orchestrator turn.

Verification and control

Completion requires two approvals from the three reviewers. A malformed review or reviewer error does not approve. Repeated blockers can produce blocked. Exhausting the turn budget produces needs_human instead of silently claiming success. The ledger preserves the original contract, receipts, reviews, findings, blockers, reducer decisions, and lifecycle events for inspection.

Inputs: objective is required. Optional inputs are acceptance_criteria, max_turns (default 10), base_branch, git_worktree_dir, and create_pr (default false). Only strict create_pr=true permits a handoff attempt after completion. It cannot guarantee that provider credentials or repository state will allow a PR or merge request.

Exact source: definition and schemas · orchestrator and review loop · deterministic reducer

ralph: research-first delegated implementation

Use it when: a cross-cutting implementation should refresh its repository and ecosystem understanding before editing, delegate work through specialist subagents, and withstand iterative adversarial review. A broad refactor or migration with a ticket or spec path is a representative fit. Prefer goal when a bounded ledger of orchestrator turns fits the task better than repeated research and orchestration.

How it runs

1. Each loop refines the task into a research question, runs that research, and writes an artifact.
2. An orchestrator reads the artifact, supervises implementation and validation subagents, and maintains implementation notes.
3. Two reviewers from different primary model families inspect the result in parallel.
4. If either reviewer withholds approval, consolidated findings enter the next research, orchestration, and repair loop.

Verification and control

Ralph requires approval from both reviewers. Each reviewer reports a stop_review_loop boolean, and the gate trusts that flag rather than recomputing approval from the findings list. Two guards remain absolute: a reviewer execution error never approves, and output that fails to parse is recorded as a non-approval. The loop is bounded: reaching max_loops without convergence returns approved: false, not implied success. UI-applicable work may return a QA video path only when a file was actually produced. The workflow does not promise a video for every run.

Inputs: prompt is required. Optional inputs are acceptance_criteria, max_loops (default 10), base_branch, git_worktree_dir, and create_pr (default false). Without create_pr=true Ralph never touches a pull request, approved or not. With it, the handoff stage runs even when the loop exhausts max_loops without approval: that run must open a draft carrying every unresolved blocking finding, state that review did not converge, and not claim approval. Unlike Goal, Ralph's handoff is not gated on approval. Creating it remains an attempt, because provider credentials and repository state can still prevent a pull or merge request.

Exact source: definition and schemas · research, orchestration, and review loop · review decision semantics

open-claude-design: browser-guided design and handoff

Use it when: a page, dashboard, component, prototype, theme, or token task benefits from brief shaping, project design-system extraction, visual references, browser feedback, and a rich implementation handoff. It is not the general implementation loop for backend or non-visual work. Despite its historical name, do not treat its configured model and fallback chain as a guarantee that every stage always uses one provider.

How it runs

1. The workflow checks browser tooling, then shapes the brief and establishes or reconciles PRODUCT.md and DESIGN.md.
2. Three parallel passes locate, analyze, and extract project design-system patterns. Optional curated reference discovery follows.
3. A generation stage writes preview.html. The run then pauses at a deterministic prompt naming the preview path and its file:// URL, offering either a live browser review session or an immediate export of the preview as it stands. Headless runs skip that prompt.
4. One live review session follows if it was chosen. The user picks elements, receives variants, and accepts edits written into preview.html in place.
5. An exporter creates spec.html as the implementation handoff, then a final display stage opens it and prints the spec and preview paths. That stage does not reopen review or invite further changes, and a failure in it does not fail the run.

Verification and control

The live session is unbounded rather than capped at a fixed number of rounds. The workflow owns the poll loop and ends it only when the user exits the review — through the overlay, by closing the tab, or by saying exit live. A poll timeout is not an ending. The workflow declares no approval output: ending the session exports the design exactly as it then stands, with no second opinion, decision stage, or confirmation step. In normal interactive runtime, unavailable browser review stops the workflow before generation instead of producing an unreviewable preview.

Inputs: prompt is required. The only optional input is discover_references (default true). Discovery gathers the output type and concrete references. They are not supplied as command inputs.

Exact source: definition and schemas · discovery and design flow · review and export phases

Continue with the complete workflow reference

This page is a source-backed chooser, not an API manual. Use the complete Atomic workflow documentation as the technical reference for current commands, schemas, execution semantics, composition, run controls, and authoring details. The TypeScript workflow SDK guide covers workflow authoring and composition. The verification guide covers contracts, evidence, gates, and escalation.