Test-driven loop for coding agents

Plan before code. Prove before commit.

devloop turns a coding agent's one-shot "done" into three gated steps. You specify, it plans, it builds with tests, and independent review agents catch design bugs before any code is written and correctness bugs before anything ships.

/plugin marketplace add KashZod/devloop
The problem

"Done" is usually a self-report

Ask an agent to build a feature and it hands you working-looking code and a confident summary. What it cannot give you is a second look from a context that did not just write it.

reads as: done

"I verified it works."

The same context that wrote the code, grading its own work against the assumptions it just made.

reads as: done

"An independent agent reviewed the diff."

A reviewer that never saw the code being written, quoting the test line that proves each acceptance criterion.

One prompt also runs three decisions together: what to build, how to build it, and the code itself. A misread requirement gets decided and written into code at once, where it is hardest to undo. devloop pulls the three apart and puts a gate between each.

The loop

Three commands, three gates

One command per decision, each with a hard gate that has to pass before the next begins.

1
/spec

Clarify what to build

Turn a request into user stories, acceptance criteria, and edge cases. Nothing gets planned on a vague spec.

gate: 8-point spec checklist

2
/plan

Decide how to build it

Decompose the spec into an ordered, dependency-aware set of chunks and a JSON tracker that survives context resets.

gate: review-plan agent, before any code

3
/implement

Build it, test first

Work each chunk red then green: a failing test, then the code that passes it, against the plan.

gate: review-impl + red-team agents

The loop is not one-way. If a review finding shows the plan itself was wrong, not just the code, /implement appends corrective chunks and re-runs the plan gate in place, then keeps building, so the plan and the code stay in sync.

The review layer

Two reviews at the end. No overlap.

When the chunks are done, two independent agents read the diff in a context that did not write it. They answer different questions, so nothing falls between them.

review-impl · conformance

Does it match the plan?

Checks that the code does what was planned and that a test proves each acceptance criterion. Every criterion is marked, each backed by a quoted line.

CONFIRMED PLAUSIBLE REFUTED
red-team · correctness

Is it wrong or wasteful?

Hunts bugs across five angles regardless of the plan, recall-biased first, then verifies each finding and drops the false positives.

bugs cleanup verified

A bug that faithfully implements a flawed plan is caught only by red-team; a correct but off-spec change only by review-impl. On a large, multi-file diff the red-team half splits into a focused bug pass and a focused cleanup pass in parallel; on a small one it stays a single pass. Either way the whole gate is read-only.

Why it holds

The reviewer never wrote the code

A context that wrote the plan or the diff grades its own assumptions along with the code. devloop runs each gate in a separate context, so a pass comes with evidence instead of a summary.

Install

Add it to your agent in two commands

devloop ships as a plugin over a git marketplace. The same three commands power both harnesses.

Claude Code
/plugin marketplace add KashZod/devloop
/plugin install devloop@kashzod
Codex
codex plugin marketplace add KashZod/devloop
codex plugin add devloop@kashzod

Then give the loop project context: drop a .devloop/ folder at your project root with config.md (build and test commands, architecture, standards) and domain.md (domain knowledge). The fastest start is to copy the closest examples/<stack> directory. The skills read .devloop/ from your project, so a plugin install stays read-only in its cache.

Questions

Before you install

What agent do I need to run it? +
Any coding agent that supports slash-command skills and can delegate to subagents. Claude Code and Codex both qualify and are what devloop runs on today. Subagent delegation is what lets each gate review in a context that did not write the code; on a harness without it the gates still run, but as an in-context self-check, and the skills flag that at the gate.
Does it call a model or send my code anywhere? +
No. devloop ships only markdown and a bash validator, with no runtime dependencies and no service of its own. It runs inside the agent you already use; any model cost lives with that agent, which is yours.
How is this different from just prompting the agent well? +
A good prompt lives in your head and drifts from run to run. devloop separates what, how, and build into three gated steps, runs review in a context that did not write the code, persists a tracker so work survives resets, and ships as a versioned artifact that behaves the same across projects.
What if my project has no tests yet? +
The loop is test-first by construction. Each chunk starts from a failing test, then the code that turns it green. You end up with tests because writing them is how the work gets done, not a chore bolted on after.
Can I review a random diff with no plan? +
Yes. Invoke the red-team agent directly on a hotfix or someone else's branch. It is plan-agnostic and discovers the project's standards at runtime, so it does not need a tracker to review against.
Does it lock me in? +
No. It is plain files under an Apache-2.0 license. Install it from the marketplace, or vendor skills/ and agents/ into your own project. Remove it and your code is untouched.