SWE-ATLAS — a senior AI software engineer for Claude Code

The senior-engineer layer for Claude Code. Explore before you build, clarify only what matters, capture it in living HTML, then hand it to Claude Code's native plan / goal / workflow loop. Fewer tokens, less ceremony, faster to the thing people actually pictured.

npx swe-atlas@latest new-project                 # in your current project
npx swe-atlas@latest new-project my-workspace    # …or scaffold a new folder

One command. Full setup. No copy-pasting prompts every session.

ATLAS is an open-source Claude Code template: a curated set of skills, subagents, slash commands, and engineering conventions that turn Claude Code into a production-grade AI software engineer, with a wireframe-and-prototype workflow in place of heavyweight spec-driven development.

It ships in three CLAUDE.md modes, so you choose how much of the wheel to hand over:

• Vanilla — minimal footprint, no ATLAS identity.
• Collaborative (default) — the full senior-engineer identity with a review-and-commit loop; you stay in the driver's seat.
• Autonomous — the approval loop removed and free-will wired in (alongside super-product-owner and super-ui-ux-design): the skill that lets ATLAS decide for itself on the high-stakes forks — hold real alternatives open, ground each in evidence, refute the winner, then log the call in docs/decision_logs/. That's what lets it one-shot an app and run unattended without going off the rails.

The innovation isn't another spec pipeline — it's giving the agent engineered judgment: a way to make the calls a senior engineer would, on its own, and leave a trail you can audit. (Jump to the full mode comparison →)

---

Claude Code already has the engine. ATLAS helps you discover what to build.

Claude Code now plans before it edits, works toward a goal across turns, runs autonomously with safety checks, and orchestrates fleets of subagents, natively, in the box:

Native capability	What it does
Plan mode	Reads the codebase and proposes a plan; touches no files until you approve
/goal	Keeps working across turns until a checked completion condition holds
Auto mode	Approves its own safe tool calls, blocks destructive ones
Dynamic workflows	Writes a script that fans out dozens of subagents and cross-checks their findings

Kick off a workflow — describe the task and ask for a workflow in your own words, or include the keyword ultracode, and Claude writes one for it. Want it always-on? Set /effort ultracode and Claude plans a workflow for every substantive task in the session. (How workflows work →)

That is the execution loop, and it keeps getting better. So ATLAS doesn't try to rebuild it.

What Claude Code still won't do for you is decide what's worth building, prove the shape works before you spend tokens generating it, and leave behind a document you can actually trust. That part is on you. And that part is ATLAS.

Auto mode and dynamic workflows are in research preview at the time of writing; plan mode and /goal are generally available.

---

Why not another spec framework

The popular answer to "make the AI build the right thing" has been to bolt a process framework onto the model — Spec-Driven Development (SDD) and the agent frameworks in the same vein (spec-kit, BMAD, Get Shit Done, and the rest): write exhaustive specifications first, then generate the code from them. A constitution. A spec. A plan. A task breakdown. Five to seven Markdown files and a multi-phase pipeline, most of it produced before a single screen has been seen.

Four things go wrong:

• You plan before you've learned. The requirements, the task breakdown: most of it is a guess made before anyone has seen the thing work. You pay full freight to formalize guesses, build to them task by task, and find out at the end it isn't what anyone pictured. That's premature investment: detailed plans and guardrails poured around an idea nobody has validated yet.
• Text leaves room to disagree. A written spec is open to interpretation. You and the model can read the same paragraph and picture two different screens, and the gap only surfaces once the code exists. Prose is the wrong medium for "do we mean the same thing?"
• Markdown drifts. Keeping spec.md, plan.md, and tasks.md consistent with each other and with the code is its own tax, and plain .md can't even render the wireframe, flow, or matrix it's straining to describe.
• The loop is already native. Spec → plan → tasks → implement is precisely what plan mode, /goal, and workflows now do on their own. Wrapping a framework around the model to make it loop reinvents what ships in the box, at a heavy token premium, and slower, because every step waits on ceremony.

ATLAS takes the opposite bet: do the minimum upfront thinking that actually de-risks the build, make it cheap, fast, and visual, so a human and the model can look at the same thing and agree before a line is written, then hand a clean artifact to the native loop.

---

What ATLAS does instead

1. Explore before you commit

Cheap, throwaway-friendly artifacts that let you see the thing before generating code for it:

• /brainstorm:wireframe: a low-fi wireframe as one self-contained HTML file
• /brainstorm:prototype: a clickable, multi-screen React prototype
• /design:create-design-md: three real design variants you compare in a browser, then lock as DESIGN.md
• or /plan:visual: any non-UI change (refactor, migration, architecture call) as a visual HTML plan — Mermaid diagrams, change map, decision matrices

You validate the shape for the pr