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 worker-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. A worker performs one turn and records a receipt. Later turns can continue the worker 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 worker 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 · worker 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 worker 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. Parse failures and reviewer errors are non-approvals. 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). As with Goal, PR creation is an opt-in post-approval attempt, not a guaranteed outcome.

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 bounded generate-and-feedback loop writes preview.html, opens it for browser review, and passes meaningful user feedback into the next revision.
4. An exporter creates spec.html as the implementation handoff. A final display stage follows.

Verification and control

Human feedback controls refinement. No separate independent export gate exists. “Approved for export” means the latest feedback pass contained no meaningful feedback. If the refinement cap is reached while feedback remains, export still proceeds and the approval flag can remain false. In normal interactive runtime, unavailable browser review stops the workflow before generation instead of producing an unreviewable preview.

Inputs: prompt is required. Optional inputs are discover_references (default true) and max_refinements (default 3). Discovery gathers the output type and concrete references. They are not supplied as command inputs.

Exact source: definition and schemas · discovery and design flow · refinement 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.