1. Polling too tight

The mistake: /loop 60s check the deploy for a deploy that takes 12 minutes.

Why it hurts: 11 wasted iterations, 10 unnecessary cache misses, no faster information.

Fix: Use dynamic mode, or pick an interval that matches the underlying state-change rate.

2. No stop condition

The mistake: /loop 5m check the CI. It runs forever, even after the build is long since finished.

Why it hurts: You forget about it. It keeps running. Tokens leak.

Fix: Always include a stop condition. "End when the build passes or fails." Dynamic mode will respect it.

3. No "only tell me" filter

The mistake: /loop 5m tail logs/app.log. You get the same 500 errors every iteration.

Why it hurts: Noise drowns out signal. You start ignoring the loop, which defeats the point.

Fix: Add a "report only new / changed" clause. "Only ping me on errors I have not seen before."

4. Non-idempotent side effects

The mistake: /loop 30m open a PR for any new lint warning. Run 1 opens a PR. Run 2 opens another. And another.

Why it hurts: Loops re-run. If your task creates artifacts, the second run will create duplicates unless you guard against it.

Fix: Make the task check for prior artifacts before creating new ones. "If a PR for this warning already exists, skip it."

5. Forgetting state across iterations

The mistake: Asking the loop to "compare to last time" without giving it a way to remember.

Why it hurts: Conversation history gets summarized. Claude does not always remember the previous iteration's exact output.

Fix: Write fingerprints/state to a scratch file at the end of each iteration. Read them back at the start of the next.

6. Wrapping a giant task

The mistake: /loop 1h run the full integration test suite, deploy if green, post results to Slack, then summarize for the weekly report.

Why it hurts: Long iterations are expensive, brittle, and hard to debug.

Fix: One loop, one job. Compose with skills if needed. Each loop iteration should do one coherent thing.

7. Using /loop when you meant /schedule

The mistake: "I want a morning brief at 8am every day" — and then setting it up as a /loop 24h.

Why it hurts: Local loops die when you close the session. Your brief stops appearing on the day you forget to leave Claude Code running.

Fix: Use /schedule for anything that should run unattended. /loop is for things you want to monitor in the moment.

One sentence summary: Specific task, "only new" filter, explicit stop condition, scratch-file memory, idempotent side effects. If your loop has all five, it will not become a noise machine.

Related reads