Introduction
An agent told to make the tests pass will make the tests pass. This makes it prove the software works instead.
“Tests pass” is not evidence that anything works. Tests check code against your model of the code, so when the model is wrong the tests are wrong the same way — confidently. And an agent optimises for whatever signal it is judged on: tell it to make the tests pass and it will make the tests pass.
DAG Engineering is a Claude Code and Codex plugin that closes that gap. If the destination is unclear it first preserves an Atlas of decisions and related expeditions. It then breaks one destination into slices on GitHub, writes down what would convince you each slice works before any code exists, and builds them without closing anything until that evidence is in the pull request.
Two commands
| Move | Claude Code | Codex |
|---|---|---|
| Settle, chart and sign the plan | /dag:plan |
$dag:plan |
| Walk every signed slice to done-clean | /dag:execute |
$dag:execute |
dag:plan is where you live until the plan is signed. Run it from any window: it reads the state off
GitHub, tells you where you are, and performs the next planning move in the same turn. When the plan is
signed, dag:execute takes it from there. The main orchestrator owns the frontier and assignments;
Claude Code uses Agent Teams, Codex uses native child agents, and every worker receives exactly one
issue, one worktree and one PR.
Is this for you?
Worth it when
The work is more than one sitting, several slices could run in parallel, and you’d be embarrassed to find out later that “done” meant “tests passed”. Especially when agents are doing the building.
Overkill when
It’s a one-file fix or anything where writing down the evidence bar costs more than the change itself. Just do the work.
It also assumes GitHub. The dependency graph is GitHub’s own issue-blocking relation, not prose links in issue bodies — that’s what lets any window pick up where the last one stopped, and no other tracker provides it.
What it forces
Three things, and they’re the whole design:
The bar is written before the work
When a slice becomes an issue, its issue says what evidence would prove it — which checks, what to capture, and how. Whoever builds it later cannot choose a bar they can clear, because the bar already exists.
Nothing closes without that evidence
Not “tests green”. The actual artifact — the screenshots, the record with its ids, the captured output — posted to the pull request where a reviewer will see it.
The evidence must survive someone else reading it
It goes in the PR and a committed receipt, so the person who wasn’t there can check it, and so it’s still there when the thing breaks in a month.
Where to go next
Quickstart
Install it and configure a repo. Ten minutes.
Walkthrough
One small expedition end to end, with the real issue bodies, commands and PR comment. Start here if you’d rather see it than read about it.
When it goes wrong
Stops, deadlocks, resuming after a crash, and what it does to your repo.
Concepts
Proof tiers, the graph, and the escalation ladder — once you want the reasoning.