How to Create Loops with Claude: From One-Shot Prompts to Designed Loops

Most people use Claude the way they'd use a search box: type a request, get an answer, move on. That works until the work doesn't fit in one sitting — the test suite that needs to go green, the backlog that needs draining, the review that needs a second pass tomorrow. At that point the question stops being "what should I prompt?" and becomes "what should I build so the prompting keeps happening without me?"

That shift — from writing prompts to designing loops — is the core of a loop-engineering explainer by MIKE (@mikenevermiss on X), and it matches what we see across every loop in this directory. The one-line version: a loop is not just a prompt. A prompt that runs once is a request. A loop needs four more things a request never has: a trigger, persistent memory, verification, and a stopping condition.

The four parts a prompt doesn't have

A trigger decides when the loop runs — a schedule, a failing check, a new item in a queue. Without one, "autonomous" just means "whenever you remember to paste the prompt again." A concrete example from the directory: Issue de-duplication sweep runs twice a week on a fixed /schedule, links likely duplicates with a comment and a label, and — by design — never closes anything itself.

Persistent memory is what lets run number five know what runs one through four did. The simplest implementation is also the standard one: a PROGRESS.md or STATE.md file in the repo. The agent forgets everything between runs; the file doesn't. Each run opens by reading state, closes by rewriting it — what's done, what's in flight, what's blocked. Complete PLAN.md until tests pass is the pattern in its purest form: the plan file is both the work queue and the memory, and the loop walks it until nothing is left unchecked.

Verification is where most first loops quietly fail. If the agent gets to decide whether its own work is done, it will decide "yes" — early and often. The fix is to base done-ness on hard signals the agent can't charm: tests, type checks, builds, linters, or an explicit scoring rubric. "The code looks correct" is not a signal. npm test exiting 0 is.

A stopping condition is the difference between a loop and a runaway. Every loop needs a line it cannot cross: an iteration cap, a budget, a state that means "done," or a gate that means "stop and ask a human." Get the build green is the pattern at its simplest: iterate on build errors until npm run build exits 0 — and stop after 10 turns no matter what.

Separate the writer from the checker

The single highest-leverage design decision in the source article is also the one beginners skip: don't ask one agent to grade its own work. A writer/checker split — one agent (or one pass) produces the change, a separate one verifies it — is safer than self-assessment for the same reason code review is safer than merging your own PR at midnight.

You can see the split running live in two directory loops. Review code changes until done is a pure checker: it finds and ranks issues, then hands you the verdict instead of pushing fixes. Ship verified code, one stage per agent goes further and gives every stage of the pipeline its own agent, so the one that implemented a slice is never the one that approves it.

If the writer and checker are the same model with the same context, you've built a rubber stamp with extra steps. Vary the context, vary the pass, or vary the model — but keep the roles apart.

Worktrees: parallelism without collisions

Once loops work, you'll want more than one running. Git worktrees are the boring, effective answer: each agent gets its own checkout of the same repo, so parallel loops can't stomp on each other's uncommitted changes. One worktree per loop, one branch per worktree, merge through the normal review gate. It's the same isolation discipline you'd apply to human contributors, applied to agents that type faster.

The safety gate is part of the design, not an add-on

Everything above compounds into one uncomfortable truth: a loop with a trigger, memory, and no verification is an unattended failure generator. The safety rails aren't something you bolt on after the loop "works" — they're what makes it a loop instead of a hazard.

The minimum harness for anything that runs unattended:

• Hard verification before any "done." Tests, builds, linters, or a rubric — never the agent's own opinion of its output.
• An explicit stopping condition. Iteration cap, budget cap, or a verified end state. If you can't name the line where it stops, it doesn't have one.
• A checker that isn't the writer. Independent review before anything merges, publishes, or sends.
• State you can audit. The STATE.md file isn't just memory — it's the flight recorder you'll read when a run goes sideways.
• Human gates on anything irreversible. Deploys, deletes, sends, and spends wait for a person.

Every loop in this directory carries a safety grade for exactly this reason: the prompt is the easy part, and the gate is the part that decides whether you'd let it run overnight.

Start with one loop, not a factory

The practical path out of prompting and into loop design is smaller than it sounds. Pick one task you already repeat, give it the four parts — trigger, memory file, hard verification, stopping condition — and run it manually a few times before you schedule it. Steal the structure from a loop that already works: start from Complete PLAN.md until tests pass if your work lives in a plan file, or Get the build green if your problem is agents declaring victory before the build actually passes.

When you're ready to wire yours up, the harness builder turns a loop idea into a bounded, gated prompt you can actually run — and if your loop needs to touch email, ConnectMyEmail gives agents a safe, gated way to do it.

Design the loop. Let the prompting take care of itself.

---

Source: "How to Create Loops with Claude" by MIKE, @mikenevermiss on X.