Build loops like Claude Code's creator (copy-paste setup inside).

Everyone's telling you to stop prompting and build loops. Almost nobody shows you the setup the people who built Claude Code actually recommend: /goal, a separate verifier, worktree isolation, real stop conditions.

It's not a secret. It's just buried under a hundred "what is a loop" explainers.

So I built that setup, exactly as the creator's own guidance lays it out, and let it run for 7 days on a real backlog while I did other things. It cleared a week of work I'd been putting off: a flaky test suite went green, lint debt hit zero across ~40 files, a whole library got docstrings - mostly while I slept.

Here is the entire thing, copy-paste ready, plus the handful of settings that make the difference between a loop that ships and a loop that spins. Steal all of it.

Why this matters

A loop is the first setup that does real work without you sitting there. /goal sets a finish line, /loop drives toward it, a routine schedules it, auto mode removes the confirmations. Point it at a well-scoped task and it runs like a junior engineer who never tires.

Most loops disappoint not because of the model, but because people wing the harness - no verifier, no stop rule, no memory. The creators of Claude Code already worked out the shape that holds.

You don't have to rediscover it. You just copy it.

The setup, exactly

The finish line is a verifiable condition, not a vibe:

/goal every test in /tests/auth passes, lint is clean, zero type errors
/loop run the suite, read every failure, pick the single highest-impact one,
      write the smallest change that fixes it, re-run tests + lint + type check

/goal matters more than it looks. When Claude Code added it (v2.1.139, week of May 11 2026), the point wasn't the finish line, it was that a separate, faster model checks completion. The builder and the grader are different instances. That one design choice is why the loop can be trusted to run unwatched.

Put it on a schedule so it runs without you at the terminal:

/routines add auth-loop \
  --schedule "every 30 minutes" \
  --task "run /auth-fix-loop, append a one-line result to logs/loop.md"

Native routines run in the cloud; to run it on your own box against a private repo, wire the headless form into cron. Cron uses a minimal environment, so the binary path, the working directory, and a hard timeout all have to be explicit:

# /etc/cron.d/auth-loop — every 30 min, hard-killed at 8 minutes
*/30 * * * *  cd /home/me/proj && \
  timeout 8m /usr/local/bin/claude --print "/auth-fix-loop" \
  --allowedTools "Bash,Edit,Read" >> logs/loop.log 2>&1

Prefer a script you control? The same loop, headless, in Python handy when you want to gate each run on your own conditions and cap the spend:

import subprocess, time, json

BUDGET_USD, spent = 5.00, 0.0
for cycle in range(10):                     # hard cap: 10 cycles
    if spent >= BUDGET_USD:
        break
    r = subprocess.run(
        ["claude", "--print", "/auth-fix-loop", "--output-format", "json"],
        cwd="/home/me/proj", capture_output=True, text=True, timeout=480,
    )
    out = json.loads(r.stdout)
    spent += out.get("cost_usd", 0)
    if out.get("goal_met"):
        break
    time.sleep(1800)                        # 30 min between cycles

Two more touches complete the engine. Auto mode removes the per-action confirmations so it doesn't stop and wait for you on every file write - that's what makes "unattended" real. And a scoped allow-list keeps it safe while it's unattended: let it run tests and edit code, but never let it push or delete without you.

# .claude/settings.json — safe to leave running
{ "permissions": {
    "allow": ["Bash(pnpm test)", "Bash(pnpm lint)", "Edit", "Read"],
    "deny":  ["Bash(git push*)", "Bash(rm*)", "Edit(.env)"] } }

That's the whole engine. The rest is the four settings that make it reliable.

What it produced

I pointed it at a backlog I'd been avoiding for weeks and let it run. Over 7 days it did the boring, valuable work I never get to:

The moment: I woke on day 5 to a summary that the auth suite had gone from 11 failing tests to 0 overnight, each fix verified before the next one started. Lint debt dropped to zero across ~40 files. Every public function in one library got a docstring. None of it needed me in the loop.

The pattern: a loop is best at work that's clearly defined and genuinely tedious - the stuff that never reaches the top of your day because something more urgent always does. It doesn't replace your judgment; it clears the runway. A week in, the repo was measurably healthier - changelog written, a month-old flaky test gone - and I'd spent my actual hours on the feature work only I could do.

The four settings that make a loop reliable

1. A separate verifier - the single most important one.
The model that writes the code cannot be trusted to grade it. A different instance, one job, pass or fail with evidence, is what makes unattended runs safe.

The moment: on a migration cycle the writer reported "all tests pass" while it had skipped a file that threw on import. The separate verifier caught it on the next cycle. This is the whole reason the setup can run unattended: the writer is optimistic, the verifier is skeptical, and they never share a context. Write the verifier like a different job, not the same prompt with "check it" appended:

You are a verifier. You did not write this code.
GOAL: <the exact goal string>
Given the diff and the test output, answer ONLY:
  PASS  — every condition in GOAL is objectively met, with evidence, or
  FAIL: <the specific condition not met, and the evidence>
