The Claude Code Harness: Plan → Work → Review → Release
Raw agent sessions drift. The plan lives in chat scrollback, so by turn forty nobody — including the agent — can say what was actually agreed. Tests become optional the moment the agent decides it's "basically done." Review happens after the merge, if at all. And when it's time to ship, the release notes get reconstructed from memory instead of evidence.
None of these are model failures. They're process failures — and process failures have process fixes. The most complete one we've seen packaged recently is the harness pattern: wrap the agent in a bounded Plan → Work → Review → Release cycle where each stage has its own artifact, its own gate, and its own definition of done.
Where this comes from
The framing here is drawn from claude-code-harness by GitHub user Chachamaru127 — a Claude Code plugin that describes itself as achieving quality through an autonomous Plan → Work → Review cycle. It installs from the Claude Code plugin marketplace and ships slash commands for each stage: one to build the plan, one to execute tasks from it, one to run an independent review, and one to validate builds and tests before anything ships.
You don't need that specific plugin to use the pattern. The ideas underneath it are tool-agnostic, and each one maps onto loops already in this directory:
Plans live in source-of-truth files, not chat. A plan that exists only in conversation history evaporates when the context does. The harness keeps a Plans.md the agent reads from and writes to — the same "the agent forgets, the file does not" principle behind every durable loop.
Work happens only against approved slices. The agent doesn't freelance. It picks up the next approved item from the plan file, does that, and stops. Scope creep is a plan-file edit, which makes it visible and reviewable instead of silent.
Review is independent from implementation. The agent that wrote the code doesn't grade it. A separate pass — ideally a separate agent or model — checks the diff against the plan.
Release evidence is packaged from verified outputs, not memory. What shipped is what passed. Test results, build logs, and diffs travel with the release instead of being summarized after the fact.
Unknowns stay marked unknown. If the agent can't verify something, the harness has it say so rather than invent an answer. This sounds small; it is the difference between a report you can act on and one you have to re-check line by line.
Five loops that implement the stages
You can assemble the whole cycle from loops in this directory today.
Plan — [Draft a sprint plan from the backlog](/loops/sprint-plan-from-issues). Turns an issue backlog into a written, prioritized plan artifact. This is your Plans.md generator: the output is a file the work stage can execute against, not a chat answer that scrolls away.
Work — [Ship specs through code review](/loops/ship-specs-through-code-review). Executes against an approved spec and drives the change toward review, rather than improvising from a one-line instruction. The spec is the approved slice; the loop's job is to make the diff match it.
Review — [Babysit a PR](/loops/babysit-a-pr). The independent-review stage. A loop that watches the pull request, responds to feedback, and keeps the review moving — separate from whatever produced the code. Pair it with [Verify agent output before it ships](/loops/loop-harness-verification-loop), which is the maker/checker split as a loop: a second pass that inspects the first agent's output against hard signals before anything merges.
Release — [Ship when checks pass](/loops/ship-when-checks-pass). The release gate as machinery. Nothing ships on the agent's opinion of readiness; it ships when CI is green, and the green run *is* the release evidence.
The stop condition — [Run zero-config stop gate](/loops/run-zero-config-stop-gate). Every bounded cycle needs an objective exit. This loop is the pattern in miniature: a gate the agent cannot argue with, so "done" is a fact about the world rather than a feeling the model has.
Run them separately and you have five useful loops. Chain them — plan file feeds work, work feeds review, review feeds the release gate — and you have a harness.
Why the harness is the safety story
The safety argument for this pattern is that every failure mode of unattended agents is a missing stage.
An agent with no plan file re-derives its goal every run, and re-derivation is where drift enters. An agent that grades its own work exhibits exactly the self-preferential bias you'd expect — writer/checker separation exists because verification based on hard signals (tests, type checks, builds, linters, explicit rubrics) is trustworthy and self-assessment is not. An agent with no release gate ships when it *believes* it's done, and belief is not a stopping condition. A loop with a soft exit and no verifier doesn't fail loudly — it fails quietly and keeps spending.
The harness fixes these structurally rather than behaviorally. You're not asking the model to be careful; you're building a pipeline where carelessness can't propagate past the next gate. Budgets, gates, and evidence enforced by machinery, not by prompt-engineering the word "please."
That's also why the pattern scales down. You don't need the full four stages on day one. A plan file plus one hard gate is already a harness — a small one, but the structure is right, and every stage you add later has somewhere to bolt on.
Build the cycle
The [loop builder](/builder) will scaffold this for you: pick a goal, an exit condition, a budget, and guardrails, and it hands back a harness you can run tonight — including the state file and the gate, so the Plan and Release stages exist from the first run. Start with one stage, prove it on a manual run, then wrap it in a schedule.
And when the cycle finishes — or hits a gate it can't pass — the loop should tell you, not wait for you to notice. ConnectMyEmail gives your agent an email address for exactly that: the review stage reports in, the release stage confirms what shipped, and you stay out of the loop until it needs you.