michi-loop

The loop skill runs a task as an autonomous, lights-off loop — the agent works unattended, checks its own output against a verifier, and stops on a defined condition — with Michi discipline around it. It is the convergent + autonomous lane: the sibling of michi-expedition (emergent + Entrusted-spiral), on the other side of the routing question “which form of verification can you answer?”

The skill is discipline over mechanism. It does not run the loop; Claude Code already ships the runners (/loop, /goal, claude -p, Workflow). What it adds is the judgment the loop-engineering literature skips: have you earned lights-off, what does “done” mean, what checks the work, and when does it stop?

When to use

• The work is convergent — you can finish the sentence “this is done when ___” with measurable criteria
• The verifier is trustworthy — a real check (tests, build gates, an independent reviewer), not the agent’s say-so
• The blast radius is reversible — a container, a worktree, a branch
• Autonomy has been earned — you’ve watched this kind of work go well Paired

Don’t use it when the work is exploratory or the end isn’t knowable — that’s an expedition. Don’t use it when the only verifier is human visual judgment with no automatable floor — a loop can’t see the screen.

What it does

The skill walks seven steps with you — the first five are pre-flight (lights on), Launch hands off to the mechanism (lights off), and Review brings the lights back:

1. Gate — should this be a loop at all? Reads earned autonomy and which form of verification you can answer.
2. Contract — the measurable goal, allowed actions, the isolation that makes a bad pass reversible, and the control surface (how you’ll see progress and how you’ll interrupt).
3. Verifier — the check with teeth. Mechanical authority first (a Stop hook, /goal, a test gate); independent judgment second (a fresh-context reviewer, holdout scenarios). Unverifiable = not done.
4. Stop conditions — iteration ceiling, no-progress detection, budget cap. A loop without a stop is a runaway.
5. Readiness — the shopping list. Every dependency needed to build and to verify, confirmed present in the target environment before launch. There is no human mid-loop to notice a missing ingredient.
6. Launch & supervise — the runner choice and the go-ahead are the human’s call (default /goal — harness-enforced). The loop body runs under Michi discipline, not raw.
7. Review — lights back on. Verified done or abort; either way, review against the contract and close with a debrief so the learnings land.

Key things to know

• The verifier must be something the agent cannot talk its way past. A loop graded by its own author’s self-assessment has no gate. Verification governs autonomy — the loop’s reach is bounded by what the verifier actually catches.
• Unverifiable = not done. If the environment can’t exercise a done-criterion (a missing service, queue, browser, fixture), that criterion is an open hole — flagged and failed, never rationalized into a pass.
• The human owns the launch. The runner sets who enforces the gate, so it’s never the agent’s silent decision.
• Lights-off is not blind or unstoppable. Decide the monitor you’ll check and the halt you’ll use before walking away.
• Surface-and-explore, you decide. The skill raises the readiness checks; it doesn’t police them. For experimental work, fail-fast is the point — the human makes the call.

For the full agent instructions, see the SKILL.md source.