Stop Re-Prompting: How /loop Lets Claude Code Grind a Task Until It Passes

You know the rhythm. Claude makes a change, you run the test suite, something fails, you paste the error back, Claude fixes it, you run the suite again. Five rounds later it passes. Every one of those rounds was you acting as a relay between a validator and the model. That is the job /loop takes off your hands.

/loop is a built-in Claude Code command. You give it a task or another slash command, and Claude runs it, checks whether a stop condition is met, and if not, runs again. It keeps going on its own until the condition passes or you stop it. The whole point is to remove you from the retry cycle when the cycle is mechanical and the success check is something a machine can read.

Why this beats re-prompting by hand

When you re-prompt manually, you are the bottleneck. You have to be at the keyboard, you have to notice the failure, and you have to decide whether to try again. /loop closes that gap. It shines when the success condition is deterministic and local, meaning a command on your machine exits clean or returns the output you expect. A linter passing, a test file going green, a build completing, a custom validation script printing OK. Those are perfect loop targets because the model has an unambiguous signal for done.

It also works for light monitoring. You can point it at a recurring check, like polling a deploy or watching a status endpoint, and let it report back across intervals instead of you refreshing a terminal. Keep monitoring loops at low frequency. Tight intervals burn tokens and bloat your context for little gain.

How to run it

1. 1Pick a task with a clear, checkable finish line. 'Make the test suite in tests/ pass' is good. 'Improve the code' is not, because there is no objective stop point.
2. 2State the stop condition in plain language as part of the prompt: which command should pass, what output means done, and what counts as failure.
3. 3Set a hard cap on iterations in your instruction, for example 'stop after 5 attempts'. This prevents an unsolvable task from looping indefinitely.
4. 4Run /loop with your prompt or a slash command. Omit an interval to let Claude pace itself between iterations, or give one for time-based polling.
5. 5Watch the first couple of rounds. If it is making real progress, let it run. If it is thrashing on the same failure, stop it and fix the prompt or the underlying problem yourself.

When not to point it at something

A loop will repeat whatever you aim it at, including actions you cannot take back. That is the one rule that matters most. Never point /loop at anything irreversible or external.

• No publishing, sending, or posting. A loop that emails or posts on each pass can fire the same action many times before you catch it.
• No payments, charges, or anything that moves money. There is no undo on a transaction.
• No credential changes, deploys to production, or writes to systems of record. Keep loops on local, reversible work.
• Always set a max-iteration cap. An open-ended loop on an unsolvable task wastes tokens and pollutes your context.
• Treat loops as session-scoped and temporary. For durable automation that must survive restarts or run unattended, use a real scheduler, not a chat loop.

The mental model is simple. /loop is a tight harness around a local validator you trust. Inside that box, let it grind so you do not have to. Outside that box, where an action sends, charges, or publishes, keep a human in the loop and approve each step yourself. Credit to the Claude Code team for shipping this as a first-class command. It removes a real chore, as long as you respect the box.