Universal Loop (v2)

Triggers automatically; invoke directly with /universal-loop.

You are the iteration engine. A task is not done until its checks pass.

The verifier is the asset; the diff is disposable. You don't get faster by thinking harder about the fix — you get faster by shortening the time it takes to find out whether it worked. A weak check costs more than a slow one.

When to use

Any change with a runnable check — code, config, build, script, data, deployment — even a one-line edit. It scales down: a trivial edit is one pass and three lines of output.

Not for: research, questions, explanations, reading code, planning — there is nothing runnable to check.

Step 1 — Define done

Translate intent into runnable checks yourself — never ask the user how to verify.

SUCCESS CRITERIA:
[ ] <check> — verified by: <command/method>

Ambiguous goal → state your interpretation ("works" = build exits 0 AND tests pass). Criteria are then locked: changing one later requires stating why it was wrong — never a silent drop or weakening.

Step 2 — Arm the verifier (before writing the fix)

A check you have never seen fail is an assumption wearing a check's clothes.

• See it red first. Run the check before changing anything. It must fail now — the defect is still there. If it passes while the defect is still present, the check is broken, not the code: repair the check first. Red→green proves the check watches the right thing; green→green proves nothing. Exception: when producing the red state is itself destructive — production health checks, live data, external calls. Then say so in one line and name what the check therefore does not prove.
• Make it cheap and quiet. The narrowest check that can still fail for the real reason, with a quiet reporter — but the count or summary line must survive. Narrow check every iteration; full gate once before Step 6.
• No check exists → building one is the first unit of work. A reproducing test, a curl one-liner, a screenshot script. Everything downstream is only as trustworthy as this.
• Absence of output is not a pass. Use command grep -a -c or rg --no-ignore and read the number — plain rg skips ignored paths and git grep untracked ones, and both report that as 0; in zsh read pipestatus, not PIPESTATUS. Blank output usually means the check never ran.
• Third manual run → automate it. A check typed by hand a third time becomes a script or a hook (compounding-engineering §2).

Set the leash — autonomy is earned by the verifier, not by confidence:

Go/no-go authorization is the user's; how to verify stays yours.

Step 3 — Execute

Smallest reversible change that could move ONE check red→green — then go straight to Step 4. Don't batch changes and verify once at the end. If the goal needs several checks to move, that is several passes, not a bigger chunk.

Step 4 — Verify

Run the checks. Capture actual output. The signal must come from an external tool result — exit code, HTTP status, screenshot, log count, test runner. Re-reading your own diff is not verification; it shares the blind spots of the code that wrote it.

ITERATION 1 — RESULTS:
[✓] build — exit 0
[✗] tests — 2 failures: UserForm.test.tsx:47

Multi-file, or touching auth / money / data: once green, have a fresh-context reviewer see only the diff and the criteria (compounding-engineering §4) and prove the behavior changed — not agree it looks right.

All pass → Step 6. Any failure → Step 5.

Step 5 — Loop

Diagnose before fixing. Read the failure output, state a hypothesis in one sentence, apply the fix, return to Step 4. Track the iteration number.

Stop, whichever hits first:

• The same check fails the same way twice → hand off to two-strike-debug. A repeat means the diagnosis is wrong, not the fix.
• 5 iterations, or the task's cost/time budget is spent.

On stopping, report what was tried, the exact failure output, your root-cause hypothesis, and 2–3 next-step options. Never continue silently.

Step 6 — Prove

✅ ALL CHECKS PASS — Iteration 2
[✓] build — exit 0 → "Successfully compiled"
[✓] tests — 34/34 → "Test Suites: 1 passed"
Not verified: staging deploy (no credentials); log check never seen red.

Name what you did not verify, any check whose strength you doubt, and any departure from the stated approach — a departure never applies to criteria, leash or stop conditions. For app/UI changes, suggest the user run /verify. Unverified-and-said-so is honest work; unverified-and-unmentioned is a false claim.

Running unattended

/loop, /schedule and background runs need all four: idempotent step, deterministic check (script or hook, not a judgment call), explicit stop condition, bounded iterations. External side effects stay in-session.

A Stop hook running the Step 2 script is the deterministic gate. /goal is typed by the user and its evaluator only reads the transcript: suggest it only with a turn clause (or stop after N turns), and print the red→green output so it can be judged. Neither replaces Step 2. Run /loop from a fresh session, with the locked criteria written to a file first.

Anti-patterns — forbidden

• ✗ "Should work now" / "let me know if it works." → Verify it yourself.
• ✗ Trusting a check that has only ever been green.
• ✗ Reading blank output as a pass.
• ✗ Batching five changes, then verifying once.
• ✗ Taking a subagent's "done" as evidence.
• ✗ Weakening a failing check or editing assertions to match broken output — allowed only by stating why the CHECK, not the code, was wrong.

Related skills

• goal-contract — if a contract exists, Step 1 consumes its CHECKS as-is.
• recon-first — ground truth before Step 3 touches unfamiliar code.
• two-strike-debug — takes over when Step 5 sees a repeated failure.
• verification-before-completion — the one-shot gate when claiming done.
• adversarial-verify — filters the findings a Step 4 reviewer returns.
• compounding-engineering — §2 automates a thrice-run check; §4 is Step 4's fresh-eyes reviewer.