First, Get Clear: What Exactly Is a "Loop"

The official definition is a single sentence: a loop is an agent repeatedly executing rounds of work until some stopping condition is met. The key distinction is that "when it's considered done" is defined in advance and left to the system to judge — not something you personally chase round after round.

The authors classify loops along four dimensions, and these four dimensions form the shared reference frame for every loop type that follows: who triggers it, how it decides it should stop, which feature in Claude Code implements it, and what kind of task it suits best. Set up the coordinate system first, and then the four loop types slot right in.

The authors also note: not every task needs a complex loop — start from the simplest option, and pick up these patterns as needed.

You Ask, It Does One Round

This is the default mode you use every day. Every prompt you send kicks off a loop where you personally steer each round: Claude gathers context, makes the change, checks its own work, repeats if needed, and then reports back. Officially, this is called the "agentic loop."

An example from the original piece: you ask Claude to build a like button. It reads your code, edits the files, runs the tests, then hands back something it "believes" works. From there, you manually verify it and write the next prompt. What triggers it is a single prompt; the call on when to stop sits with Claude itself; it suits short tasks that don't belong to a fixed process and don't run on a schedule.

How to Make Its Self-Checks More Thorough

You can strengthen the "verification" step: turn the steps you normally check by hand into a SKILL.md, so Claude can check more things end-to-end on its own. The key is giving it tools or connectors that let it see, measure, and act — the more quantifiable the check, the easier it is for Claude to self-verify, and the fewer rounds it needs.

The original piece gives a verify-frontend-change skill: for any frontend change, it's not allowed to declare the job done just because the edit succeeded — it has to walk through the whole process the way a human reviewer would.

1. Start the dev server, open the changed page in the browser
2. Interact with the change directly: click the button, confirm the state change, screenshot before/after
3. Check the browser console: zero new errors or warnings allowed
4. Run a performance trace with Chrome DevTools MCP, audit Core Web Vitals

If any step fails, fix it and rerun from step 1 — never hand back partially finished work.

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---

# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:

1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button,
   input, toggle): click it, confirm the expected state change,
   and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit
   Core Web Vitals.

If any step fails, fix the issue and rerun from step 1 — do
not hand back partially verified work.

Set the "Passing Bar" First — Only Then Can It Stop

Sometimes one round isn't enough, especially for complex tasks — agents perform better when they're allowed to iterate. You can use /goal to clearly define "what counts as done," extending how long Claude gets to iterate.

In other words, the power to decide gets taken out of Claude's hands and handed to a dedicated evaluator model. This is also why "deterministic criteria" work especially well — things like the number of passing tests or clearing a specific score threshold — the evaluator model can check them off unambiguously, with no ambiguity.

A concrete example:

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Goal-based loops suit tasks with a verifiable exit criterion; what you hand over is a "stopping condition," and the feature that implements it is /goal. To manage cost: make both the success criterion and the retry cap specific — e.g., "stop after 5 tries."

Check In On a Schedule

Some work is periodic: the task itself stays the same and only the input changes — like rounding up Slack messages every morning. Other work depends on an external system, and the simplest way to hook into it is to check in at a fixed interval and react to whatever changed — like a PR that might get review comments or might have CI fail.

This class of work is triggered with /loop, which reruns a prompt at a set interval. It stops when you cancel it, or when the work is done (the PR gets merged, the queue empties). Example:

/loop 5m check my PR, address review comments, and fix failing CI

Stack Five Features and It Runs Itself, Unmanaged

Take the earlier primitives, add auto mode (auto mode — doesn't stop at every step to ask whether to continue) and dynamic workflows (dynamic orchestration across agents, research preview), and you get a loop that can be combined to handle long-running work. What triggers it is an event or a schedule, with no one present in real time at all.

A proactive loop's stopping logic has two layers: each individual task exits once it hits its own goal, while the routine itself keeps running until you manually shut it down. It best suits recurring, clearly-defined workflows: bug reports, issue triage, migrations, dependency upgrades, and the like.

Put together, a complete prompt looks like this:

/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged,
actioned, and responded to. When fixing a bug, use a workflow to
explore three solutions in parallel worktrees and have a judge
adversarially review them.

In plain terms: every hour, check the #project-feedback channel for bug reports; for every one found this run, don't stop until it's been triaged, actioned, and responded to; when fixing a given bug, use a workflow that tries three solutions in parallel across three separate branches (worktrees), then has a judge agent adversarially pick them apart. Here, dynamic workflows can spin up on the order of hundreds of sub-agents in a single run, working in parallel and coordinating with each other.

To manage cost: hand the routine off to a smaller, faster model, and only bring in the strongest model at the key decision points that actually need it.

Don't Let the Loop Drift Off Course

The quality of a loop's output depends on the system around it. When designing that system, the official post gives four rules:

• Keep the codebase itself clean

  Claude follows the patterns and conventions already in your codebase — if the foundation is clean, what it produces following that foundation will be clean too.

• Give Claude a way to self-check

  Codify "what counts as good" into skills as a shared standard for you and your team, so it can check its own work end-to-end.

• Keep documentation within reach

  A framework or library's official docs carry the latest best practices — don't make it guess from stale memory.

• Use a second agent for code review

  A reviewer starting from a fresh context has fewer biases and isn't influenced by the main agent's reasoning. You can use the built-in /code-review, or hook up GitHub's Code Review.

Don't Let a Loop Quietly Burn Through Your Tokens

To keep tokens under control, a loop needs clear boundaries. The original piece gives a six-item, actionable checklist:

Which Loop to Pick — One Table Says It All

Facing a concrete task, you need to think through three things: what you hand over, when to use it, and which feature to use. The original piece's summary table lines up the four loop levels row by row for comparison — click into each card for a concrete example.

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

/loop 5m check my PR, address review comments, and fix failing CI

/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged,
actioned, and responded to. When fixing a bug, use a workflow to
explore three solutions in parallel worktrees and have a judge
adversarially review them.

Once you have an idea, get the loop running, watch where it gets stuck or oversteps, and iterate on it from there.

This isn't a new product launch. What the team did was take 5 features that already existed (/goal, /loop, /schedule, dynamic workflows, auto mode) and organize them into a 4-level loop system ranked by "degree of autonomy," with combination templates you can copy directly.

So the question becomes: without you watching, what actually decides "time to stop"? That's exactly where the four levels differ.

Take the same job — XiaoHu needs to handle a steady stream of bug reports — and see how the four loop levels each run it. The difference comes down to just two things: who shouts "go," and who decides "stop."

What a loop saves isn't machine time — it's "the number of times XiaoHu has to watch the screen." For the same recurring job (handling new bug reports every hour), here's how the old and new approaches compare:

Two token-saving (AI billing unit) principles worth remembering too: hand deterministic steps to a script rather than making Claude re-derive them each time; and when a given result falls short, fix the system's rules so every future round benefits, rather than just patching this one instance.

All figures above come from the definitions and examples in Anthropic's official blog post (/schedule and dynamic workflows are both marked as research preview features) — there's no third-party reproduction.