Engineering28 packages
- code-mentor
- code-vuln-audit
- repo-audit
The model writes the code. It doesn't get to decide if it's good.
atlas-orchestrator is a plugin for Claude Code, Codex and OpenCode that drives every change through one state machine and judges it with six lenses. A pure function, not a model, computes the verdict, and nothing reaches your tree without a human gate.
Task add parse_duration, the inverse of format_seconds
6 lenses5 passed1 flagged
- DOES-IT-RUNruncheckpassed
- CODE-QUALITYquality.lint_deliverablepassed
- SECURITYsemgrep sastpassed
- TEST-ADEQUACYadvisorypassed
- REQUIREMENTS-COVERAGE7 criteriapassed
- CORRECTNESScriticflagged
verdict.merge -> verdict.gate
0 CRITICAL 0 HIGH 4 MEDIUM 2 LOWPass 0 already cleared the gate: only CRITICAL and HIGH block
REFINE 1/2
A correctness or security defect at any severity forces a refine pass anyway: a model assigns that severity.
Pass 0 had already cleared the gate. The forced refine pass found the bug anyway.
int() accepts all of them, so the parse never raised.
A real run from 12 September 2026, documented in the plugin's README under “Proven live”.
claude plugin marketplace add null0xxx/atlas-orchestrator claude plugin install atlas-orchestrator@atlas-orchestrator Those two need the Claude Code CLI; every host needs Python 3.11 or newer
How a verdict is computed
A coding agent that grades its own work will call it done. atlas-orchestrator takes that vote away from every model, including the one that wrote the diff.
Evidence is gathered by programs
The build is run, the diff is linted, the criteria are matched, cited paths are checked for existence, changed sources are parsed, and a SAST scan runs over the scope. Each of these can block on its own, before a model has been asked anything.
runcheck,quality.lint_deliverable,reqcoverage,pathcheck,astlens,syntaxlens,semgrep sastDOES-IT-RUN
Fully deterministic
Your verify command runs under a memory cap and a hard timeout, and every changed source file is parsed. No model is consulted.
Deterministic floor
runcheck + astlens + syntaxlensTEST-ADEQUACY
Deterministic, advisory
Were tests really added and collected? A green build whose suite ran nothing is not green.
Deterministic floor
quality.lint_deliverableREQUIREMENTS-COVERAGE
Deterministic, advisory
Each frozen success criterion is checked against the actual diff, and a change that grew beyond the files you named is a defect.
Deterministic floor
reqcoverage.coverage
Three critics judge in isolation
Each critic receives exactly four things: the frozen intent and criteria, the captured diff, its own single rubric lens, and the slice of deterministic evidence relevant to it. Nothing else. That isolation is what buys anti-anchoring: a critic cannot agree with a conclusion it was never shown.
correctness-critic,code-quality-critic,security-criticCORRECTNESS
Judgment critic
Does the change do what was asked, for the inputs it will see? Edge cases, error paths, off-by-one errors, tests that miss the requirement.
Deterministic floor
runcheckCODE-QUALITY
Judgment critic
Does it follow the conventions already in the repository? Structure, naming, dead code and debug tokens left behind.
Deterministic floor
quality.lint_deliverableSECURITY
Judgment critic
Injection, unsafe sinks, secrets, trust boundaries. A
semgrepscan blocks on its own; it is fail-open, and the lens says whensemgrepis absent.Deterministic floor
semgrep sast
A pure function returns the verdict
Critic reports and deterministic defects are normalised by
verdict.mergeand folded byverdict.gate. Both are pure: same inputs, same answer, every time. The orchestrator marshals inputs into them and reads the result. It does not get a vote.verdict.mergeverdict.gateverdict.final_status
Nothing auto-applies
Three gates, at the only three places a human decision actually changes the outcome.
INIT
Checks its own preconditions and looks for an interrupted run to continue. If import isolation is unavailable, it aborts here rather than running unprotected.
INTENT_
CAPTURED Freezes the task packet: your intent verbatim, the ordered success criteria, the scope, the verify command, the baseline. Nothing downstream may re-derive them.
- Human gate: Clarify, until the design is settled
CLARIFYconditional
A design-tree interview, asked in rounds with a recommended answer to every question, written to the ledger and resumable; a fact it can read out of the repository it establishes itself. It fires only when a load-bearing field is missing or the scope is genuinely ambiguous; a clear task skips it.
TRIAGED
Classifies the work as a bugfix, feature, refactor or test, and confirms the target is a code tree. Bookkeeping, no model judgment.
- Human gate: Approve the plan before a byte is written
GROUNDED
A read-only scout reads the repository and returns the facts, conventions and conflicts that matter. It cannot write; the root persists the digest.
CODED
The coder implements inside the approved scope and self-verifies before returning. Its own status is evidence for the harness, never proof.
VERIFIED
The full six-lens harness runs: the deterministic floor first, then three isolated adversarial critics, then a pure fold into one verdict.
REFINEconditionalcapped at 2
Any blocking defect, and any correctness or security defect at any severity, forces another pass. Hard-capped at two, so the loop provably halts.
- Human gate: Apply or discard at the end
OUTPUT
The one place a run ends. You get a result labelled with its status, and you decide what happens to it.
An interactive run stops at each gate and waits for your answer.
Clarify, until the design is settled
If a load-bearing field is missing or the scope is genuinely ambiguous, the run interviews you rather than guess: a design tree, asked in rounds, each question carrying a recommended answer. It ends only when you confirm the shared understanding, and a clear task skips it entirely. The same interview ships on its own as
grill-me.Approve the plan before a byte is written
You see which files will change, the approach, and the exact command that will judge the result, while the tree is still untouched. Approve, adjust, or cancel.
Apply or discard at the end
The run stops with a labelled result and asks what to do with it.
On this site, each of atlas's four recorded runs stopped once at CLARIFY for the author's answer.
In a non-interactive run nobody can honestly answer, so it does not ask: the change stays on an isolated branch and worktree, and your own tree is never written. A task too ambiguous to proceed on ends there, labelled UNVERIFIED, rather than being guessed at.
Every transition is written to an on-disk ledger under .atlas/<run_id>/, so a run survives a context compaction, and /atlas-orchestrator:atlas-resume continues it from its last recorded stage.
While a run is active, telemetry.sh appends a line to that run's hooks.jsonl on every tool and subagent event: PostToolUse, PostToolUseFailure, SubagentStart, SubagentStop. The live context graph is recomputed from the ledger each time it is read.
Larger changes, and what keeps a run safe
/atlas-orchestrator:atlas-weave splits a larger change into a file-disjoint plan and runs at most 3 atlas runs at once. After merging, every node's baseline-green tests run again on the merged tree, which catches a change that passes alone and fails combined. Work that does not really split degrades byte-identically to a single run.
One untrusted-content wrapper Every text a model sees but did not write (a skill's body, tool output, a failing build's stderr) is framed as data, so it cannot change the coder's intent, scope or target.
Forward-only rollback A crash-safe reset that only ever fires inside the isolated worktree, never in your real tree.
116 skill packages, and a selector that picks the right one
Finance19 packages
- financial-ratio-toolkit
- discounted-cashflow-model
- equity-research-report
Featured18 packages
- find-skills
- fast-browser-use
- docx
Productivity17 packages
- grilling
- gantt-planner
- structured-minutes
Creative15 packages
- keynote-composer
- x-thread-crafter
- photo-magazine
Marketing11 packages
- seo-content-writer
- campaign-plan
- competitor-analysis
Academic8 packages
- cv-tailor
- anki-card-maker
- scholarly-writing-refiner
At GROUNDED the selector ranks the registry against your frozen intent: the top result becomes the coder's active skill, the critics never see it, and you steer it with pin, exclude, boost and categories.
The 116 is measured: the registry names 116 packages, and their manifest owns 661 files and 153 SKILL.md entries — one per package, plus 37 nested GitLab skills. Claude Code counts 119 skills on disk, those packages and the 3 orchestrator skills; Codex and OpenCode each discover 156 native names, 151 generated and 5 first-party. Discovery is what was verified on each host: whether a host auto-triggers a vendored package is not confirmed, while the orchestrator skills are confirmed directly invocable.
What it has actually caught
No customer logos and no benchmark claims: this project does not have them and will not invent them. What follows is its own recorded evidence, and you can read the ledgers.
This site, audited by atlas
3 of 4 atlas runs on this site ended UNVERIFIED.
Twice for HIGH-severity defects in this site's own build code. Once for a CRITICAL error atlas caught in its own run ledger.
| Run | Date | Task | Refine passes | Result | CORR | CQ | SEC | TEST | RUN | REQ | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 48fb111e.1 | Building the site | 2 | UNVERIFIED | 4 | 7 | 5 | 2 | 1 | 0 | 19 | |
| 48fb111e.2 | Fixing the first run's open defects | 2 | UNVERIFIED | 3 | 7 | 5 | 1 | 0 | 0 | 16 | |
| 48fb111e | A new palette and a before/after demonstration | 2 | UNVERIFIEDFootnote 2 | 12 | 6 | 0 | 1 | 1 | 0 | 20 | |
| a4f86c28 | Fixing the palette run's open defects | 1 | OK | 2 | 6 | 0 | 3 | 0 | 1 | 12 |
- A ledger keeps only a run's final pass, because each pass overwrites the one before it. Every count in this table is therefore a floor, not a total. Back to the text
- Of the 20 defects run
48fb111erecorded, the orchestrator withheld 11 from the coder: 10CRITICALpathcheckfindings that checked real paths from the plugin's own repository against this site's root, and 1 out-of-scopeHIGHfinding on a file the coder never wrote, the impeccable plugin's hook cache. The gate is a pure function and knows nothing of what was withheld, so it returnedUNVERIFIED. The one blocker that was not withheld is the ledger'sstale-verdict. Back to the text
One real finding from each lens
Read each lens's finding
On the Georgian page, a screen reader announced whether a lens had passed or been flagged as an English word, with no language marked.
The stylesheet and the design document both said no coloured halo existed anywhere on the site, while the primary button's hover cast a white glow.
Every build deleted the symbolic links in its output directory, even ones its own manifest never recorded; on a server with no version control, a certificate-renewal link could have gone with no way to restore it. The finding describes that risk, not a recorded deletion. Fixed: a link is now removed only when the manifest records it, checked in this site's code on 13 September 2026.
“Python 3 standard library only” was true of every module, but no test would have failed had it stopped being true.
The ledger recorded a pair of consecutive stages the state machine does not allow, so the run's own record of what it did could not be trusted.
The approved plan allowed a colour in shadows that the shipped test rejected, and the departure from the plan was not written down.
39 defects while building its own skill system
The registry, the selector and the vendoring of the skill packages each went through the full machine. As recorded in the plugin's README under “Proven live”, the harness caught 39 real defects across the two runs, including a critical zip-slip: a hostile skill's frontmatter name could traverse the extractor's output path. Fixed before anything shipped, with strict name validation, collision checks, path and symlink guards, and a hostile-input matrix.
These are the project's own records, not third-party benchmarks.
What it does not do
A verification tool that oversells itself is the one thing it must not be. These are the project's own stated limits, reproduced without softening.
Decomposition incoherence is not solved
The gates catch defects and test-observable regressions. They do not catch a split that looks coherent and is semantically wrong. This is mitigated (degrade-to-single-run, coupling checks, seam critics, criteria conservation) and explicitly not solved.
The differential is sound, not complete
An emergent interaction between two changes, with no test covering it, can still merge green.
The judgment lenses are model critics
The deterministic floor blocks what is mechanically detectable. A subtle bug hiding behind an adequate-looking test remains a named soft spot, not a solved problem.
The vendored skills are third-party content
They are integrity-anchored and injected with explicit untrusted-content framing, but they are instructions written by their authors and used on your behalf. Read a skill's directory before relying on its payload scripts in a sensitive environment.
Throughput is deliberately small
The integration step is a serial bottleneck, so useful concurrency is roughly twelve to sixteen nodes per run, not hundreds. That is the design: quality over quantity.
Install
Two commands on Claude Code, or one installer for all three hosts. Then one real task.
Requirements
Claude Code CLI, and CPython 3.11 or newer as python3. The floor is hard: the isolation that keeps an untrusted repository from replacing the gate's own modules did not exist before 3.11, so on anything older every run stops at its first step rather than running unprotected. Several LTS distributions still ship 3.10, so check before installing.
python3 -VAdd the marketplace
claude plugin marketplace add null0xxx/atlas-orchestrator Install the plugin
claude plugin install atlas-orchestrator@atlas-orchestrator Confirm it loaded
/atlas-orchestrator:atlas ping Then hand it real work
Illustrative task
/atlas-orchestrator:atlas fix the off-by-one in pagination verify_cmd: pytest -q success: page 2 returns rows 11-20 scope: api/ pagination.py verify_cmd:- the command that must pass
success:- the acceptance criteria, in plain words
scope:- the files atlas may touch; a change outside them is a blocking scope-creep defect
All three are optional: a field you leave out is asked for at
CLARIFY.
Three commands: /atlas-orchestrator:atlas for a single change, /atlas-orchestrator:atlas-weave when the work is really several changes, and /atlas-orchestrator:atlas-resume to continue an interrupted run.
What it adds to Claude Code
The agents, skills and hooks it adds
- Agents
- 7
context-scout,elite-coder,correctness-critic,code-quality-critic,security-critic,integration-critic,planner - Skills
- 3 orchestrator skills and 116 vendored skill packages
- Hooks
init-env.shSessionStartsession-resume.shSessionStarttelemetry.shPostToolUse,PostToolUseFailure,SubagentStart,SubagentStop
The hook manifest registers only fail-open, observe-only or pointer-only hooks.
One installer for all three hosts
How to install or update all three at once
From a checkout of the repository, one manager installs or updates Claude Code, Codex and OpenCode together: plan is a read-only preview, apply installs or updates, and rollback restores the previous managed revision.
python3 scripts/atlasctl.py plan python3 scripts/atlasctl.py apply python3 scripts/atlasctl.py rollback It makes no model call while installing, owns its own checkout under ~/.local/share/atlas-orchestrator/current, and refuses a dirty checkout or a file it does not recognise. --channel development tracks origin/main, --ref takes a published revision, --repo another repository or a local clone, and --hosts narrows it to the hosts you name; the default is all three.
Restart Claude Code or OpenCode, or open a new Codex thread, after an update.
Both ports carry seven role contracts, five native skills and a generated catalogue of the 116 packages, on the same scripts/ backbone, unchanged:
On Codex
How it runs on Codex
The port sits in runtimes/codex/ and reuses an existing ChatGPT login, with no API credentials of its own.
Codex exec holds every role read-only except the coder, the one worker that writes the review tree, and no child can escalate. User exec rules, nested agents, plugins and hooks are disabled, and project MCP servers explicitly so, because a remote write would bypass the filesystem sandbox.
Malformed JSON, an invalid critic contract, a missing final message, a timeout and a process failure all fail closed. If a selected model is unavailable, the run stops instead of falling back to a weaker one, and the runner rejects reasoning below medium.
The packaged worker profile
gpt-5.6-solhighelite-coder,planner,correctness-critic,security-critic,integration-criticgpt-5.6-terramediumcontext-scoutgpt-5.6-terrahighcode-quality-critic
A starting configuration, not a ranking: the project states that cross-role quality and quota cost are unmeasured. The model of the session you run it from is yours to choose, not the profile's.
On OpenCode
How to set it up on OpenCode
The port sits in runtimes/opencode/, and OpenCode discovers the installed role and skill files itself.
OpenCode reads role and skill files from ~/.config/opencode/agent/ and ~/.config/opencode/skills/. The installer above places them there for you; from a clone of the repository you can also symlink the role files and the skill directories yourself, as the port's README shows.
The role files name no model, because OpenCode is provider-agnostic: which model takes which role is set on your install, outside the plugin.
One guard stays off until you turn it on
What it checks, and how to turn it on
guard-destructive.sh is the only hook in the plugin that can block a tool call: a denylist check on Bash commands before they run. It is not wired by default, because a blocking PreToolUse hook applies to every Claude Code session once the plugin is installed, and it is best-effort and fail-open by design.
To turn it on, add a PreToolUse entry for it to hooks/hooks.json; the hook's own header gives the exact entry.
Know this before you turn it on: the plugin's own security audit found that it also denies some ordinary compound commands, such as rm -rf ./build && ls /. The guard in 4.8.1 still denies that one, and no release records a fix.
Headless and CI
The command, and what to read before you run it
One-shot and non-interactive. With no human able to approve, the run confines itself to an isolated branch and worktree and presents the result for a person to merge.
Read the flag itself carefully before you copy this: bypassPermissions removes every approval prompt in Claude Code, not only the ones atlas adds. Run it inside a disposable container or a CI runner you control, never on your own workstation.
claude --permission-mode bypassPermissions -p "/atlas-orchestrator:atlas <change> verify_cmd: <cmd> success: <criteria> scope: <paths>" Developing atlas-orchestrator itself
To change the plugin rather than use it, work from the repository: its README explains how to load it from a working tree.