Mastering Claude Code /loop: Turning Fragmented Tasks into Automated Workflows

After a first serious look at Claude Code's /loop, the author describes it as a form of "fragmented automation" that behaves like a small observer in a CI/CD pipeline, handling repetitive, low‑cost checks without constant human attention.

What /loop Does

/loop

wakes up after a delay, checks a specified condition, returns evidence if something changed, gives a short reply if nothing changed, and stops when it encounters credentials, production configuration, or other boundary issues, handing control back to the user.

Version Requirement and Basic Syntax

Claude Code version v2.1.72 or higher is required. Basic commands include:

/loop 5m check if the deployment finished and tell me what happened

which means “run this prompt every 5 minutes and report the deployment status.”

/loop check whether CI passed and address any review comments

When no interval is given, Claude decides the next wait time based on how quickly the state changes. An empty run /loop uses a built‑in maintenance prompt to handle pending tasks such as PR comments, failed CI, or merge conflicts. A default prompt can be stored in .claude/loop.md (project level) or ~/.claude/loop.md (user level).

Usage Patterns

/loop 5m <prompt>

– use when you know the exact interval. /loop <prompt> – let Claude choose the interval based on state changes. /loop – rely on the default maintenance prompt for the current session.

Tasks started with /loop belong to the current session; a new session clears them. The --resume or --continue flags can restore unexpired tasks, which automatically expire after seven days. For long‑running, unattended jobs (e.g., nightly reports), use Routines, Desktop scheduled tasks, GitHub Actions, or a custom scheduler instead of /loop.

Runtime Details

/loop

only triggers while Claude Code is running and the session is alive.

If Claude is replying, the scheduled turn is queued and runs after the current turn finishes.

Missed triggers are not replayed en masse; they run once when the agent becomes idle.

Fixed‑interval tasks have slight jitter and are not suitable for second‑level precision.

You can query or cancel tasks with commands like what scheduled tasks do I have? or cancel the deploy check job.

Press Esc during the next wake‑up to stop further executions.

Practical Advice

Use /loop for tasks that are cheap to check, have clear evidence (exit codes, job status, comments, queue depth), and can be safely stopped for human review. Store a tiny JSON state file to avoid re‑explaining context each round, for example:

{
  "status": "idle",
  "last_check_time": "2026-06-30T10:00:00+08:00",
  "last_evidence": [],
  "blocked_reason": null,
  "check_count": 3
}

The agent reads this file on each wake‑up, decides whether to perform a lightweight check or a deeper analysis, and updates it with new evidence.

Results are categorized as: changed – state changed, report evidence. no_change – no new evidence, short reply. blocked – credentials, production config, or other boundary; stop for human. done – goal satisfied, summarize and stop.

Prompt Design as a Small Card

A good /loop prompt is concise and covers five parts: state, scope, evidence, action, and stop conditions. Example:

/loop 30m
You are monitoring the current PR.
Read loop_state.json first.
Only check CI status, new review comments, and merge conflicts.
If CI fails:
- capture the failing job name
- capture the shortest useful error excerpt
- update loop_state.json
If nothing changed:
- reply in one sentence
Stop and ask for human help when:
- credentials or permissions fail
- production config is involved
- the same failure appears twice
- the next step requires architectural judgment

Keeping the prompt short avoids token waste; the state file supplies context across rounds.

Beyond Simple Observation

When the loop starts performing actions such as fixing failures, opening PRs, updating issue trackers, or sending Slack notifications, additional components become necessary:

Skill – reusable rules, commands, or scripts stored outside the prompt.

Isolated workspace – a separate worktree or branch for any file modifications.

Verifier – a sub‑agent (or human) that validates the results before they affect production.

These map to traditional engineering responsibilities and help keep the loop safe and maintainable.

Distinguishing /loop and /goal

/loop

is for “check again later” scenarios, while /goal drives the agent toward a verifiable condition (e.g., all tests pass). /goal evaluates the condition with a small model that can only read evidence already placed in the conversation.

Conclusion

The strength of /loop lies in automating the repetitive “wait‑and‑check” parts of engineering work, freeing engineers to focus on higher‑level decisions. Start with a small, well‑scoped scenario, define clear state, evidence, and stop criteria, and then migrate stable loops into longer‑lived scheduling mechanisms.

References

Anthropic Claude Code Docs: Run prompts on a schedule – https://code.claude.com/docs/en/scheduled-tasks

Anthropic Claude Code Docs: Keep Claude working toward a goal – https://code.claude.com/docs/en/goal

Addy Osmani: Loop Engineering – https://addyosmani.com/blog/loop-engineering/

Business Insider: Forget prompt engineering – https://www.businessinsider.com/what-are-loops-ai-engineering-tips-2026-6

Peter Steinberger: Discussion on coding agents and loops – https://x.com/steipete/status/2063697162748260627