Getting started with loops

📝 摘要 #

本文由 Claude Code 团队撰写，系统阐述了「设计循环（Designing Loops）」而非简单提示（Prompting）的智能体工作范式。文章将循环定义为"智能体重复工作周期直至满足停止条件"，并按触发方式、停止条件、使用原语和适用场景将循环分为四类：Turn-based（手动驱动）、Goal-based（/goal 驱动）、Time-based（/loop 和 /schedule 驱动）以及 Proactive（事件/调度驱动的组合循环）。

核心概念： 将编码智能体的工作方式从"逐轮手动提示"升级为"设计自动化循环系统"，通过明确的停止条件和验证机制，让 Claude 自主迭代直至目标达成。

关键技术栈 / 关键要点：

1. Turn-based loops — 用户逐轮驱动，适合短任务；可通过 Skills 编码验证步骤减少交互轮次
2. Goal-based loops (/goal) — 定义成功标准后由评估模型自动判断是否达成，适合有可验证退出条件的任务
3. Time-based loops (/loop, /schedule) — 按时间间隔触发，适合与外部系统交互或周期性工作
4. Proactive loops — 组合 /schedule + /goal + Dynamic Workflows + Auto mode，实现无需人类实时参与的自主工作流
5. 代码质量维护 — 保持代码库整洁、赋予 Claude 自验证能力、文档可触及、使用第二智能体做 Code Review
6. Token 用量管理 — 选对原语和模型、明确成功/停止条件、先小规模试点、用脚本替代确定性工作

关键结论 / 实践建议： 从现有工作中找出自己成为瓶颈的任务，判断可以交接的是验证检查、目标定义还是调度触发，然后运行循环、观察结果并持续迭代优化。

There’s a lot of talk right now about "designing loops" instead of prompting your coding agent. If you spend some time on X trying to pin down what a loop actually is, you'll come across multiple different answers.

On the Claude Code team, we define loops as agents repeating cycles of work until a stop condition is met. We categorize a few different types of loops based on:

• How they are triggered
• How they are stopped
• What Claude Code primitive is used
• What type of task is most appropriate for each.

We’ll cover the main loop types, when to use each, and how to maintain code quality while managing token usage. Not all tasks require complex loops; start with the simplest solution and use these patterns selectively.

Turn-based loops #

• Triggered by: A user prompt.
• Stop criteria: Claude judges it has completed the task or needs additional context.
• Best used for: Shorter tasks that are not part of a regular process or schedule.
• Managed usage by: Write specific prompts and improve verification using skills to reduce the number of turns.‍

Every prompt you send starts a manual loop with you directing each turn. Claude gathers context, takes action, checks its work, repeats if needed, and responds. We call this the agentic loop.

For example, ask Claude to create a like button. It reads your code, makes the edit, runs the tests, and hands back something it believes works. You then manually check the work, and write the next prompt.

You can improve the verification step by encoding your manual steps as a SKILL.md so Claude can check more of its own work, end-to-end. This should include tools or connectors to allow Claude to see, measure or interact with the result. The more quantitative the checks are, the easier it is for Claude to self-verify.

For example, in your SKILL.md file you may specify:

--- 
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.

Goal-based loop (/goal) #

• Triggered by: A manual prompt in real-time.
• Stop criteria: Goal achieved OR maximum number of turns reached.
• Best used for: Tasks that have verifiable exit criteria.
• Managed usage by: Setting a specific completion criteria and explicit turn caps, “stop after 5 tries.”

Sometimes, a single turn is not enough, especially for more complex tasks. Agents do better when they can iterate. You can extend how long Claude keeps iterating by defining what done looks like with /goal.

When you define the success criteria, Claude doesn’t have to make a determination on what is “good enough” and end the loop early. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or a number of turns you define is reached.

This is why deterministic criteria, such as number of tests passed or clearing a certain score threshold, are so effective.

For example:

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

Time-based loop (/loop and /schedule) #

• Triggered by: A specified time interval.
• Stop criteria: You cancel it, or the work completes (the PR merges, the queue is empty).
• Best used for: For recurring work, or interfacing with external environments / systems.
• Managed usage by: Set longer intervals or react based on events rather than time.

Some agentic work is recurring: the task stays the same and only the inputs change. For example, summarizing Slack messages every morning. Other work depends on external systems, and a simple way to interface with one is to check it on an interval and react to what changed. For example, a PR which may receive code reviews or fail CI.

For these, you can trigger when Claude runs with `/loop` which re-runs a prompt on an interval. For example:

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

`/loop` runs on your computer, so if you turn it off, it stops. You can move the loop to the cloud by creating a routine with  `/schedule`.

Proactive loops #

• Triggered by: An event or schedule, with no human in real time.
• Stop criteria: Each task exits when its goal is met. The routine itself runs until you turn it off.
• Best used for: Recurring streams of well-defined work: bug reports, issue triage, migrations, dependency upgrades, etc.
• Managed usage by: Routing routines to smaller, faster models and using the most capable model for judgment calls.

The primitives above, along with other Claude Code features like auto mode and dynamic workflows (research preview) can be composed into a loop for long-running work.

For example, to handle incoming feedback, you can use:

1. `/schedule` (research preview) to run a routine that checks for new reports
2. `/goal` to define what done looks and skills to document how to verify it
3. Dynamic workflows to orchestrate agents that triage each report, fix it, and review the fix
4. Auto mode so the routine runs without stopping to ask for permission

Putting it together, a prompt could look like this:

/schedule every hour: check the project-feedback channel 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.

Maintaining code quality #

The quality of a loop’s output depends on the system around it. When designing the system:

• Keep the codebase itself clean: Claude follows patterns and conventions that already exist in your codebase.
• Give Claude a way to verify its own work: Encode what good looks like for you and your team with skills.
• Make docs easy to reach: Frameworks and libraries docs have up-to-date best practices.
• Use a second agent for code reviews: A reviewer with fresh context is less biased and not influenced by the main agent’s reasoning. You can use the built-in `/code-review` skill or Code Review for Github.

When an individual result doesn’t meet the standard, don’t stop at fixing the individual issue, try to encode it to improve the system for all future iterations.

Managing token usage #

To manage token usage, loops should have clear boundaries:

• Choose the right primitive and model for the job: Smaller tasks don’t need multiple agents or loops. Some tasks can use cheaper and faster models.
• Define clear success and stop criteria: Be specific about what done looks like so Claude can arrive at the solution sooner (but not too soon).
• Pilot before a large run: Dynamic workflows can spawn hundreds of agents. Gauge usage on a smaller slice of the work first.
• Use scripts for deterministic work: Running a script is cheaper than reasoning through the steps. For example, a PDF skill can ship a form-filling script that Claude runs each time, instead of re-deriving the code.
• Don’t run routines more often that you need to: Match the interval to how often the thing you’re watching changes
• Review usage: The `/usage` command breaks down recent usage by skills, subagents, and MCPs, `/goal` with no arguments shows number of turns and token usage so far, `/workflows` shows each agent’s token usage and you can stop an agent at any time.

Getting started #

To summarize:

To get started with loops, look at the work you already do. Pick one task where you’re the bottleneck and ask which piece you could hand off: can you write the verification check? Is the goal clear enough? Does the work arrive on a schedule?

Once you have an idea, run the loop, observe the results like where it stalls or over-reaches, and don’t be afraid to iterate on it.

For more information, read the Claude Code docs on running agents in parallel, as well as the loop, schedule, goal, and dynamic workflows pages.

This article was written by @delba_oliveira