SWE-ATLAS: a Claude Code template that bets against the spec pipeline

The problem SWE-ATLAS claims to solve is planning before learning

The README frames the target as the gap between what Claude Code already does and what it will not do for you. Plan mode reads the codebase and proposes a plan. `/goal` keeps working across turns until a completion condition holds. Auto mode approves safe tool calls and blocks destructive ones. Dynamic workflows fan out subagents and cross-check findings. None of that decides what is worth building, and none of it proves the shape of a screen before you spend tokens generating it. That second gap is where ATLAS positions itself, and the audience is narrow: someone already running Claude Code who keeps producing correct code for the wrong interface. The README's own phrase for the failure is planning "before anyone has seen the thing work." If your projects are backend jobs with no visual surface, most of the tooling described here has nothing to attach to.

Four objections to spec-driven development, and which ones hold up

ATLAS names spec-kit, BMAD and Get Shit Done as the pattern it rejects, then lists four problems. The first is premature investment: requirements and task breakdowns are guesses formalized before validation, and you pay full freight to build to them. The second is that prose is ambiguous, so you and the model can read one paragraph and picture two different screens. The third is that `spec.md`, `plan.md` and `tasks.md` drift out of sync with each other and with the code, and plain Markdown cannot render a wireframe or a flow. The fourth is that spec to plan to tasks to implement is what plan mode, `/goal` and workflows already do natively, so wrapping a framework around the model duplicates shipped behaviour at a token premium. The third and fourth objections are the strongest: they are about mechanism, not taste. The first is partly a claim about how other teams run their pipelines, and the README does not measure it. Treat the argument as a design rationale, not a benchmark.

What the explore step actually produces

The mechanism is a set of slash commands that emit artifacts cheap enough to throw away. `/brainstorm:wireframe` produces a low-fi wireframe as a single self-contained HTML file. `/brainstorm:prototype` produces a clickable multi-screen React prototype. `/design:create-design-md` generates three design variants you compare in a browser, then lock as `DESIGN.md`. `/plan:visual` handles non-UI changes such as a refactor, a migration or an architecture call, rendering Mermaid diagrams, a change map and decision matrices as HTML. The common thread is that each output is something a human and a model can look at simultaneously, which is the README's answer to the ambiguity objection: text invites interpretation, a wireframe pins it down. Note what is not claimed. There is no statement that the prototype is production code, and the README calls these artifacts throwaway-friendly, so the intent is a disposable probe rather than a first commit.

Clarification stops at load-bearing unknowns

`/plan:create-phase` resolves what the README calls the load-bearing unknowns through targeted Q&A and then stops. There is no constitution and no task ledger. The stated boundary is that ambiguity which would derail the build gets surfaced and answered, while everything else stays out of the way. That is a judgement call baked into a command, and it is the part most likely to fail quietly: if the agent misclassifies an unknown as non-load-bearing, you will not see a missing section, you will see it later in the code. The design assumes you can tell the difference between a question that matters and a question that does not, and it puts the agent in charge of that filter. Whether that holds depends on how well the codebase and the request are described when the command runs.

Three CLAUDE.md modes, and the one that changes the risk profile

The template writes one of three CLAUDE.md variants. Vanilla is a minimal footprint with no ATLAS identity. Collaborative is the default: the full senior-engineer identity with a review-and-commit loop, and the README's framing is that you stay in the driver's seat. Autonomous removes the approval loop and wires in `free-will` alongside `super-product-owner` and `super-ui-ux-design`. The README describes `free-will` as the skill that lets ATLAS decide for itself on high-stakes forks: hold real alternatives open, ground each in evidence, refute the winner, then log the call in `docs/decision_logs/`. That audit trail is the interesting part, because it converts an unattended run into a sequence of written decisions you can review after the fact. It is also the mode where a wrong call costs the most, since nothing pauses for approval. The README attributes the ability to one-shot an app to this mode specifically. That is a claim about behaviour under autonomy, and the only way to check it is to read the decision logs from a run you supervised.

Getting it running

Installation is one command, run in your current project: `npx swe-atlas@latest new-project`. To scaffold into a new folder instead, pass a name: `npx swe-atlas@latest new-project my-workspace`. The README describes this as full setup with no prompt copy-pasting per session. The package is published to npm as `swe-atlas`, and the README shows version and download badges from npm, so the distribution channel is npm rather than a git clone. Everything else the template installs is generated into your project: the CLAUDE.md variant, the skills, subagents and slash commands. That means the upgrade path is re-running the scaffold command rather than pulling a dependency, and it also means the generated files are yours to edit, which will complicate a later re-run if you have modified them. The README does not describe a merge or diff behaviour for existing files, so back up a customized CLAUDE.md before re-running `npx swe-atlas@latest new-project`.

Where the approach breaks down

Two limitations follow from the design. First, the explore step assumes a human can evaluate the artifact. A clickable React prototype and a browser comparison of three design variants both require someone to open a browser and judge the result. On a team where nobody reviews the prototype, the wireframe becomes ceremony of a different kind, and you have paid for it without buying the de-risking the README promises. Second, the whole template rides on Claude Code's native loop. The README itself notes that auto mode and dynamic workflows are in research preview at the time of writing, while plan mode and `/goal` are generally available. A template whose value proposition is handing clean artifacts to that loop inherits the loop's preview status, and behaviour in a research preview can change between releases. If you need a build process that behaves identically across a pinned toolchain, this is the wrong layer to depend on.

The difference from a spec-first framework

The clearest contrast is with Spec-Driven Development as the README describes it, and with named tools like spec-kit, BMAD and Get Shit Done. Those generate a constitution, a spec, a plan and a task breakdown, five to seven Markdown files, mostly before any screen exists. ATLAS inverts the order and the medium. It produces a wireframe, a prototype or a visual plan first, keeps the written artifact to a single HTML spec document, and delegates the plan and task breakdown to Claude Code's own plan mode and `/goal` rather than maintaining parallel Markdown. The practical difference is what you review and when. In the SDD flow you review prose before anything is visible; in the ATLAS flow you review a rendered artifact before the spec is written. That is a real difference in approach, not a rebranding, though it only pays off if the rendered artifact is easier to correct than the prose would have been.

Maintenance cost and the licence question

Release cadence is visible from the tags: v2.6.2, v2.6.3 and v2.6.4 all landed within roughly eight days in June 2026. A template that tracks Claude Code's preview features has to move when those features move, so expect to re-run the scaffold periodically and to re-read the generated CLAUDE.md each time. That is a recurring cost, and it lands on whoever customized the previous version. On licensing, the repository metadata supplied here does not state a licence, and the README's licence badge points at the npm package page rather than naming an SPDX identifier. Do not assume permissive terms from the npm listing alone. Check the `license` field in the published package metadata before you ship anything derived from the template, and if it is absent or unclear, treat that as a blocker for commercial use until someone confirms it. This is a factual gap in the material, not a legal opinion.

Editorial conclusion

Adopt SWE-ATLAS if you already work inside Claude Code and your failure mode is building the wrong screen rather than writing the wrong function; the wireframe and prototype commands target that specific gap. Skip it if you need a reproducible, version-pinned build process or if your team cannot review a React prototype to sign off on a design. Before committing, run npx swe-atlas@latest new-project in a throwaway folder, read the generated CLAUDE.md, and confirm which mode it wrote and whether the licence file is present in the package, since the repository metadata does not state a licence.

Official sources

1. Issues
2. README
3. Releases
4. syahiidkamil/Software-Engineer-AI-Agent-Atlas on GitHub