Atlas.

FIG. 1 — The premise

The lone-genius era had a good run.

AI can already write most of your code. The open question is whether anyone is supervising it — or whether one chat window is researching, planning, building, and grading its own homework in a single breathless conversation that forgets its constraints by Tuesday.

Atlas is the other answer. It runs software work the way factories run production: distinct stations, verified handoffs, quality control by someone who didn't build the part — and a human at every decision that deserves one. You stop being the typist. You become the operator.

FIG. 2 — The cast

Three roles that check each other. One of you.

FIG. 3 — The touchpoints

Unattended between touchpoints. Never past a hard gate.

Five touchpoints per run of the feature workflow; two of them are hard gates that no configuration removes. Everything between them runs at machine speed inside the rails you set; nothing crosses a hard gate without your signature. (Rung one, research, has none: it only writes a document.)

FIG. 4 — The ladder

One discipline, three rungs. Match the process to the uncertainty, not the diff.

Sessions are expected to die. Plans, research, reviews, and decisions live in durable files in your journal — the conversation is disposable RAM.

FIG. 5 — The doorman

Autonomy is a padded room, not an open door.

Claude Code gives you three permission layers. Atlas edits none of them: the setup wizard prints the recommended deny rail and you paste it once. The rail is a floor, not a proof; a flag typed after its arguments evades a prefix rule, so judgment and review still do the real work.

FIG. 6 — Quality control

The factory grades its own runs. Then it tries to break them.

Every /atlas:feature-workflow run ends with a scorecard on the same form: protocol fidelity, role quality, outcome quality, a friction log, a verdict. Research runs carry their quality check inside the document, as a skeptic pass; the multi-session supervisor reads scorecards today and does not yet write one. The run fills in what it can see about itself. The outcome part and the grade are left to a session that ran none of the work; today you launch that session yourself and point it at the file and the PR. Its check isn't a lint pass: the grader reverts your fix in a scratch worktree and watches the new tests fail. Tests that don't scream when the fix is gone are decoration, and they get flagged.

Every friction gets logged, and every log entry becomes an edit — to a prompt, a rule, a template. The factory that built your last feature is not the factory that builds your next one.

FIG. 7 — The flywheel

It arrives good. It becomes yours.

Setup creates a journal — a durable home outside your repos where every plan, research doc, review, and scorecard accumulates. Skills consult it before starting anything, so the system's inputs get richer with every run you complete.

And your corrections outlive every update: HOUSE_RULES.md is a file the plugin seeds once and never overwrites, and every skill obeys, senior to its own defaults. Fold in a rule once, and every future run — through every version bump — carries it.

FIG. 8 — Installation

Three commands. Then give it a work item.

The marketplace and the plugin are both named atlas, so the install string is exactly atlas@atlas. After the install, /atlas:setup is available in the same session; no restart. The wizard checks your machine, asks about your tracker, and proves the setup with a real read before it writes anything. It never touches your Claude Code settings.

Or paste this into Claude Code and let it run the first two lines for you:

Then: the quick start, what to type, from an empty machine to your first scorecard · how it works · the Deck, one card per skill and role · the README.