{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"en","schema_type":"TechArticle","category":"tutorial","category_name":"Tutorial","title":"Claude Code Loop Engineering Guide: 4 Types of Loops and Safe Automation Design","summary":"Claude In Code, a loop is a control structure that causes an agent to repeat the cycle of observation, action, and verification until a termination condition is met. This section explains the differences between the four types of loops and describes practical design methods, including verification evidence, hard stops, idempotence, cost, and least privilege.","author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["⁣In INJX12⁣ Code, a “loop” is not a code loop, but rather an agent execution structure that repeats the cycle of observation, action, and verification until a termination condition is met.","Turn-based handles verification procedures, Goal-based handles termination decisions, Time-based determines when to re-execute, and Proactive delegates task initiation and orchestration to the system.","A good loop must have measurable completion criteria, external verification evidence, forced termination, idempotency, and the principle of least privilege.","Since the `/goal` evaluation model evaluates only the evidence evident in the conversation, test outputs, exit codes, and the scope of changes must be clearly reported.","Deterministic transformations should be handled using Script, while Dynamic Workflow and multiple Agents should be used only for large-scale tasks that require true parallelism."],"content_markdown":"⁣The \"Loop\" in INJX12⁣ Code is not simply a feature that runs a model for a long time. The key lies in placing **Triggers, Verifiers, Success Conditions, Hard Stops, and Permission Boundaries** around an AI agent that acts probabilistically, thereby transforming iterative tasks into a controllable system. This article summarizes the differences between Turn-based, Goal-based, Time-based, and Proactive Loops, along with practical design principles.\n\n## 1. What Is a Loop in Claude Code?\n\nHere, a “loop” does not refer to `for` or `while` statements in a programming language. As explained by the Claude Code team, a loop is an execution structure in which an agent observes its current state, takes action, verifies the results, and repeats the process until the termination condition is met.\n\n```text\nStart task\n  ↓\nAssess state and code\n  ↓\nFormulate a plan\n  ↓\nModify code or run tools\n  ↓\nTest and verify\n  ↓\nIs the completion condition met?\n  ├─ No: Next iteration\n  └─ Yes: Terminate and report results\n```\n\nThe following four questions are useful for identifying a loop.\n\n1. What triggers the task?\n2. What terminates the task?\n3. Which Claude Code feature controls the repetition?\n4. What type of task is it suitable for?\n\nNot every task needs to be turned into a complex loop. For tasks where the results are immediately visible—such as correcting typos in a single file or simply renaming something—a standard prompt is more efficient. Loops should only be used when multiple rounds of observation, modification, and verification are actually necessary.\n\n## 2. Comparison of the Four Loop Types\n\n| Type | Start Condition | End Condition | Mainly Used Features | Suitable Tasks | Human Intervention |\n|---|---|---|---|---|---|\n| Turn-based | User’s prompt | When Claude determines the task is complete or additional information is needed | General conversation, Skills, testing and browser tools | Short, one-time implementations or modifications | Iterative verification process |\n| Goal-based | User specifies completion condition | When the evaluation model confirms the condition is met or the user interrupts | `/goal`, Auto mode if needed | Tasks with measurable completion status, such as testing, building, and migration | Determining termination |\n| Time-based | Specified time, interval, or schedule | User cancels or external task completes | `/loop`, `/schedule` | Monitoring PRs, CI, and deployments; periodic summaries; status polling | Next execution time |\n| Proactive | Schedules, APIs, GitHub events, etc. | Individual tasks meet goals; Routines are deactivated | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | Ongoing tasks such as issue triage, bug resolution, and large-scale migrations | Task discovery, prompt execution, orchestration |\n\nThe key to this classification is not “how smart the AI is,” but **what control responsibilities a person delegates to the system**. In Turn-based mode, the user creates the next prompt; in Goal-based mode, the user delegates the decision on completion; and in Time-based mode, the user delegates the timing of re-execution. In the Proactive stage, the responsibility for detecting task occurrence and executing the appropriate prompt is also transferred to the system.\n\n## 3. Turn-based Loop: Delegating the Verification Process\n\nThe Turn-based Loop is the default form in which most developers use Claude Code.\n\n```text\nHuman → Claude → Human → Claude\n```\n\nWhen the user makes a request, Claude locates the relevant files, modifies the code, tests it, and reports the results. Internally, multiple cycles of observation, action, and verification may occur, but the authority to initiate the next task remains with the user.\n\n### Code Modification Is Not the Same as Feature Completion\n\nEven if Claude reports that “implementation and testing are complete,” the following issues may still remain in the actual product:\n\n- The state does not change after clicking a button.\n- An error occurs in the browser console.\n- The mobile layout is broken.\n- Accessibility attributes are missing.\n- Tests pass, but the actual browser flow fails.\n- Files unrelated to the change were modified.\n\nTherefore, the criterion for completion should not be “the code has been changed,” but rather “the behavior has been verified through external evidence.”\n\n### Reusing Verification via `SKILL.md`\n\nSkill stores frequently used guidelines and procedures in `SKILL.md`. Claude can automatically load it based on relevance, or you can run it directly via `/skill-name`. Rather than always putting lengthy operational procedures in `CLAUDE.md`, separating them so that Skills are loaded only when needed allows for more efficient use of context.\n\n```markdown\n---\nname: verify-ui-change\ndescription: Verify UI changes in a production environment before marking them as complete.\n---\n\n# Verifying UI Changes\n\n1. Run the development server.\n2. Open the updated screen in a browser.\n3. Interact with the new controls.\n4. Verify that the expected state changes occur.\n5. Check the browser console for new errors and warnings.\n6. Check accessibility and key performance metrics.\n7. If it fails, fix the issue and repeat the verification from the beginning.\n8. Report evidence such as the commands executed, results, and screenshots.\n```\n\nA good skill contains actionable checklists rather than abstract advice. “Verify that `npm test` returns exit code 0” is a much stronger rule than “Review more carefully.”\n\n### Strength of Validation Evidence\n\n| Evidence | Reliability | Reason |\n|---|---:|---|\n| An agent’s explanation that “it appears to be working normally” | Low | Merely an inference, not an actual execution result |\n| Code diffs and static reviews | Medium | Changes are visible, but runtime behavior cannot be verified |\n| Actual test output and exit code | High | Reproducible external results exist |\n| Browser interactions, screenshots, console and performance results | Very high | Directly verifies user flow and runtime state |\n| Independent Review Agent and CI reach the same conclusion | Very high | Reduces self-confirmation bias in the implementation Agent |\n\nClaude The official Code documentation also describes bundled Skills such as `/run`, which checks running applications, and `/verify`, which validates changes in a real execution environment. If your project’s execution process is complex, it is safer to document the exact startup commands, environment variables, data preparation procedures in the team’s custom Skills.\n\n## 4. Goal-based Loop: Delegating the Termination Decision\n\nIn a Goal-based Loop, the user does not decide “whether to run the task one more time” each time. The user defines the completion state, and Claude continues through multiple turns until those conditions are met.\n\n```text\nUser specifies Goal\n  ↓\nClaude runs a Turn\n  ↓\nA separate evaluation model checks the completion condition\n  ├─ Not met: Pass the reason to the next Turn\n  └─ Met: Goal ends\n```\n\n`/goal` is documented as available in Claude Code v2.1.139 and later. Only one Goal can be active per session.\n\n### What the Evaluation Model Actually Sees\n\nAt the end of each Turn, a separate small, fast model examines the completion conditions and the conversation history to determine whether the condition is `met` or `not met`. The default setting is the Haiku-based evaluation model. An important limitation is that the evaluation model does not read files directly or run tests separately.\n\nTherefore, the agent Claude that performed the task must clearly leave the following evidence in the dialogue:\n\n- Commands executed\n- Number of tests and pass/fail results\n- Exit code\n- Build results\n- List of modified files\n- Remaining causes of failure\n- Confirmation that scope constraints were met\n\nThe evaluation model judges “what evidence was revealed in the conversation,” not “what actually happened.”\n\n### Four Elements of a Good Goal\n\nA good Goal includes the following four elements.\n\n1. **Measurable Success Criteria**: Passing tests, successful build, clearing the queue, reaching a score threshold\n2. **Verification Method**: Specify which commands or tools will be used to prove success\n3. **Scope of Changes**: Modifiable directories, prohibited files, and allowed side effects\n4. **Termination Conditions**: Maximum number of turns, maximum time, number of consecutive failures, or termination upon permission errors\n\n```text\n/goal All auth-related tests and lint checks must succeed,\nand `git diff` must include only `src/auth` and related test files.\nReport the execution results and exit code for each turn.\nAbort when the maximum of 12 turns or 45 minutes is reached, and clean up any remaining failures.\n```\n\nThe core termination condition for `/goal` itself is a successful evaluation by the model or the user’s `/goal clear` command. To enforce turn or time limits, they must be specified within the Goal conditions.\n\n### Good Conditions vs. Bad Conditions\n\n| Good Conditions | Bad Conditions |\n|---|---|\n| `npm test` exits with exit code 0 | Make the code flawless |\n| All 48 authentication-related tests pass | Improve the user experience as much as possible |\n| All API call points are migrated to the new interface and the build succeeds | Refactor to a better structure |\n| The issue queue is empty, and results are recorded for each issue | Process as many issues as possible |\n\nAmbiguous goals can result in the process ending too quickly or in an endless cycle of improvements.\n\n### Checking Status and Canceling\n\n- `/goal`: Check active conditions, execution time, number of evaluation turns, token usage, and reason for the most recent evaluation\n- `/goal clear`: Cancel the active Goal\n- Set a new Goal: Replaces the existing Goal\n- `--resume` or `--continue`: Allows resuming an incomplete Goal\n\nWhile conditions are preserved upon resumption, the Turn count, time, and token thresholds may be reset; therefore, it is advisable to manage hard stops alongside operational metrics.\n\n### `/goal` and permissions are separate\n\n`/goal` only automatically starts the next Turn; it does not expand tool permissions. If file writing, test commands, or Git operations require approval, approval may still be needed even during a Goal.\n\nAuto mode can be used for unattended execution, but Auto mode is not a feature that “unconditionally allows all tools.” The classifier blocks operations that are destructive, difficult to undo, or target areas outside the trust boundary, and explicit `ask` and `deny` rules take precedence over the classifier.\n\n## 5. Time-based Loop: Exceeding the Re-execution Time\n\nWhile the Goal-based Loop addresses “when to stop,” the Time-based Loop addresses “when to run again.” It is suitable for tasks where the state of an external system changes over time.\n\n- Check if a new review has been added to a PR\n- Check if CI or deployment has completed\n- Monitor long-running builds\n- Daily Slack message summary\n- Check for new items in the issue queue\n\n### `/loop`: Run repeatedly within the current session\n\n```text\n/loop 10m Check current PRs and incorporate new reviews;\nif there are failed CI runs, analyze the cause and fix them.\n```\n\nThe main formats described in this document are as follows.\n\n| Input | Action |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | Runs the prompt at a specified fixed interval |\n| `/loop \u003cprompt\u003e` | Claude selects the interval for each iteration |\n| `/loop` | Runs a built-in maintenance prompt or the project’s `loop.md` |\n| `/loop 20m /review-pr 1234` | Reruns an allowed skill at the specified interval |\n\n`/loop` is tied to the current Claude Code session. Your computer and the session must be running; starting a new conversation will cause session-scoped tasks to disappear. Uncompleted tasks can be restored with `--resume` or `--continue`, but recurring tasks expire by default 7 days after creation. They do not retroactively run all missed cycles.\n\nSince the session scheduler may be subject to jitter, it may not be suitable for operational requirements that demand “execution exactly on the hour.”\n\n### `/schedule`: Anthropic Managed Cloud Routine\n\n`/schedule` creates a Routine that bundles a Prompt, Repository, Connector, and Trigger to run on the Anthropic managed infrastructure. It can run even when the notebook is closed, and the official documentation classifies it as a Research Preview.\n\nThe Routines support the following Triggers:\n\n- Recurring schedules\n- One-time schedules at a specific future time\n- Authenticated API calls\n- GitHub Pull Request or Release events\n\nYou can link multiple Triggers to a single Routine. For example, you can set up a PR Review Routine to run every night while also responding to the `pull_request.opened` event.\n\n### Comparison of `/loop` and `/schedule`\n\n| Category | `/loop` | `/schedule` Routine |\n|---|---|---|\n| Execution Location | Current computer and session | Anthropic-managed Cloud |\n| Execution after computer shutdown | Generally not possible | Possible |\n| Open session required | Required | Not required |\n| Local uncommitted files | Accessible | Inaccessible; repository is cloned anew for each execution |\n| Minimum interval | 1 minute (per official documentation) | 1 hour (per official documentation) |\n| Persistence | Session-based; recurring tasks expire after 7 days | Routines stored in the account |\n| Permission Prompt | Inherits current session policy | Runs autonomously without interactive approval |\n| Suitable Use Cases | Monitoring short PRs and deployments | Continuous operational automation |\n\n### When Events Are Better Than Polling\n\nIf you check a PR that rarely changes every minute, most runs will end without doing anything. If an external system can send events, the following structure is more efficient.\n\n```text\nCI failure or PR update\n  ↓\nGitHub Trigger or Routine API\n  ↓\nRun Claude only when necessary\n```\n\nEvent-based design reduces latency and minimizes unnecessary model calls and token consumption. If polling is unavoidable, increase the interval to match the actual frequency of changes, and apply a backoff mechanism when there are no changes for an extended period.\n\n### Prerequisites for Time-Based Tasks\n\n1. **Idempotency**: Even if the same event is received multiple times, it must not result in duplicate comments, duplicate PRs, or duplicate deployments.\n2. **Processing Status**: The last processed Event ID, Commit SHA, Review Comment ID, etc., must be logged.\n3. **Completion Status**: It must be possible to determine when a task is complete, such as when a PR is merged or closed, the queue is empty, or a deployment is successful or rolled back.\n4. **Write Scope**: Side effects must be restricted, such as allowing comments, prohibiting merges, or limiting pushes to the `claude/*` branch.\n5. **Failure Handling**: Retry and escalation rules are required in the event of external service outages, expired authentication, rate limits, or insufficient permissions.\n\n## 6. Proactive Loop: Moving Beyond Task Discovery and Orchestration\n\nThe Proactive Loop is not a single command but a continuous automation architecture that combines multiple functions.\n\n```text\nTrigger\n+ Goal\n+ Skills\n+ Dynamic Workflow\n+ Auto mode\n+ Repository·Connector·Browser·CI tools\n```\n\nNew tasks are detected, processed, verified, and reported even without a human entering prompts in real time.\n\n### Example: Automated Bug Feedback Processing\n\n```text\nReceive GitHub Issue or Slack feedback\n  ↓\nClassify by duplication, priority, and reproducibility\n  ↓\nGenerate reproduction tests\n  ↓\nExplore potential solutions\n  ↓\nImplement the selected solution\n  ↓\nIndependent Review Agent searches for counterexamples\n  ↓\nTesting, building, and security verification\n  ↓\nDraft PR and results report\n```\n\nThe responsibilities of each component are as follows.\n\n| Component | Responsibility |\n|---|---|\n| Trigger or `/schedule` | Determines when to start a new task |\n| `/goal` | Defines what constitutes a \"completed\" state for this run |\n| Skill | Standardizes reproduction, implementation, verification, and reporting procedures |\n| Dynamic Workflow | Parallel execution of multiple subagents and conditional branching |\n| Auto mode | Executes permitted tool calls without waiting for approval |\n| Permission policy | Defines the scope of prohibited, approved, and automatically allowed actions |\n\n### Dynamic Workflow and Worktree\n\nDynamic Workflow is a structure in which the Runtime executes a JavaScript orchestration script written in Claude. In a typical subagent call, Claude selects the next agent each turn, but in a workflow, loops, parallel processing, branching, and intermediate result storage are handled by the script.\n\n```text\nWorkflow Script\n  ├─ Agent A: Requirements Analysis\n  ├─ Agent B: Test Design\n  ├─ Agent C: Exploration of Implementation Candidates\n  ├─ Agent D: Security Review\n  └─ Judge: Evidence-Based Comparison\n```\n\nSince intermediate results are stored in script variables rather than the main conversation context, large-scale tasks can be organized in a more reproducible manner. The current documentation specifies runtime limits of up to 16 Agents simultaneously and up to 1,000 Agents per execution; however, these limits may change during the product’s preview phase.\n\nIf you need to test multiple implementation candidates simultaneously, you can separate your workspaces using Git Worktrees.\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\nHaving each Agent work in its own independent branch and directory can help minimize the risk of simultaneously overwriting the same files. The Judge Agent should compare candidates based on criteria such as requirement fulfillment, test results, regression risks, scope of changes, complexity, performance, security, and consistency with the existing architecture.\n\n### More Agents Are Not Always Better\n\nSimply increasing the number of agents for tasks that do not benefit from parallelism will increase costs and delays. If multiple agents share the same incorrect assumptions, errors may be amplified.\n\nDynamic Workflows are suitable in the following cases:\n\n- Migration: Applying the same transformation to hundreds of files\n- Security and quality audits of the entire codebase\n- Comparing plans from multiple independent perspectives\n- Research requiring the processing of many items in batches and cross-validation\n- Tasks where it is difficult to store all intermediate results within a single agent’s context\n\nFor minor bug fixes, refactoring a single file, or adding simple tests, a standard turn-based loop or `/goal` is preferable.\n\n## 7. Systems for Maintaining Code Quality in Loop\n\nThe quality of Loop’s results depends heavily not only on the model itself but also on the verification systems surrounding it.\n\n### 7.1 Organizing the Codebase\n\nClaude closely follows the patterns of existing code. If there are outdated APIs, duplicate implementations, unclear test structures, bloated modules, or inconsistent exception-handling rules, the Loop can quickly replicate those issues.\n\nThe essential foundations are as follows:\n\n- Formatters and linters\n- Clear directory and module boundaries\n- Reliable unit, integration, and E2E tests\n- Distinction between in-use and deprecated APIs\n- Project-specific development guidelines\n- Reproducible build and development environments\n\n### 7.2 Create a “Definition of Done” for Each Type of Change\n\n| Change Type | Minimum Validation |\n|---|---|\n| API | Contract testing, backward compatibility, updated schema and documentation examples |\n| Frontend | Actual browser interaction, console errors, accessibility, responsive layout |\n| Database | Forward and rollback migrations, lock scope, execution plan |\n| Dependency | Build, key regression tests, license and security checks |\n| Infrastructure | Plan diff, least privilege, rollback, and checks for exposed secrets |\n\nRather than repeating these criteria at length in the prompt every time, it is better to hardcode them into Skills, Hooks, Scripts, and CI Rules.\n\n### 7.3 Provide Up-to-Date Documentation and Exact Versions\n\nLoops can repeat incorrect assumptions multiple times. Ensure that the exact version used in the project, official documentation, internal architecture documents, API specifications, migration guides, and approved examples are easily accessible.\n\n### 7.4 Separate the Implementation Agent and the Review Agent\n\nThe Implementation Agent is already influenced by the chosen design and reasoning. The Review Agent, operating in a new context, can ask the following questions more independently:\n\n- Did we weaken the tests just to pass them?\n- Did we modify files outside the scope?\n- Were security boundaries compromised?\n- Did we omit failure paths and boundary value testing?\n- Did regression occur in existing features?\n\nIt is more effective to write the Review Prompt as “Assume the implementation is incorrect and find counterexamples; provide reproducible evidence for each point raised” rather than “Summarize the positive aspects.”\n\n### 7.5 Link Individual Failures to System Improvements\n\nIf the same error recurs, you should not simply fix the specific result. To prevent the failure type from recurring, you must change one of the following:\n\n- Add regression tests\n- Strengthen skill verification procedures\n- Add rules to `CLAUDE.md`\n- Add hooks or lint rules\n- Add permission denial rules\n- Strengthen goal completion conditions\n- Refine the review checklist\n\nGood Loop Engineering is not about fixing a single failure, but rather **building a system where that type of failure is unlikely to occur again**.\n\n## 8. Token and Cost Management\n\nLoop costs can increase significantly compared to a single prompt.\n\n```text\nTotal Cost ≈\nMain Agent Turn Cost\n+ Goal Evaluation Cost\n+ Subagent Cost\n+ Workflow Iteration Cost\n+ Context Cost for Reading Tool Results\n+ Time-Based Execution Frequency\n```\n\nWhile exact billing varies depending on the Plan, Model, and Provider, the principles determining the cost structure remain the same.\n\n### Practical Principles for Reducing Costs\n\n1. **Do not use Loops for small tasks.** Typos, name changes, and type errors in a single file should be handled in a single turn.\n2. **Include both success conditions and hard stops.** Consider success, maximum turns, maximum time, consecutive failures, and permission errors.\n3. **Test large-scale workflows on a small scale first.** Verify costs and quality using 5 files, a single directory, or a subset of issues before scaling up.\n4. **Handle deterministic tasks with scripts.** For AST substitution, JSON conversion, formatting, and generating fixed templates, verified scripts are more cost-effective and reproducible.\n5. **Adjust the polling interval to match the actual frequency of changes.** Use event triggers whenever possible.\n6. **Monitor usage in real time.** Check usage of Skills, Subagents, MCPs, Turns, and Tokens via `/usage`, `/goal`, and `/workflows`.\n7. **Do not keep retrying if the same error recurs.** Set a limit on consecutive failures and escalate to a human.\n\n### Model and Effort Are Different Levers\n\n- **Model** changes the basic inference capabilities and the scope of problems that can be solved.\n- **Effort** changes the number of files read, the number of tools used, the scope of validation, and how thoroughly multi-step tasks are carried out.\n\n⁣If INJX12⁣ has verified all necessary files and tests but continues to make incorrect judgments, a more powerful Model may be needed. Conversely, if it fails to read important files, skips tests, or stops refactoring partway through, increasing the Effort may be more appropriate.\n\n## 9. Permissions and Safety Boundaries\n\nThe most dangerous design in the Proactive Loop is granting the Agent broad permissions while setting loose success and termination conditions.\n\nAuto mode reduces the scope of general permission prompts, but the classifier can block tool calls that are irreversible, destructive, or target areas outside the trust boundary. Additionally, explicit `permissions.ask` and `permissions.deny` take precedence over Auto mode.\n\n### Example of Permission Hierarchy\n\n| Level | Examples |\n|---|---|\n| Automatically Allowed | Reading code, testing, linting, building, analysis, creating `claude/*` branches, creating draft PRs |\n| Human Approval | Merging to the default branch, production deployment, applying DB migrations, sending messages to external customers |\n| Always Denied | Force push, Secret output, Deletion of production data, Bypassing permissions, Removal of audit logs |\n\nIt is safer to set permanent `ask` and `deny` rules than to simply say “Do not push” once in a conversation. This is because conversation rules can be weakened by context compression or session changes.\n\nCloud Routine clones the repository anew for each execution and operates using the permissions of the connected GitHub and Connector. The following scopes must be minimized:\n\n- Accessible repositories and branches\n- Allowed network domains\n- Connectors to use\n- Environment variables and secrets\n- Write permissions for external systems\n- Scope for creating, pushing, and merging PRs\n\nThe “Normal Exit” status in the Routine execution log may simply mean that the session ended without any infrastructure errors; it does not guarantee that the business objective was successfully achieved. You must review the transcript, test evidence, and generated diffs separately.\n\n## 10. Loop Design Template for Development Projects\n\nThe following YAML is a template for design review and does not represent actual Claude code syntax.\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: The goal to be modified or processed\n  input: Newly incoming Issue, Event, File, or status\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: A completion status that can be evaluated as true or false\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nside_effects:\n  idempotency_key: event-id-or-commit-sha\n  allow_branch_push: claude/*\n  require_human_for_merge: true\n  require_human_for_deploy: true\n\nreview:\n  independent_agent: true\n  adversarial_review: true\n\nobservability:\n  report_progress: true\n  report_token_usage: true\n  report_changed_files: true\n  report_remaining_failures: true\n```\n\nThe five items listed below are more important than the prompt sentence itself.\n\n```text\nTrigger\nVerifier\nSuccess condition\nHard stop\nPermission boundary\n```\n\n## 11. Which Loop Should You Choose?\n\n| Situation | Recommended Approach |\n|---|---|\n| Tasks that are completed with a single modification and verification | Turn-based |\n| Tasks that require multiple attempts but have a clear completion state | `/goal` |\n| Tasks that require a brief wait for external CI, PR, or deployment status | `/loop` |\n| Tasks that must run repeatedly even if the notebook is closed | `/schedule` Routine |\n| Tasks requiring an immediate response to GitHub events or alerts | Event-triggered Routine |\n| Tasks requiring parallel processing and cross-validation of hundreds of items | Dynamic Workflow |\n| Transformations with completely deterministic input and output rules | Script or CI Job |\n\nThe selection order should be based not on “the most powerful feature,” but on “the simplest control structure for achieving the goal.”\n\n## 12. Safe Implementation Order\n\n1. Select one bottleneck task that requires repeated manual verification.\n2. First, create a verification procedure using a Skill, Script, or CI.\n3. Stabilize the quality of validation using a turn-based approach.\n4. Add `/goal` once the completion state is clear.\n5. Use `/loop` only when you need to wait for an external state.\n6. If long-term execution is required, move it to a `/schedule` Routine.\n7. Expand to Dynamic Workflow and Proactive Loop only after idempotency, permissions, and costs have been verified.\n\n## 13. Common Misconceptions\n\n| Misconception | Correct Interpretation |\n|---|---|\n| A loop runs indefinitely | It is a limited iterative structure with success conditions and a hard stop |\n| An agent’s completion report constitutes verification | External command output, exit codes, and runtime results are required |\n| `/goal` automatically grants all permissions | It only automatically starts the next turn; permission policies are separate |\n| `/loop` is a long-term scheduler | It is session-based and has a 7-day expiration and execution environment constraints |\n| The more agents there are, the better the results | Parallelization is only valuable when roles, perspectives, and verification differ |\n| All iterative tasks must be performed by an LLM | For deterministic parts, scripts are cheaper and offer higher reproducibility |\n\n## Conclusion\n\nLoop Engineering is not a technology for running AI for long periods, but rather **the design of a control system that enables AI to detect its own errors, correct them within cost limits, and stop at dangerous points**.\n\nLLMs excel at exploration, inference, implementation, exception analysis, and comparing alternatives. The system must be responsible for the execution timing, scope of changes, verification methods, termination criteria, cost limits, and approval boundaries. The clearer this division of roles is, the closer Claude Code automation moves beyond a simple code generation tool to become a reproducible and auditable development and operations system.","content_html":"\u003cp\u003e⁣The \"Loop\" in INJX12⁣ Code is not simply a feature that runs a model for a long time. The key lies in placing \u003cstrong\u003eTriggers, Verifiers, Success Conditions, Hard Stops, and Permission Boundaries\u003c/strong\u003e around an AI agent that acts probabilistically, thereby transforming iterative tasks into a controllable system. This article summarizes the differences between Turn-based, Goal-based, Time-based, and Proactive Loops, along with practical design principles.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-what-is-a-loop-in-claude-code\" class=\"anchor\" id=\"1-what-is-a-loop-in-claude-code\"\u003e\u003c/a\u003e1. What Is a Loop in Claude Code?\u003c/h2\u003e\n\u003cp\u003eHere, a “loop” does not refer to \u003ccode\u003efor\u003c/code\u003e or \u003ccode\u003ewhile\u003c/code\u003e statements in a programming language. As explained by the Claude Code team, a loop is an execution structure in which an agent observes its current state, takes action, verifies the results, and repeats the process until the termination condition is met.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eStart task\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eAssess state and code\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eFormulate a plan\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eModify code or run tools\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTest and verify\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eIs the completion condition met?\n\u003c/span\u003e\u003cspan\u003e  ├─ No: Next iteration\n\u003c/span\u003e\u003cspan\u003e  └─ Yes: Terminate and report results\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe following four questions are useful for identifying a loop.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eWhat triggers the task?\u003c/li\u003e\n\u003cli\u003eWhat terminates the task?\u003c/li\u003e\n\u003cli\u003eWhich Claude Code feature controls the repetition?\u003c/li\u003e\n\u003cli\u003eWhat type of task is it suitable for?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNot every task needs to be turned into a complex loop. For tasks where the results are immediately visible—such as correcting typos in a single file or simply renaming something—a standard prompt is more efficient. Loops should only be used when multiple rounds of observation, modification, and verification are actually necessary.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#2-comparison-of-the-four-loop-types\" class=\"anchor\" id=\"2-comparison-of-the-four-loop-types\"\u003e\u003c/a\u003e2. Comparison of the Four Loop Types\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eType\u003c/th\u003e\n\u003cth\u003eStart Condition\u003c/th\u003e\n\u003cth\u003eEnd Condition\u003c/th\u003e\n\u003cth\u003eMainly Used Features\u003c/th\u003e\n\u003cth\u003eSuitable Tasks\u003c/th\u003e\n\u003cth\u003eHuman Intervention\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003ctd\u003eUser’s prompt\u003c/td\u003e\n\u003ctd\u003eWhen Claude determines the task is complete or additional information is needed\u003c/td\u003e\n\u003ctd\u003eGeneral conversation, Skills, testing and browser tools\u003c/td\u003e\n\u003ctd\u003eShort, one-time implementations or modifications\u003c/td\u003e\n\u003ctd\u003eIterative verification process\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGoal-based\u003c/td\u003e\n\u003ctd\u003eUser specifies completion condition\u003c/td\u003e\n\u003ctd\u003eWhen the evaluation model confirms the condition is met or the user interrupts\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e, Auto mode if needed\u003c/td\u003e\n\u003ctd\u003eTasks with measurable completion status, such as testing, building, and migration\u003c/td\u003e\n\u003ctd\u003eDetermining termination\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTime-based\u003c/td\u003e\n\u003ctd\u003eSpecified time, interval, or schedule\u003c/td\u003e\n\u003ctd\u003eUser cancels or external task completes\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e, \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eMonitoring PRs, CI, and deployments; periodic summaries; status polling\u003c/td\u003e\n\u003ctd\u003eNext execution time\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eProactive\u003c/td\u003e\n\u003ctd\u003eSchedules, APIs, GitHub events, etc.\u003c/td\u003e\n\u003ctd\u003eIndividual tasks meet goals; Routines are deactivated\u003c/td\u003e\n\u003ctd\u003eRoutines, \u003ccode\u003e/goal\u003c/code\u003e, Skills, Dynamic Workflows, Auto mode\u003c/td\u003e\n\u003ctd\u003eOngoing tasks such as issue triage, bug resolution, and large-scale migrations\u003c/td\u003e\n\u003ctd\u003eTask discovery, prompt execution, orchestration\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eThe key to this classification is not “how smart the AI is,” but \u003cstrong\u003ewhat control responsibilities a person delegates to the system\u003c/strong\u003e. In Turn-based mode, the user creates the next prompt; in Goal-based mode, the user delegates the decision on completion; and in Time-based mode, the user delegates the timing of re-execution. In the Proactive stage, the responsibility for detecting task occurrence and executing the appropriate prompt is also transferred to the system.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-turn-based-loop-delegating-the-verification-process\" class=\"anchor\" id=\"3-turn-based-loop-delegating-the-verification-process\"\u003e\u003c/a\u003e3. Turn-based Loop: Delegating the Verification Process\u003c/h2\u003e\n\u003cp\u003eThe Turn-based Loop is the default form in which most developers use Claude Code.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eHuman → Claude → Human → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen the user makes a request, Claude locates the relevant files, modifies the code, tests it, and reports the results. Internally, multiple cycles of observation, action, and verification may occur, but the authority to initiate the next task remains with the user.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#code-modification-is-not-the-same-as-feature-completion\" class=\"anchor\" id=\"code-modification-is-not-the-same-as-feature-completion\"\u003e\u003c/a\u003eCode Modification Is Not the Same as Feature Completion\u003c/h3\u003e\n\u003cp\u003eEven if Claude reports that “implementation and testing are complete,” the following issues may still remain in the actual product:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe state does not change after clicking a button.\u003c/li\u003e\n\u003cli\u003eAn error occurs in the browser console.\u003c/li\u003e\n\u003cli\u003eThe mobile layout is broken.\u003c/li\u003e\n\u003cli\u003eAccessibility attributes are missing.\u003c/li\u003e\n\u003cli\u003eTests pass, but the actual browser flow fails.\u003c/li\u003e\n\u003cli\u003eFiles unrelated to the change were modified.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTherefore, the criterion for completion should not be “the code has been changed,” but rather “the behavior has been verified through external evidence.”\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#reusing-verification-via-skillmd\" class=\"anchor\" id=\"reusing-verification-via-skillmd\"\u003e\u003c/a\u003eReusing Verification via \u003ccode\u003eSKILL.md\u003c/code\u003e\u003c/h3\u003e\n\u003cp\u003eSkill stores frequently used guidelines and procedures in \u003ccode\u003eSKILL.md\u003c/code\u003e. Claude can automatically load it based on relevance, or you can run it directly via \u003ccode\u003e/skill-name\u003c/code\u003e. Rather than always putting lengthy operational procedures in \u003ccode\u003eCLAUDE.md\u003c/code\u003e, separating them so that Skills are loaded only when needed allows for more efficient use of context.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: Verify UI changes in a production environment before marking them as complete.\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Verifying UI Changes\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Run the development server.\n\u003c/span\u003e\u003cspan\u003e2. Open the updated screen in a browser.\n\u003c/span\u003e\u003cspan\u003e3. Interact with the new controls.\n\u003c/span\u003e\u003cspan\u003e4. Verify that the expected state changes occur.\n\u003c/span\u003e\u003cspan\u003e5. Check the browser console for new errors and warnings.\n\u003c/span\u003e\u003cspan\u003e6. Check accessibility and key performance metrics.\n\u003c/span\u003e\u003cspan\u003e7. If it fails, fix the issue and repeat the verification from the beginning.\n\u003c/span\u003e\u003cspan\u003e8. Report evidence such as the commands executed, results, and screenshots.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eA good skill contains actionable checklists rather than abstract advice. “Verify that \u003ccode\u003enpm test\u003c/code\u003e returns exit code 0” is a much stronger rule than “Review more carefully.”\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#strength-of-validation-evidence\" class=\"anchor\" id=\"strength-of-validation-evidence\"\u003e\u003c/a\u003eStrength of Validation Evidence\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEvidence\u003c/th\u003e\n\u003cth\u003eReliability\u003c/th\u003e\n\u003cth\u003eReason\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAn agent’s explanation that “it appears to be working normally”\u003c/td\u003e\n\u003ctd\u003eLow\u003c/td\u003e\n\u003ctd\u003eMerely an inference, not an actual execution result\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eCode diffs and static reviews\u003c/td\u003e\n\u003ctd\u003eMedium\u003c/td\u003e\n\u003ctd\u003eChanges are visible, but runtime behavior cannot be verified\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eActual test output and exit code\u003c/td\u003e\n\u003ctd\u003eHigh\u003c/td\u003e\n\u003ctd\u003eReproducible external results exist\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eBrowser interactions, screenshots, console and performance results\u003c/td\u003e\n\u003ctd\u003eVery high\u003c/td\u003e\n\u003ctd\u003eDirectly verifies user flow and runtime state\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eIndependent Review Agent and CI reach the same conclusion\u003c/td\u003e\n\u003ctd\u003eVery high\u003c/td\u003e\n\u003ctd\u003eReduces self-confirmation bias in the implementation Agent\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eClaude The official Code documentation also describes bundled Skills such as \u003ccode\u003e/run\u003c/code\u003e, which checks running applications, and \u003ccode\u003e/verify\u003c/code\u003e, which validates changes in a real execution environment. If your project’s execution process is complex, it is safer to document the exact startup commands, environment variables, data preparation procedures in the team’s custom Skills.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-goal-based-loop-delegating-the-termination-decision\" class=\"anchor\" id=\"4-goal-based-loop-delegating-the-termination-decision\"\u003e\u003c/a\u003e4. Goal-based Loop: Delegating the Termination Decision\u003c/h2\u003e\n\u003cp\u003eIn a Goal-based Loop, the user does not decide “whether to run the task one more time” each time. The user defines the completion state, and Claude continues through multiple turns until those conditions are met.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eUser specifies Goal\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClaude runs a Turn\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eA separate evaluation model checks the completion condition\n\u003c/span\u003e\u003cspan\u003e  ├─ Not met: Pass the reason to the next Turn\n\u003c/span\u003e\u003cspan\u003e  └─ Met: Goal ends\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e is documented as available in Claude Code v2.1.139 and later. Only one Goal can be active per session.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#what-the-evaluation-model-actually-sees\" class=\"anchor\" id=\"what-the-evaluation-model-actually-sees\"\u003e\u003c/a\u003eWhat the Evaluation Model Actually Sees\u003c/h3\u003e\n\u003cp\u003eAt the end of each Turn, a separate small, fast model examines the completion conditions and the conversation history to determine whether the condition is \u003ccode\u003emet\u003c/code\u003e or \u003ccode\u003enot met\u003c/code\u003e. The default setting is the Haiku-based evaluation model. An important limitation is that the evaluation model does not read files directly or run tests separately.\u003c/p\u003e\n\u003cp\u003eTherefore, the agent Claude that performed the task must clearly leave the following evidence in the dialogue:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCommands executed\u003c/li\u003e\n\u003cli\u003eNumber of tests and pass/fail results\u003c/li\u003e\n\u003cli\u003eExit code\u003c/li\u003e\n\u003cli\u003eBuild results\u003c/li\u003e\n\u003cli\u003eList of modified files\u003c/li\u003e\n\u003cli\u003eRemaining causes of failure\u003c/li\u003e\n\u003cli\u003eConfirmation that scope constraints were met\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe evaluation model judges “what evidence was revealed in the conversation,” not “what actually happened.”\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#four-elements-of-a-good-goal\" class=\"anchor\" id=\"four-elements-of-a-good-goal\"\u003e\u003c/a\u003eFour Elements of a Good Goal\u003c/h3\u003e\n\u003cp\u003eA good Goal includes the following four elements.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eMeasurable Success Criteria\u003c/strong\u003e: Passing tests, successful build, clearing the queue, reaching a score threshold\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVerification Method\u003c/strong\u003e: Specify which commands or tools will be used to prove success\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eScope of Changes\u003c/strong\u003e: Modifiable directories, prohibited files, and allowed side effects\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTermination Conditions\u003c/strong\u003e: Maximum number of turns, maximum time, number of consecutive failures, or termination upon permission errors\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal All auth-related tests and lint checks must succeed,\n\u003c/span\u003e\u003cspan\u003eand `git diff` must include only `src/auth` and related test files.\n\u003c/span\u003e\u003cspan\u003eReport the execution results and exit code for each turn.\n\u003c/span\u003e\u003cspan\u003eAbort when the maximum of 12 turns or 45 minutes is reached, and clean up any remaining failures.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe core termination condition for \u003ccode\u003e/goal\u003c/code\u003e itself is a successful evaluation by the model or the user’s \u003ccode\u003e/goal clear\u003c/code\u003e command. To enforce turn or time limits, they must be specified within the Goal conditions.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#good-conditions-vs-bad-conditions\" class=\"anchor\" id=\"good-conditions-vs-bad-conditions\"\u003e\u003c/a\u003eGood Conditions vs. Bad Conditions\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eGood Conditions\u003c/th\u003e\n\u003cth\u003eBad Conditions\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003enpm test\u003c/code\u003e exits with exit code 0\u003c/td\u003e\n\u003ctd\u003eMake the code flawless\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAll 48 authentication-related tests pass\u003c/td\u003e\n\u003ctd\u003eImprove the user experience as much as possible\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAll API call points are migrated to the new interface and the build succeeds\u003c/td\u003e\n\u003ctd\u003eRefactor to a better structure\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe issue queue is empty, and results are recorded for each issue\u003c/td\u003e\n\u003ctd\u003eProcess as many issues as possible\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAmbiguous goals can result in the process ending too quickly or in an endless cycle of improvements.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#checking-status-and-canceling\" class=\"anchor\" id=\"checking-status-and-canceling\"\u003e\u003c/a\u003eChecking Status and Canceling\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e/goal\u003c/code\u003e: Check active conditions, execution time, number of evaluation turns, token usage, and reason for the most recent evaluation\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e/goal clear\u003c/code\u003e: Cancel the active Goal\u003c/li\u003e\n\u003cli\u003eSet a new Goal: Replaces the existing Goal\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e--resume\u003c/code\u003e or \u003ccode\u003e--continue\u003c/code\u003e: Allows resuming an incomplete Goal\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWhile conditions are preserved upon resumption, the Turn count, time, and token thresholds may be reset; therefore, it is advisable to manage hard stops alongside operational metrics.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#goal-and-permissions-are-separate\" class=\"anchor\" id=\"goal-and-permissions-are-separate\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003e and permissions are separate\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e only automatically starts the next Turn; it does not expand tool permissions. If file writing, test commands, or Git operations require approval, approval may still be needed even during a Goal.\u003c/p\u003e\n\u003cp\u003eAuto mode can be used for unattended execution, but Auto mode is not a feature that “unconditionally allows all tools.” The classifier blocks operations that are destructive, difficult to undo, or target areas outside the trust boundary, and explicit \u003ccode\u003eask\u003c/code\u003e and \u003ccode\u003edeny\u003c/code\u003e rules take precedence over the classifier.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-time-based-loop-exceeding-the-re-execution-time\" class=\"anchor\" id=\"5-time-based-loop-exceeding-the-re-execution-time\"\u003e\u003c/a\u003e5. Time-based Loop: Exceeding the Re-execution Time\u003c/h2\u003e\n\u003cp\u003eWhile the Goal-based Loop addresses “when to stop,” the Time-based Loop addresses “when to run again.” It is suitable for tasks where the state of an external system changes over time.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCheck if a new review has been added to a PR\u003c/li\u003e\n\u003cli\u003eCheck if CI or deployment has completed\u003c/li\u003e\n\u003cli\u003eMonitor long-running builds\u003c/li\u003e\n\u003cli\u003eDaily Slack message summary\u003c/li\u003e\n\u003cli\u003eCheck for new items in the issue queue\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#loop-run-repeatedly-within-the-current-session\" class=\"anchor\" id=\"loop-run-repeatedly-within-the-current-session\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e: Run repeatedly within the current session\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m Check current PRs and incorporate new reviews;\n\u003c/span\u003e\u003cspan\u003eif there are failed CI runs, analyze the cause and fix them.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe main formats described in this document are as follows.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eInput\u003c/th\u003e\n\u003cth\u003eAction\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eRuns the prompt at a specified fixed interval\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eClaude selects the interval for each iteration\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eRuns a built-in maintenance prompt or the project’s \u003ccode\u003eloop.md\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eReruns an allowed skill at the specified interval\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003e is tied to the current Claude Code session. Your computer and the session must be running; starting a new conversation will cause session-scoped tasks to disappear. Uncompleted tasks can be restored with \u003ccode\u003e--resume\u003c/code\u003e or \u003ccode\u003e--continue\u003c/code\u003e, but recurring tasks expire by default 7 days after creation. They do not retroactively run all missed cycles.\u003c/p\u003e\n\u003cp\u003eSince the session scheduler may be subject to jitter, it may not be suitable for operational requirements that demand “execution exactly on the hour.”\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#schedule-anthropic-managed-cloud-routine\" class=\"anchor\" id=\"schedule-anthropic-managed-cloud-routine\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e: Anthropic Managed Cloud Routine\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003e creates a Routine that bundles a Prompt, Repository, Connector, and Trigger to run on the Anthropic managed infrastructure. It can run even when the notebook is closed, and the official documentation classifies it as a Research Preview.\u003c/p\u003e\n\u003cp\u003eThe Routines support the following Triggers:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRecurring schedules\u003c/li\u003e\n\u003cli\u003eOne-time schedules at a specific future time\u003c/li\u003e\n\u003cli\u003eAuthenticated API calls\u003c/li\u003e\n\u003cli\u003eGitHub Pull Request or Release events\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eYou can link multiple Triggers to a single Routine. For example, you can set up a PR Review Routine to run every night while also responding to the \u003ccode\u003epull_request.opened\u003c/code\u003e event.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#comparison-of-loop-and-schedule\" class=\"anchor\" id=\"comparison-of-loop-and-schedule\"\u003e\u003c/a\u003eComparison of \u003ccode\u003e/loop\u003c/code\u003e and \u003ccode\u003e/schedule\u003c/code\u003e\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategory\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eExecution Location\u003c/td\u003e\n\u003ctd\u003eCurrent computer and session\u003c/td\u003e\n\u003ctd\u003eAnthropic-managed Cloud\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eExecution after computer shutdown\u003c/td\u003e\n\u003ctd\u003eGenerally not possible\u003c/td\u003e\n\u003ctd\u003ePossible\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eOpen session required\u003c/td\u003e\n\u003ctd\u003eRequired\u003c/td\u003e\n\u003ctd\u003eNot required\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eLocal uncommitted files\u003c/td\u003e\n\u003ctd\u003eAccessible\u003c/td\u003e\n\u003ctd\u003eInaccessible; repository is cloned anew for each execution\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eMinimum interval\u003c/td\u003e\n\u003ctd\u003e1 minute (per official documentation)\u003c/td\u003e\n\u003ctd\u003e1 hour (per official documentation)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePersistence\u003c/td\u003e\n\u003ctd\u003eSession-based; recurring tasks expire after 7 days\u003c/td\u003e\n\u003ctd\u003eRoutines stored in the account\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermission Prompt\u003c/td\u003e\n\u003ctd\u003eInherits current session policy\u003c/td\u003e\n\u003ctd\u003eRuns autonomously without interactive approval\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSuitable Use Cases\u003c/td\u003e\n\u003ctd\u003eMonitoring short PRs and deployments\u003c/td\u003e\n\u003ctd\u003eContinuous operational automation\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#when-events-are-better-than-polling\" class=\"anchor\" id=\"when-events-are-better-than-polling\"\u003e\u003c/a\u003eWhen Events Are Better Than Polling\u003c/h3\u003e\n\u003cp\u003eIf you check a PR that rarely changes every minute, most runs will end without doing anything. If an external system can send events, the following structure is more efficient.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCI failure or PR update\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub Trigger or Routine API\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eRun Claude only when necessary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEvent-based design reduces latency and minimizes unnecessary model calls and token consumption. If polling is unavoidable, increase the interval to match the actual frequency of changes, and apply a backoff mechanism when there are no changes for an extended period.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#prerequisites-for-time-based-tasks\" class=\"anchor\" id=\"prerequisites-for-time-based-tasks\"\u003e\u003c/a\u003ePrerequisites for Time-Based Tasks\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eIdempotency\u003c/strong\u003e: Even if the same event is received multiple times, it must not result in duplicate comments, duplicate PRs, or duplicate deployments.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProcessing Status\u003c/strong\u003e: The last processed Event ID, Commit SHA, Review Comment ID, etc., must be logged.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCompletion Status\u003c/strong\u003e: It must be possible to determine when a task is complete, such as when a PR is merged or closed, the queue is empty, or a deployment is successful or rolled back.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWrite Scope\u003c/strong\u003e: Side effects must be restricted, such as allowing comments, prohibiting merges, or limiting pushes to the \u003ccode\u003eclaude/*\u003c/code\u003e branch.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFailure Handling\u003c/strong\u003e: Retry and escalation rules are required in the event of external service outages, expired authentication, rate limits, or insufficient permissions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#6-proactive-loop-moving-beyond-task-discovery-and-orchestration\" class=\"anchor\" id=\"6-proactive-loop-moving-beyond-task-discovery-and-orchestration\"\u003e\u003c/a\u003e6. Proactive Loop: Moving Beyond Task Discovery and Orchestration\u003c/h2\u003e\n\u003cp\u003eThe Proactive Loop is not a single command but a continuous automation architecture that combines multiple functions.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003e+ Goal\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Dynamic Workflow\n\u003c/span\u003e\u003cspan\u003e+ Auto mode\n\u003c/span\u003e\u003cspan\u003e+ Repository·Connector·Browser·CI tools\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eNew tasks are detected, processed, verified, and reported even without a human entering prompts in real time.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#example-automated-bug-feedback-processing\" class=\"anchor\" id=\"example-automated-bug-feedback-processing\"\u003e\u003c/a\u003eExample: Automated Bug Feedback Processing\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eReceive GitHub Issue or Slack feedback\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClassify by duplication, priority, and reproducibility\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGenerate reproduction tests\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eExplore potential solutions\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eImplement the selected solution\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eIndependent Review Agent searches for counterexamples\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTesting, building, and security verification\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDraft PR and results report\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe responsibilities of each component are as follows.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eComponent\u003c/th\u003e\n\u003cth\u003eResponsibility\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrigger or \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eDetermines when to start a new task\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eDefines what constitutes a \"completed\" state for this run\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSkill\u003c/td\u003e\n\u003ctd\u003eStandardizes reproduction, implementation, verification, and reporting procedures\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003ctd\u003eParallel execution of multiple subagents and conditional branching\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAuto mode\u003c/td\u003e\n\u003ctd\u003eExecutes permitted tool calls without waiting for approval\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermission policy\u003c/td\u003e\n\u003ctd\u003eDefines the scope of prohibited, approved, and automatically allowed actions\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#dynamic-workflow-and-worktree\" class=\"anchor\" id=\"dynamic-workflow-and-worktree\"\u003e\u003c/a\u003eDynamic Workflow and Worktree\u003c/h3\u003e\n\u003cp\u003eDynamic Workflow is a structure in which the Runtime executes a JavaScript orchestration script written in Claude. In a typical subagent call, Claude selects the next agent each turn, but in a workflow, loops, parallel processing, branching, and intermediate result storage are handled by the script.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWorkflow Script\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent A: Requirements Analysis\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent B: Test Design\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent C: Exploration of Implementation Candidates\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent D: Security Review\n\u003c/span\u003e\u003cspan\u003e  └─ Judge: Evidence-Based Comparison\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSince intermediate results are stored in script variables rather than the main conversation context, large-scale tasks can be organized in a more reproducible manner. The current documentation specifies runtime limits of up to 16 Agents simultaneously and up to 1,000 Agents per execution; however, these limits may change during the product’s preview phase.\u003c/p\u003e\n\u003cp\u003eIf you need to test multiple implementation candidates simultaneously, you can separate your workspaces using Git Worktrees.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eHaving each Agent work in its own independent branch and directory can help minimize the risk of simultaneously overwriting the same files. The Judge Agent should compare candidates based on criteria such as requirement fulfillment, test results, regression risks, scope of changes, complexity, performance, security, and consistency with the existing architecture.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#more-agents-are-not-always-better\" class=\"anchor\" id=\"more-agents-are-not-always-better\"\u003e\u003c/a\u003eMore Agents Are Not Always Better\u003c/h3\u003e\n\u003cp\u003eSimply increasing the number of agents for tasks that do not benefit from parallelism will increase costs and delays. If multiple agents share the same incorrect assumptions, errors may be amplified.\u003c/p\u003e\n\u003cp\u003eDynamic Workflows are suitable in the following cases:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMigration: Applying the same transformation to hundreds of files\u003c/li\u003e\n\u003cli\u003eSecurity and quality audits of the entire codebase\u003c/li\u003e\n\u003cli\u003eComparing plans from multiple independent perspectives\u003c/li\u003e\n\u003cli\u003eResearch requiring the processing of many items in batches and cross-validation\u003c/li\u003e\n\u003cli\u003eTasks where it is difficult to store all intermediate results within a single agent’s context\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFor minor bug fixes, refactoring a single file, or adding simple tests, a standard turn-based loop or \u003ccode\u003e/goal\u003c/code\u003e is preferable.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#7-systems-for-maintaining-code-quality-in-loop\" class=\"anchor\" id=\"7-systems-for-maintaining-code-quality-in-loop\"\u003e\u003c/a\u003e7. Systems for Maintaining Code Quality in Loop\u003c/h2\u003e\n\u003cp\u003eThe quality of Loop’s results depends heavily not only on the model itself but also on the verification systems surrounding it.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#71-organizing-the-codebase\" class=\"anchor\" id=\"71-organizing-the-codebase\"\u003e\u003c/a\u003e7.1 Organizing the Codebase\u003c/h3\u003e\n\u003cp\u003eClaude closely follows the patterns of existing code. If there are outdated APIs, duplicate implementations, unclear test structures, bloated modules, or inconsistent exception-handling rules, the Loop can quickly replicate those issues.\u003c/p\u003e\n\u003cp\u003eThe essential foundations are as follows:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormatters and linters\u003c/li\u003e\n\u003cli\u003eClear directory and module boundaries\u003c/li\u003e\n\u003cli\u003eReliable unit, integration, and E2E tests\u003c/li\u003e\n\u003cli\u003eDistinction between in-use and deprecated APIs\u003c/li\u003e\n\u003cli\u003eProject-specific development guidelines\u003c/li\u003e\n\u003cli\u003eReproducible build and development environments\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#72-create-a-definition-of-done-for-each-type-of-change\" class=\"anchor\" id=\"72-create-a-definition-of-done-for-each-type-of-change\"\u003e\u003c/a\u003e7.2 Create a “Definition of Done” for Each Type of Change\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eChange Type\u003c/th\u003e\n\u003cth\u003eMinimum Validation\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAPI\u003c/td\u003e\n\u003ctd\u003eContract testing, backward compatibility, updated schema and documentation examples\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFrontend\u003c/td\u003e\n\u003ctd\u003eActual browser interaction, console errors, accessibility, responsive layout\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDatabase\u003c/td\u003e\n\u003ctd\u003eForward and rollback migrations, lock scope, execution plan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDependency\u003c/td\u003e\n\u003ctd\u003eBuild, key regression tests, license and security checks\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfrastructure\u003c/td\u003e\n\u003ctd\u003ePlan diff, least privilege, rollback, and checks for exposed secrets\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eRather than repeating these criteria at length in the prompt every time, it is better to hardcode them into Skills, Hooks, Scripts, and CI Rules.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#73-provide-up-to-date-documentation-and-exact-versions\" class=\"anchor\" id=\"73-provide-up-to-date-documentation-and-exact-versions\"\u003e\u003c/a\u003e7.3 Provide Up-to-Date Documentation and Exact Versions\u003c/h3\u003e\n\u003cp\u003eLoops can repeat incorrect assumptions multiple times. Ensure that the exact version used in the project, official documentation, internal architecture documents, API specifications, migration guides, and approved examples are easily accessible.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#74-separate-the-implementation-agent-and-the-review-agent\" class=\"anchor\" id=\"74-separate-the-implementation-agent-and-the-review-agent\"\u003e\u003c/a\u003e7.4 Separate the Implementation Agent and the Review Agent\u003c/h3\u003e\n\u003cp\u003eThe Implementation Agent is already influenced by the chosen design and reasoning. The Review Agent, operating in a new context, can ask the following questions more independently:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDid we weaken the tests just to pass them?\u003c/li\u003e\n\u003cli\u003eDid we modify files outside the scope?\u003c/li\u003e\n\u003cli\u003eWere security boundaries compromised?\u003c/li\u003e\n\u003cli\u003eDid we omit failure paths and boundary value testing?\u003c/li\u003e\n\u003cli\u003eDid regression occur in existing features?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIt is more effective to write the Review Prompt as “Assume the implementation is incorrect and find counterexamples; provide reproducible evidence for each point raised” rather than “Summarize the positive aspects.”\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#75-link-individual-failures-to-system-improvements\" class=\"anchor\" id=\"75-link-individual-failures-to-system-improvements\"\u003e\u003c/a\u003e7.5 Link Individual Failures to System Improvements\u003c/h3\u003e\n\u003cp\u003eIf the same error recurs, you should not simply fix the specific result. To prevent the failure type from recurring, you must change one of the following:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAdd regression tests\u003c/li\u003e\n\u003cli\u003eStrengthen skill verification procedures\u003c/li\u003e\n\u003cli\u003eAdd rules to \u003ccode\u003eCLAUDE.md\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eAdd hooks or lint rules\u003c/li\u003e\n\u003cli\u003eAdd permission denial rules\u003c/li\u003e\n\u003cli\u003eStrengthen goal completion conditions\u003c/li\u003e\n\u003cli\u003eRefine the review checklist\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eGood Loop Engineering is not about fixing a single failure, but rather \u003cstrong\u003ebuilding a system where that type of failure is unlikely to occur again\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#8-token-and-cost-management\" class=\"anchor\" id=\"8-token-and-cost-management\"\u003e\u003c/a\u003e8. Token and Cost Management\u003c/h2\u003e\n\u003cp\u003eLoop costs can increase significantly compared to a single prompt.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTotal Cost ≈\n\u003c/span\u003e\u003cspan\u003eMain Agent Turn Cost\n\u003c/span\u003e\u003cspan\u003e+ Goal Evaluation Cost\n\u003c/span\u003e\u003cspan\u003e+ Subagent Cost\n\u003c/span\u003e\u003cspan\u003e+ Workflow Iteration Cost\n\u003c/span\u003e\u003cspan\u003e+ Context Cost for Reading Tool Results\n\u003c/span\u003e\u003cspan\u003e+ Time-Based Execution Frequency\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhile exact billing varies depending on the Plan, Model, and Provider, the principles determining the cost structure remain the same.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#practical-principles-for-reducing-costs\" class=\"anchor\" id=\"practical-principles-for-reducing-costs\"\u003e\u003c/a\u003ePractical Principles for Reducing Costs\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eDo not use Loops for small tasks.\u003c/strong\u003e Typos, name changes, and type errors in a single file should be handled in a single turn.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInclude both success conditions and hard stops.\u003c/strong\u003e Consider success, maximum turns, maximum time, consecutive failures, and permission errors.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTest large-scale workflows on a small scale first.\u003c/strong\u003e Verify costs and quality using 5 files, a single directory, or a subset of issues before scaling up.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHandle deterministic tasks with scripts.\u003c/strong\u003e For AST substitution, JSON conversion, formatting, and generating fixed templates, verified scripts are more cost-effective and reproducible.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAdjust the polling interval to match the actual frequency of changes.\u003c/strong\u003e Use event triggers whenever possible.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMonitor usage in real time.\u003c/strong\u003e Check usage of Skills, Subagents, MCPs, Turns, and Tokens via \u003ccode\u003e/usage\u003c/code\u003e, \u003ccode\u003e/goal\u003c/code\u003e, and \u003ccode\u003e/workflows\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDo not keep retrying if the same error recurs.\u003c/strong\u003e Set a limit on consecutive failures and escalate to a human.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#model-and-effort-are-different-levers\" class=\"anchor\" id=\"model-and-effort-are-different-levers\"\u003e\u003c/a\u003eModel and Effort Are Different Levers\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eModel\u003c/strong\u003e changes the basic inference capabilities and the scope of problems that can be solved.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEffort\u003c/strong\u003e changes the number of files read, the number of tools used, the scope of validation, and how thoroughly multi-step tasks are carried out.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e⁣If INJX12⁣ has verified all necessary files and tests but continues to make incorrect judgments, a more powerful Model may be needed. Conversely, if it fails to read important files, skips tests, or stops refactoring partway through, increasing the Effort may be more appropriate.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#9-permissions-and-safety-boundaries\" class=\"anchor\" id=\"9-permissions-and-safety-boundaries\"\u003e\u003c/a\u003e9. Permissions and Safety Boundaries\u003c/h2\u003e\n\u003cp\u003eThe most dangerous design in the Proactive Loop is granting the Agent broad permissions while setting loose success and termination conditions.\u003c/p\u003e\n\u003cp\u003eAuto mode reduces the scope of general permission prompts, but the classifier can block tool calls that are irreversible, destructive, or target areas outside the trust boundary. Additionally, explicit \u003ccode\u003epermissions.ask\u003c/code\u003e and \u003ccode\u003epermissions.deny\u003c/code\u003e take precedence over Auto mode.\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#example-of-permission-hierarchy\" class=\"anchor\" id=\"example-of-permission-hierarchy\"\u003e\u003c/a\u003eExample of Permission Hierarchy\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eLevel\u003c/th\u003e\n\u003cth\u003eExamples\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAutomatically Allowed\u003c/td\u003e\n\u003ctd\u003eReading code, testing, linting, building, analysis, creating \u003ccode\u003eclaude/*\u003c/code\u003e branches, creating draft PRs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHuman Approval\u003c/td\u003e\n\u003ctd\u003eMerging to the default branch, production deployment, applying DB migrations, sending messages to external customers\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAlways Denied\u003c/td\u003e\n\u003ctd\u003eForce push, Secret output, Deletion of production data, Bypassing permissions, Removal of audit logs\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIt is safer to set permanent \u003ccode\u003eask\u003c/code\u003e and \u003ccode\u003edeny\u003c/code\u003e rules than to simply say “Do not push” once in a conversation. This is because conversation rules can be weakened by context compression or session changes.\u003c/p\u003e\n\u003cp\u003eCloud Routine clones the repository anew for each execution and operates using the permissions of the connected GitHub and Connector. The following scopes must be minimized:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAccessible repositories and branches\u003c/li\u003e\n\u003cli\u003eAllowed network domains\u003c/li\u003e\n\u003cli\u003eConnectors to use\u003c/li\u003e\n\u003cli\u003eEnvironment variables and secrets\u003c/li\u003e\n\u003cli\u003eWrite permissions for external systems\u003c/li\u003e\n\u003cli\u003eScope for creating, pushing, and merging PRs\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe “Normal Exit” status in the Routine execution log may simply mean that the session ended without any infrastructure errors; it does not guarantee that the business objective was successfully achieved. You must review the transcript, test evidence, and generated diffs separately.\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#10-loop-design-template-for-development-projects\" class=\"anchor\" id=\"10-loop-design-template-for-development-projects\"\u003e\u003c/a\u003e10. Loop Design Template for Development Projects\u003c/h2\u003e\n\u003cp\u003eThe following YAML is a template for design review and does not represent actual Claude code syntax.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eThe goal to be modified or processed\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eNewly incoming Issue, Event, File, or status\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eA completion status that can be evaluated as true or false\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eside_effects\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eidempotency_key\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eevent-id-or-commit-sha\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallow_branch_push\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_merge\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_deploy\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003ereview\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eindependent_agent\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eadversarial_review\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservability\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_progress\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_token_usage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_changed_files\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_remaining_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe five items listed below are more important than the prompt sentence itself.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eSuccess condition\n\u003c/span\u003e\u003cspan\u003eHard stop\n\u003c/span\u003e\u003cspan\u003ePermission boundary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\u003ca href=\"#11-which-loop-should-you-choose\" class=\"anchor\" id=\"11-which-loop-should-you-choose\"\u003e\u003c/a\u003e11. Which Loop Should You Choose?\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituation\u003c/th\u003e\n\u003cth\u003eRecommended Approach\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTasks that are completed with a single modification and verification\u003c/td\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTasks that require multiple attempts but have a clear completion state\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTasks that require a brief wait for external CI, PR, or deployment status\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTasks that must run repeatedly even if the notebook is closed\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTasks requiring an immediate response to GitHub events or alerts\u003c/td\u003e\n\u003ctd\u003eEvent-triggered Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTasks requiring parallel processing and cross-validation of hundreds of items\u003c/td\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTransformations with completely deterministic input and output rules\u003c/td\u003e\n\u003ctd\u003eScript or CI Job\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eThe selection order should be based not on “the most powerful feature,” but on “the simplest control structure for achieving the goal.”\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#12-safe-implementation-order\" class=\"anchor\" id=\"12-safe-implementation-order\"\u003e\u003c/a\u003e12. Safe Implementation Order\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eSelect one bottleneck task that requires repeated manual verification.\u003c/li\u003e\n\u003cli\u003eFirst, create a verification procedure using a Skill, Script, or CI.\u003c/li\u003e\n\u003cli\u003eStabilize the quality of validation using a turn-based approach.\u003c/li\u003e\n\u003cli\u003eAdd \u003ccode\u003e/goal\u003c/code\u003e once the completion state is clear.\u003c/li\u003e\n\u003cli\u003eUse \u003ccode\u003e/loop\u003c/code\u003e only when you need to wait for an external state.\u003c/li\u003e\n\u003cli\u003eIf long-term execution is required, move it to a \u003ccode\u003e/schedule\u003c/code\u003e Routine.\u003c/li\u003e\n\u003cli\u003eExpand to Dynamic Workflow and Proactive Loop only after idempotency, permissions, and costs have been verified.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#13-common-misconceptions\" class=\"anchor\" id=\"13-common-misconceptions\"\u003e\u003c/a\u003e13. Common Misconceptions\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMisconception\u003c/th\u003e\n\u003cth\u003eCorrect Interpretation\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eA loop runs indefinitely\u003c/td\u003e\n\u003ctd\u003eIt is a limited iterative structure with success conditions and a hard stop\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAn agent’s completion report constitutes verification\u003c/td\u003e\n\u003ctd\u003eExternal command output, exit codes, and runtime results are required\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e automatically grants all permissions\u003c/td\u003e\n\u003ctd\u003eIt only automatically starts the next turn; permission policies are separate\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e is a long-term scheduler\u003c/td\u003e\n\u003ctd\u003eIt is session-based and has a 7-day expiration and execution environment constraints\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eThe more agents there are, the better the results\u003c/td\u003e\n\u003ctd\u003eParallelization is only valuable when roles, perspectives, and verification differ\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAll iterative tasks must be performed by an LLM\u003c/td\u003e\n\u003ctd\u003eFor deterministic parts, scripts are cheaper and offer higher reproducibility\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#conclusion\" class=\"anchor\" id=\"conclusion\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eLoop Engineering is not a technology for running AI for long periods, but rather \u003cstrong\u003ethe design of a control system that enables AI to detect its own errors, correct them within cost limits, and stop at dangerous points\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eLLMs excel at exploration, inference, implementation, exception analysis, and comparing alternatives. The system must be responsible for the execution timing, scope of changes, verification methods, termination criteria, cost limits, and approval boundaries. The clearer this division of roles is, the closer Claude Code automation moves beyond a simple code generation tool to become a reproducible and auditable development and operations system.\u003c/p\u003e\n","tags":["Claude Code","Loop Engineering","AI Agent","Development Automation","Agent Workflow"],"faqs":[{"question":"Claude How is the \"Loop\" in Code different from standard for and while loops?","answer":"A standard loop deterministically repeats the commands defined in the code. Claude Code’s Loop is an agent-controlled structure in which the agent observes the code and external state, infers the next action, executes the tool, verifies the results, and then repeats the process based on termination conditions."},{"question":"When is a turn-based loop most appropriate?","answer":"It is suitable for short, one-time tasks where users can review the results immediately. However, if verification procedures are repeated—such as for UI, API, or databases—it is recommended to create those procedures as Skills or Scripts so that Claude can perform self-verification based on the same criteria."},{"question":"Does the `/goal` evaluation model directly check the files and test results?","answer":"No. The evaluation model does not call any tools or read files directly; instead, it assesses the Goal conditions and the evidence revealed in the dialogue. Task Claude must clearly record the test commands, exit codes, modified files, and cause of failure in the results."},{"question":"What should a good `/goal` condition include?","answer":"We need a measurable completion state, commands or tools to verify that state, the scope of what can and cannot be changed, and hard stops such as maximum turns, time limits, or consecutive failures. “Tests and lint returning a status code of 0 with no diffs outside the specified path” is a better criterion than “clean refactoring.”"},{"question":"Are there any automatic maximum turns or time limits for `/goal`?","answer":"A Goal continues until the evaluation model determines success or the user stops it by entering `/goal clear`. To limit the execution budget, you must explicitly include a turn or time clause in the Goal conditions, such as \"Stop after a maximum of 12 turns or 45 minutes.\""},{"question":"If I use `/goal`, are tool permissions automatically granted as well?","answer":"No. While `/goal` automatically starts the next turn, the permission policies for file writing, Shell, Git, and external connectors remain unchanged. If unattended execution is required, consider using Auto mode, but you must separately control risky operations using `ask` and `deny` rules."},{"question":"What is the main difference between `/loop` and `/schedule`?","answer":"`/loop` is a short-term polling mechanism that repeatedly runs the current Claude Code session on your computer. `/schedule` saves Prompts, Repositories, Connectors, and Triggers as Cloud Routines and runs them on the Anthropic management infrastructure, so it does not require an open session or a powered-on laptop."},{"question":"Does `/loop` continue to run when the computer is turned off?","answer":"Generally, it does not run continuously. `/loop` is a session-scoped operation, and Claude Code must be running. For long-term automation, you should use a persistent scheduler such as Cloud Routine, a desktop scheduled task, or GitHub Actions."},{"question":"Why is an event trigger better than time-based polling?","answer":"This is because it allows you to run the process immediately after an actual change occurs, without generating unnecessary model calls when there are no changes. For systems that can trigger events—such as CI failures, PR updates, or alerts—it’s more cost-effective and results in less latency to connect them via GitHub Triggers or the Routine API."},{"question":"Why is the verification process included in `SKILL.md` instead of `CLAUDE.md`?","answer":"`CLAUDE.md` is ideal for short rules that apply consistently across the entire project, while Skills are best suited for bundling procedures and supporting files needed only for specific tasks. By separating long validation checklists into Skills, you can load them only for the relevant tasks and re-run them directly."},{"question":"How is Dynamic Workflow different from a regular subagent call?","answer":"In the standard subagent approach, Claude selects the next worker each turn, and the results are stored in the context. With Dynamic Workflow, JavaScript scripts manage parallel execution, branching, loops, and intermediate results, allowing for more reproducible organization of large-scale migrations, audits, and cross-validation."},{"question":"Does using multiple agents always improve quality?","answer":"No. If roles and perspectives overlap, you may end up repeating the same errors while only increasing costs. The value of parallel agents is realized only when responsibilities are separated—such as for implementation, test design, security reviews, regression testing, and judging—and independent evidence is required for each conclusion."},{"question":"How do I prevent duplicate tasks in a time-based or proactive loop?","answer":"You must store idempotency keys—such as Event ID, Commit SHA, and Review Comment ID—along with the last processing status. The validation phase must include a rule to ensure that messages that have already been answered, PRs that have already been created, and commits that have already been processed are not processed again."},{"question":"What kind of task is best for the first loop to automate?","answer":"Tasks that require repeated verification but have few dangerous side effects and allow for clear measurement of completion status are ideal. For example, it’s safer to start by summarizing the causes of failed CI runs for pull requests, detecting discrepancies between documentation and code, and performing standard test and lint validations, then gradually expanding permissions for making changes and pushing code."}],"sources":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"Loop Engineering: Getting Started with Loops | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"Extend Claude with skills - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"Keep Claude on track toward a goal - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"Run prompts on a schedule - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"Automate Work with Routines - Claude Code Docs","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"Orchestrate subagents at scale with dynamic workflows - Claude Code Docs","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"Choosing an Claude Model and Effort Level in Claude Code | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"Configure Auto Mode - Claude Code Docs","type":"source"}],"images":[{"id":195,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null}}},{"id":196,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/claude-code-loop-engineering-guide"}