Problem
One coding agent is easy to supervise. Several at once fail in predictable ways. Two edit the same file. A worker's tests pass, but the bug sits in a case its brief never mentioned. A fix is reported as done and only partly works. Someone restarts the live service mid-task. An evaluation label quietly changes to fit the model's output. Decisions vanish into chat history.
The kit answers each of these with a rule and, where possible, with code that enforces it.
What I did
I did not design it up front. I pulled it together from what worked, and what went wrong, on CrateDigger (a record-buying assistant built feature by feature by parallel agents) and the code-review round on reelkit (a video pipeline). Each time something went wrong, I added a guard for it.
I directed how the method evolved: how the lead agent talks to me, independent review, bounded tasks, which model takes which kind of task, and which decisions stay with me. I also did the acceptance testing. AI agents (Claude Code and Codex) wrote the scripts, templates and skills. I wrote the requirements with an LLM and made the calls.
How it works
The kit has two parts: a lead skill that plans, briefs, reviews and commits, and a project template of make commands, git hooks and shared instructions that turn the rules into code.
- One lead. The lead agent is my single point of contact. It learns each project's own commands and rules, writes one brief per task (owned files, contracts between tasks, acceptance checks, failure cases to test), starts the workers, reads every diff and runs the full test suite.
- Workers in their own worktrees. Each task gets a git worktree, a branch, a test port and a
TASK.mdbrief. Workers never commit. They write a report and the lead commits. Every message between agents starts with the sender's name, because text typed into a terminal pane looks like me typing. - A reviewer from another provider. When the workers are Claude, Codex reviews the plan and the merged work, then re-reviews the fixes, because "the code changed" does not mean "fixed".
- Code for what must always happen. The pre-commit hook runs the tests and refuses changes to protected files, such as evaluation labels, unless I approve them.
make deployrefuses a dirty tree or failing tests, checks that the service answers and logs the commit, and runs only on my go-ahead. Decisions go into an append-only log.
The rule of thumb behind the split: what must always happen goes in code, steps that need judgement go in a skill, and facts and rules go in AGENTS.md, one short file every agent harness reads.
A task from start to finish looks like this:
make worker NAME=fix-search TIER=medium # worktree, branch, test port and an agent in its own terminal tab
make status # what is live, every worktree, its task and owner, uncommitted changes
make finish NAME=fix-search # remove the worktree and branch once mergedChoosing models by replaying old tasks
The most expensive model is not needed for every task. To decide, I replayed three finished CrateDigger tasks with cheaper worker models, in a clone that ends at each task's starting point so the reference answer is out of reach. Each run is graded against the reviewed, merged work on five gates: the hidden reference tests, the whole suite, real-data output equal to the reference, scope, and a blind review.
A cheaper model is adopted for a kind of task only if it passes every gate over two runs. These are the results as recorded in CrateDigger's decision log (18 October 2026):
| Worker model | Runs passed | Note |
|---|---|---|
| Claude Haiku 5.5, effort high | 6 of 6 | |
| Claude Sonnet 5.5, effort medium | 6 of 6 | |
| Codex gpt-6-luna, effort high | 6 of 7 | One real defect: a record without a year rendered "Undated ()" |
| Codex gpt-6-sol, effort medium | 5 of 6 | One real defect: musicians not ordered lead-first |
From this I set three tiers. Simple, exact-spec changes go to Codex luna. Medium tasks (a feature or fix of up to a few hundred lines, with a written contract and lead review) go to Haiku, or Sonnet when speed matters or the spec is looser. Complex or open-ended work goes to Claude Opus. A worker that fails its tests twice, keeps asking about the spec, or has a correctness bug found in review is restarted one tier up.
This site was built with it
The portfolio you are reading started from the kit: its AGENTS.md, hooks, decision log and make commands came from install.sh. For Stage 1, two Claude workers ran in parallel worktrees, one on the layout and visual identity and one on the web-sized images. The lead, a Claude Opus agent, merged each branch, and the git log shows both merges. The page you are on was written by a worker in its own worktree under the same rules.
Results and limits
What the record supports:
- Haiku and Sonnet each passed 6 of 6 replay runs and Codex luna 6 of 7, so routine CrateDigger tasks moved off the most expensive model.
- Every bug the lead stopped in review had passed the worker's own tests. That is why briefs now list failure cases and the lead reads every diff in full.
- In the reelkit review, the second round found two fixes that only partly worked: a lock check that ignored later edits, and a filename collision that had only moved one step down the pipeline. Both became a follow-up task.
- The kit tests itself:
make testinstalls it into a temporary project and runs a task through to finish, on Linux and macOS.
This is personal tooling, used on my own projects. I have no figures for adoption by others, time saved or defect rates, and I do not claim any. The replays cover three tasks from one project. In the replay log, the blind review for most runs is still marked pending. The kit as it stands was extracted from CrateDigger and reelkit, so it did not build them from the outset.