Do not fix anything. If unsure, FAIL.

2. A stop rule, so it never runs away.
Success or a hard cap — iterations, dollars, no-progress. This is what lets you leave it alone with confidence.

The moment: the day I added "after 2 failed attempts on the same step, log it and move on," the loop stopped chewing on the one thing it couldn't solve and started clearing everything it could.

STOP WHEN: verify passes, OR 10 cycles, OR $5 spent, OR no progress in 2 tries
ON BLOCKER: log it, skip to the next item, never halt the whole loop

3. A state file, so it remembers.
An external note - done, failed, next: re-read at the top of every run, turns a set of restarts into one continuous effort.

The moment: with state, an overnight run picked up exactly where the last one stopped instead of re-solving finished work. Memory is what turns a loop from a set of expensive restarts into one compounding effort. The file is small and structured on purpose, so it's cheap to read every cycle:

{
  "goal": "auth suite green, lint clean, zero type errors",
  "done":   ["fixed 11 auth tests", "lint clean /src/auth"],
  "failed": ["jwt-lib dep conflict — blocker, skipped"],
  "next":   ["docstrings for /lib public fns"]
}

4. Worktree isolation, so parallel work stays clean.
When the loop spins up more than one agent, each gets its own git checkout and they never overwrite each other.

The moment: switching parallel subagents to isolation: worktree turned a two-hour crawl on 40 files into twenty minutes with zero collisions.

The numbers

Over 7 days, one loop, one repo: ~340 cycles, ~90 accepted changes, ~$210 in tokens about, $2.30 per accepted change, and roughly $1.10 on the productive cycles. A separate verifier caught 14 completions the writer had wrongly marked done. Net: a week of real backlog cleared, mostly overnight, for the price of a couple of lunches.

Make it yours in ten minutes

Adapting the template to your repo is mostly find-and-replace. Three edits and you're running:

1. GOAL   -> your real finish line, as a checkable condition
             ("coverage >= 85% by pytest-cov", not "improve tests")
2. CYCLE  -> your commands (pnpm test, cargo check, make lint...)
3. BUDGET -> your ceiling (start low: 10 cycles or $5, then raise)

This is the fastest way to learn what your own repo responds to. Start with one small, safe task the first night - something where a wrong change is obvious and cheap to revert, like lint or docstrings. Watch one number: cost per accepted change. If it's low, widen the goal. If it's high, tighten the scope or the stop rule. Within a couple of runs you'll have a feel for which of your tasks are loop-shaped and which aren't.

When a loop is worth building

A loop earns its setup when all four are true. Miss one and a plain prompt wins:

the task runs at least weekly

"done" is objectively checkable (a test, a diff, a number)

verifying is cheaper than doing

the agent has the full context

The whole thing, to copy

GOAL:  every test in /tests/auth passes, lint clean, zero type errors
EACH CYCLE:
  1. run the suite, read every failure
  2. pick the single highest-impact failure
  3. write the smallest change that fixes it
  4. re-run tests + lint + type check
VERIFY:  a separate model checks the goal (never the writer)
STOP WHEN:  verify passes, OR 10 cycles, OR $5 spent, OR no progress in 2 tries
ON BLOCKER:  log it, skip to the next item, never halt the loop
STATE:  append done / failed / next to a file, re-inject each cycle
ISOLATION:  worktree per subagent

The mental model

A loop is cron plus a decision-maker plus a gate that says done. The cron part is old. The decision-maker is getting cheaper every month. The gate: a check the writer can't fudge is the whole craft, and it's exactly the part the creators of Claude Code already solved for you.

The shift the whole timeline is pointing at is real: the unit of work is moving from the prompt you type to the loop you leave running. But you don't have to invent that loop. The people who built the tool already shipped the shape that works, and it fits in one screen.

Copy the setup above, point it at one weekly, checkable task, and let it run tonight. You'll wake up to work you didn't have to do, and a repo that's quietly better than you left it.

That's the real promise behind all the loop talk, not that you stop thinking, but that the tedious, checkable part of the job runs itself on a schedule you set. The setup to get there isn't clever or secret. It's four small files and a goal, sitting right above this line, waiting to be copied.

T H E _ E N D

Everyone's talking about loops. Far fewer are running the setup the people who built the tool actually recommend and that setup is a copy-paste away, sitting right here.

A loop isn't a magic trick. It's a small, well-built machine: a clear goal, a verifier it can't fool, a stop rule, and a memory. Get those four right and it quietly clears the work you keep pushing to next week.

~340 cycles. ~90 changes shipped. ~$2.30 each.

A week of backlog, mostly done overnight while I slept, for the price of a couple of lunches.

If this setup is worth stealing, repost it so the next person can run one tonight too. The best time to build your first loop was last week. The second best is before you close this tab.

Bookmark this — the copy-paste loop setup is all in one place

Repost if this setup is worth stealing

Telegram for weekly agent build notes: https://t.me/aiXmnimi