This is the whole loop, the real one: what reads a task, what decides it's ready, what writes the code, and what happens when it isn't ready yet.
If you can build this from the description below, you don't need the install. If you'd rather have it running tonight, that's what the install is for.
The loop
Read it top to bottom on a phone. Left to right on anything wider.
What each stage actually does
The task is a card in a queue, one card at a time, small enough to land as one reviewable PR.
The context agent reads the task and reads the code around it: the files it touches, the patterns already in use, whatever decisions were already made and recorded somewhere. It's building the picture an execution agent would need before it could safely write a single line.
The readiness score is what the context agent produces at the end of that pass: a number, scored against a rubric of how complete the task description is, how many open questions remain, and how much of the relevant code has actually been read. Scored against the work still required, the way a sprint board reading 100% complete usually isn't.
The gate sits at 85%. Below that, the loop doesn't execute. It writes specific questions back to the task and waits for a person to answer them. At or above it, the loop can tell a real blocker (a fact only you hold, a task that's genuinely malformed) apart from a triviality it can decide for itself and note in the PR. That distinction is what makes running unattended safe instead of reckless.
The execution agent only sees tasks that cleared the gate. It writes the diff, runs the tests, opens the PR.
The PR is the audit trail. It says what changed, why, and which small calls got made along the way, so review takes minutes, not archaeology.
Human review is the last stage, and it's the one that decides whether any of the rest matters. A PR nobody reads sits there as a diff with a green checkmark on it, whether or not the work behind it is any good. Reviewing AI output is a contract, and this is where you sign it.
Cadence: one an hour, not one a minute
The obvious move, once a loop like this exists, is to run it as fast as possible. More fires, more PRs, more throughput. That's the wrong move.
The ceiling on this system is how many PRs one person can actually read in a day: understand what changed, catch the thing that looks fine but isn't, decide to merge or send it back. Queue twenty tasks overnight and the tempting picture is twenty PRs waiting at 9am. A well-calibrated loop executes one, waits for review, then moves to the next, turning twenty queued tasks into a paced stream instead of a pile you skim half of.
Cadence here is a ceiling on how fast the system is allowed to go, set by what a human reviewer can keep up with, calibrated to that constraint and held there on purpose.
Where it breaks
Say these plainly, because they're what make the rest of this credible.
The machine sleeps. A laptop closes, a scheduled process doesn't fire, and the queue sits untouched until someone notices. The fix is a heartbeat check, not a promise that it won't happen.
The queue runs dry. No tasks above the gate means no PRs, and an empty queue looks identical to a broken loop from the outside. The fix is checking the queue, not just the output.
PRs pile up. If review can't keep pace with execution for a stretch, a fixed cadence still produces more open PRs than one person can hold in their head. The loop needs backpressure: pause firing when the review queue crosses a threshold, don't just keep executing into it.
A task was never ready. Sometimes a task clears the score and still turns out to be underspecified in a way the rubric didn't catch. The gate cuts the failure rate. It doesn't take it to zero. That's what review is for.
None of these are hypothetical. They're the failure modes you'd hit building this yourself, and the ones the install already handles.
Want an install instead of building it yourself?
Be a founding member for €29.
Become a founding member for €29