●  Agent loops \u00b7 build until green \u00b7 copy-paste playbook
EST. 20241 makerBuilt in public
Agent loop \u00b7 Fix loop \u00b7 6 steps

Build Until Green
run it green.

For the messy middle of a change, when the compiler or bundler is red and you want a tight fix-and-rerun cycle that stops only when the build passes clean.

Typical run: 10–30 min typical \u00b7 Copy any prompt box and hand it to your agent as-is.

Loops / Build Until Green

\u00a7 01

When to use

6 steps10–30 min typical
  • The build broke after a refactor, dependency bump, or merge, and the error list is longer than one screen.
  • You want your agent to fix errors one at a time instead of rewriting half the codebase in one shot.
  • Type errors, lint errors, or bundler failures block everything else you planned to do.
  • You can already build locally, so each fix can be verified in seconds.
\u00a7 02

The steps

one prompt per stepcopy \u00b7 paste \u00b7 run
01Freeze the starting line
Run npm run build (or your build command) once with no code changes. Save the complete log to build-baseline.log. Report the error count and the first error verbatim, then stop. Do not fix anything yet.
Why: A saved baseline proves later that the loop actually moved the error count to zero.
02Fix only the first error
Read build-baseline.log. Fix ONLY the first error. Do not touch unrelated files. Explain the fix in one sentence, then stop.
Why: One error at a time keeps fixes reviewable and stops cascading guesses.
03Re-run and compare
Run the build again and save the log to build-02.log (then build-03.log, and so on). Report: errors fixed, errors remaining, and the new first error. Stop after reporting.
Why: Each cycle needs fresh evidence, not memory of the last run.
04Quarantine new errors
Compare the latest build log against the previous one. If any NEW error appeared, revert the last change and try a smaller fix for the same error. Stop after reporting the comparison.
Why: Fixes that add new errors are going backwards — catch that immediately.
05Confirm green twice
Run the build twice in a row with no code changes between runs. Both must pass with zero errors and zero warnings treated as errors. Paste both exit codes, then stop.
Why: One green run can be luck or cache — two in a row is a signal.
06Write the loop note
Write a 5-line summary: what broke, what fixed it, which files changed, how many cycles it took, and what to watch next time. Keep it under 120 words, then stop.
Why: A short note turns a fixed build into a repeatable habit.
\u00a7 03

Stop conditions

exit criteria
  • Build exits 0 twice in a row with no code changes between runs.
  • Error count reaches zero and stays there; the baseline log and the final log are both saved.
  • No new warnings introduced versus the baseline (or new warnings are listed and accepted).
\u00a7 04

Failure modes

what goes wrong + guardrail

The agent rewrites everything

Symptom: a one-line type error turns into a 12-file refactor. Guardrail: forbid touching more than 3 files per cycle and require the error log quote in every reply.

Cache hides the real state

Symptom: green locally, red in CI. Guardrail: one cycle must be a clean build (clear cache / fresh install) before you declare victory.

Warnings pile up silently

Symptom: zero errors but 40 new warnings. Guardrail: treat warnings as errors for the loop, or list every new warning in the loop note for explicit sign-off.

\u00a7 05

More loops

5 playbooks
\u2190 All loopsmosaic/lab \u00b7 agent loops
Build Until Green → Coverage Until Threshold → A11y Audit Until Clean → CI Failure Watcher → Plan Then Execute →