Skip to main content

First session

Outcome: You complete one interactive task and know how to monitor and steer it. Prerequisites: Authentication is complete.

First session

On a fresh install with no prior Atomic startup state, Atomic shows a one-time first-run explanation after any What’s New notes and directly above the input box describing Atomic as a verifiable coding agent runtime for building and running agent workflows you can feel confident in. Returning users with prior startup state are marked onboarded automatically and continue directly into the normal chat UI; stored credentials by themselves do not skip the first-run explanation. The composer is the normal Atomic input from the start: type a message, run /login first if no provider is connected, or launch a workflow command without a special onboarding transition. Once Atomic starts, default to a workflow for non-trivial work and for requests with inherent structure plus a verifiable objective. Implementation, build, debugging, bug fixes, migrations, features, scoped multi-file edits, validation/review work, and loop-shaped requests are workflow candidates; reserve direct chat for tiny deterministic low-risk answers or edits where tracking clearly adds more overhead than value. Workflow-first is not builtin-only or monolithic. Atomic can discover and run named builtin, project, user, and package workflows; author a rich custom TypeScript workflow({...}) inline; and compositionally import reusable workflow definitions—including builtins from @bastani/atomic/workflows/builtin—into parent workflows with ctx.workflow(...). Nested children can nest again within maxDepth, so custom graphs can combine proven research, implementation, design, verification, and approval workflows instead of copying them. They can also classify and branch, dynamically fan out and synthesize artifacts, run adversarial repair cycles, tournament-rank candidates, and loop until checks pass with explicit bounds. Atomic turns repeatable engineering loops into executable stages with inspectable evidence instead of relying on a markdown checklist the model may or may not follow.

Verify the session

Run one bounded task and watch it complete. In a repository you know, type:
Expected result: Atomic streams a response, calls read on a directory, find, or bash at least once — each tool call is shown inline as it runs — and finishes with a summary naming directories that actually exist in your checkout. A response that names nothing from your repository means the session started outside the directory you meant; quit, cd to the right place, and start Atomic again. Then confirm the session was recorded:
Expected result: the session picker lists the run you just finished. That session is what atomic -c resumes.

Go further

With a session working, these are the fuller capabilities to reach for next. None of them is required for a first successful session.

Try the built-in workflows

Atomic ships with nine workflows you can run immediately. Use /workflow list to see them and /workflow inputs <name> to inspect their inputs in your environment.

Workflow List

Inputs are bare key=value tokens. Values are JSON-parsed when possible, so count=5, flag=true, and prompt="multi word value" preserve useful types. If you call /workflow <name> without required inputs, the TUI opens an inline picker; pass --no-picker to skip it. Goal and Ralph support git_worktree_dir only when you explicitly want a reusable worktree, and skip PR creation unless you set create_pr=true for the post-approval final stage. You can also launch workflows with natural language — describe the task in chat and ask Atomic to run a matching installed workflow or author a task-specific one:
Atomic chooses a complete execution shape, fills inputs from the request, and confirms before launch. Use Goal when a durable ledger and receipt-backed reviewer gate fit the task. Use Ralph when the job benefits from a research-first implementation/review loop. For exact domain contracts that either builtin does not cover, author a custom graph with deterministic checks and bounded repairs.

Monitor and steer a run

Named workflow runs execute in the background. After launch you get the full run id; user-facing workflow surfaces show that complete UUID. You can still type the full id or a unique short prefix to inspect, connect, pause, quit, or resume a run. Ambiguous prefixes are reported rather than selecting a run arbitrarily.
The below-editor BACKGROUND panel uses two lines per card at 80 columns and wider: the status glyph and full id are on the first line, and the workflow name plus mode/progress/elapsed metadata are on the second. Below 80 columns it collapses to a count-only line. In chat surfaces, a full id wraps onto continuation lines at narrow widths instead of being cut, and the surrounding border remains intact. Human-in-the-loop prompts (ctx.ui.input, confirm, select, editor) surface in the graph viewer, not as chat modals — connect to the run to answer them. Atomic also posts main-chat lifecycle notices when a run completes, fails, or awaits input. If you answer a workflow prompt in the graph or attached stage chat, the main chat receives a display-only answer summary for audit; it does not wake the model, enter LLM context, or answer later prompts. See Workflow Operations for the full run-control reference.

Top skills to invoke directly

Skills are reusable expert instructions. Trigger one with /skill:<name> followed by a request: Impeccable 4.1.1 resolves Live sessions to the selected app root, supports SvelteKit, Nuxt, TanStack Start, Astro, Next.js, Vite, and static HTML injection, and rejects absolute, traversing, or symlinked configured write targets. Its concept roll may contact impeccable.style; set IMPECCABLE_NO_TELEMETRY=1 or DO_NOT_TRACK=1 to disable the anonymous choice ping. The image fallback runs only with OPENAI_API_KEY, sends prompts and optional reference images to OpenAI, and spends that account’s API credit. Generated image prompts are embedded in the image or a sidecar, so do not include secrets. Use /skill:research-codebase for a focused subsystem or question. For repository-wide research, use fan-out-and-synthesize with distinct repository partitions and an artifact synthesis barrier. Use Goal for ledger-backed bounded orchestration and Ralph for research-first delegated implementation with iterative review; task size alone does not select either workflow.

Create your own workflow in natural language

Named workflows may be builtin, project, user, or package supplied. You do not have to hand-write TypeScript to add a new workflow. Describe what you want in plain chat and Atomic will design and write it for you using Builtins and Dynamic Workflows and the Custom Workflow Authoring reference as its source of truth:
Atomic will:
  • ask clarifying questions if stage purpose, inputs, models, or handoffs are ambiguous,
  • write a .atomic/workflows/<name>.ts definition that uses workflow({ ... }) and imports Type from typebox,
  • run /workflow reload so the generated workflow is rediscovered and can be launched with /workflow <name>,
  • then report the generated workflow folder so you can inspect the code it wrote, using Custom workflow created. You can inspect its code at: <workflow-folder-path> (for example, .atomic/workflows/); Atomic does this only for newly created custom workflows, never builtin or pre-existing workflows.
The same plain-chat approach works for editing or hardening an existing workflow. For the full authoring reference, see Custom Workflow Authoring, including composition with user-defined workflows and all nine builtins from @bastani/atomic/workflows/builtin.

Default tools and prompts

If you’d rather start with a plain prompt, just type a request and press Enter:
By default, Atomic gives the model these tools:
  • read - read files
  • bash - run shell commands
  • kill - cancel owned background shell tasks by task ID
  • edit - patch files
  • write - create or overwrite files
  • find - discover files by glob pattern
  • search - search file contents
  • ask_user_question - ask structured questions in the TUI
  • todo - manage file-based todos
On native Windows, powershell is also enabled when a PowerShell executable is available. Normal coding sessions include file discovery and content search through find and search in addition to read, bash, edit, and write. Atomic runs in your current working directory and can modify files there. Use git or another checkpointing workflow if you want easy rollback.

Next step

Continue to Project instructions.