Loop Readiness

Decide whether a task should become a loop before building one. A loop that misses a condition costs more than it returns — the honest default is "keep it manual."

The 4-condition test (strategic)

All four must hold:

Miss one → verdict: keep it manual.

The 5-point checklist (tactical, per task)

1. Happens at least weekly.
2. An objective gate (test, typecheck, build, lint) rejects bad output — a second agent asked to "review" is just a second optimist.
3. The agent can run the code it changes.
4. A hard stop exists: token budget, iteration count, or time limit. Without one, the loop runs until someone notices the bill.
5. A human reviews before merge, deploy, or dependency changes.

Good first loops vs bad

Good: CI failure triage, dependency bump PRs, lint-and-fix passes, flaky test reproduction, issue→PR drafts on well-tested code. (Test: could a junior do it from a checklist, with a test suite catching their mistakes?)

Bad — human stays in the chair: architecture rewrites, auth/payments code, production deploys, vague product work, anything where "done" is a judgment call.

Build order (if verdict is "build")

1. Get one manual run reliable.
2. Turn it into a skill (SKILL.md).
3. Add a state file (see /loop-state).
4. Wrap it in a loop with the gate and hard stop.
5. Then schedule it.

Skipping ahead is how loops fail in production.

Verdict format

Task: <one line>
4-condition test: <pass | FAIL on #n — reason>
Checklist: <5/5 | which boxes missed>
Verdict: BUILD | KEEP MANUAL | FIX FIRST (<precondition>)
If BUILD — gate: <command> | hard stop: <limit> | cadence: <interval>