Stop Prompting And Start Looping. A Claude Code Engineer’s Guide to /goal and /loop

Boris Cherny, creator of Claude Code at Anthropic, introduced /goal and /loop commands that enable autonomous AI agents to work without human intervention, shifting the paradigm from prompting to loop engineering. The /goal command sets a finish line verified by a separate evaluator model, while /loop runs prompts on a timer, allowing developers to write loops that prompt Claude rather than prompting it directly.

TL;DR:/goal gives Claude Code a finish line and a second model to check if it’s been crossed - Claude keeps working autonomously until the condition is provably met. /loop runs a prompt on a timer, polling on a schedule without you present. Together they are the foundation of loop engineering. The paradigm shift Boris Cherny, creator of Claude Code, described in Jun 2026 as :This article covers both commands from first principles, and also practical demonstration by building loops on simple application end to end.“I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.” For most of Claude Code’s user, the interaction model looked like this : Here if you observe carefully, you were the loop. Every iteration required your attention. You read the output, decided if it was good enough, and either approved or corrected. Claude was fast, but you were still the bottleneck. In June’2026, Boris Cherny the creator and head of Claude Code at Anthropic described how his own workflow had changed he said that “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” Google’s Addy Osmani put a name to it : Loop Engineering The shift is conceptual before it’s technical. The question stops being “how do I write a good prompt?” and becomes “how do I write a finish line precise enough that a machine can tell when it’s been crossed?” That finish line is /goal . The clock that keeps the look ticking is /loop . Before diving into the commands, it’s worth understanding what Claude Code is doing under the hood, because both commands are built on top of it. The official docs describe it simply : “When you start an agent, the SDK runs the same execution loop that powers Claude Code : Claude evaluates your prompt, calls tools to take action, receives the results, and repeats until the task is complete.” In each full cycle, claude produces output, tools execute, results feedback is one turn. A simple question might take 1–2 turns. A complex refactor can chain dozens. The loop runs until claude produces a text-only responses with no tool calls. That’s the natural stopping point. But “Claude decides it’s done” is a problem in this process : without an external checks, Claude is grading its own homework. And /goal solves this at the architecture level. The official definition from the Claude code docs : "/goal works by wrapping a session-scoped prompt-based Stop hook. Each time Claude finishes a turn, the condition and the conversation so far are sent to a small fast model which defaults to Haiku which returns a yes-or-no decision and a short reason. A 'no' tells Claude to keep working and includes the reason as guidance for the next turn. A 'yes' clears the goal and records an achieved entry in the transcript.” Let that sink in. There are now two models running: The evaluator model does not call tools. It can only judge what claude has already surfaced in the conversation. This is the key architectural insight : the checker is intentionally blind to the codebase and it can only verify what Claude has demonstrated, which forces claude to surface proof of completion, not just claim it. The /goal Command Interface /goal <condition Set or replace the active goal starts immediately /goal Show status: condition, turns, tokens, last evaluator reason/goal clear Clear the goal aliases: stop, off, reset, none, cancel Run non-interactively completes in a single invocation claude -p "/goal <condition " For unattended runs, pair with auto modeclaude --auto -p "/goal all tests in @src/ pass and coverage is above 80%" Requirements: One goal per session. A new /goal replaces the current one. The condition can be up to 4,000 characters. This is the skill. The official docs are direct about it: Bad : ‘improve the dashboard.’ Good : ‘one measurable end state, a stated check how Claude proves it , constraints that must hold, and optionally a turn or time limit.’ The evaluator model can only read the conversation. So your condition must be written as something Claude can demonstrate in conversation, not just claim. The four components of a good condition examples: Bad Conditions vague, unmeasurable : ❌ "Fix the bugs in the code"❌ "Improve code quality"❌ "Make the tests better"❌ "Clean up the auth module" Good conditions verifiable by a second model reading the transcript : ✓ "pytest src/ exits with code 0. Claude must run pytest and show the full output. No files in tests/ are modified. Stop after 25 turns."✓ "CHANGELOG.md has an entry for every PR merged this week. Claude must run git log --oneline and show which PRs were found, then show the CHANGELOG diff. Stop after 10 turns."✓ "All TODO comments in src/ are resolved. Claude must run grep -r TODO src/ and show it returns no results. Stop after 15 turns." Notice the pattern : you’re not just describing the end state, you are specifying the evidence the evaluator will look for in the conversation. Our counterintuitive insight from practitioners : running /goal with a weaker main model often demonstrates the loop’s power more clearly than using Opus also it help us to manage token expenditure. When Opus runs /goal , it often solves problems in one or two turns. The loop barely shows. When Haiku or Sonnet runs the same goal on a hard problem, you see the loop in action: tying an approach, getting the evaluator’s “no+reason”, trying again differently, spawning subagents, brute-forcing search strategies. The same goal, the same commands, but the loop’s autonomous persistence becomes visible. For production, use the best model for the task but of course using best model as evaluator come with a some cost attached to it. For learning the system, deliberately run a medium-difficulty problem with a mid-tier model. /loog and /goal are often mentioned together, but they solve different problems: The official docs describe /loop precisely: “/loop runs on a specified interval; without an interval,it self-paces based on output.” The command interface: /loop 30m Run the current prompt every 30 minutes/loop 1h Run every hour/loop Self-paced: re-runs as soon as previous run completes/loop stop Stop the active loop /loop is designed for recurring work that arrives on a schedule; the kind of task where there is no single “done” state, just on ongoing stream: Now, you might have question that then why not to run corn job rather spending money on LLM models. But there is huge difference from a corn job, a corn job runs a fixed script. /loop runs a model that reads the current state and decides what to do next. The action adapts to the situation. The real architecture emerges when you combine them: /loop provides the cadence. /goal handles completion logic for each unit or work. Together they form a continuous, self-driven engineering agent. The Claude code team’s own documentation describes this combination directly for handling incoming feedback: “Use /schedule to run a routine that checks for new reports, /goal to define what done looks like, and auto mode so the routine runs without stopping to ask for permissions.” What it is: A cycle where AI acts on user inputs, continuing until the conversation ends. This is every standard Claude Code session you’ve already run. How it starts: A standard user prompt. How it ends: You close the chat, go idle, or switch to a new topic. Best for: General queries, exploratory dialogue, basic assistance anything where you want to stay in the driver’s seat. This is where most engineers live today. It’s useful, but you are the loop. Every iteration costs your attention. What it is: A continuous cycle focused on achieving a specific, user-defined objective. Claude doesn’t stop until the goal is provably met verified by a separate evaluator model. How it starts: Give a clear, verifiable objective “all tests pass,” “no linter errors,” “CHANGELOG updated.” How it ends: The evaluator model confirms the condition is met, or you explicitly cancel. Best for: Project management, fixing bugs, creating complex reports, iterative design any task with a checkable finish line. This is /goal. The evaluator is the key innovation: it separates "doing the work" from "deciding if the work is done." What it is: Actions executed automatically at predefined times, dates or intervals regardless of what was done in the previous run. How it starts: Provide a schedule “every 30 minutes,” “daily at 9 AM,” “every Tuesday.” How it ends: Stop instructions given, duration expires, or schedule removed. Best for: Scheduled reporting, health monitoring, reminders, time-sensitive updates for recurring work that doesn’t have a single “done” state. This is /loop. It's the clock layer. The work repeats; only the schedule determines cadence. What it is: AI initiates actions based on detected triggers or changes in external conditions. The AI is watching, not waiting. How it starts: Set conditions “notify me if the CI fails,” “respond when a PR is opened,” “alert if error rate exceeds 5%.” How it ends: You stop monitoring or the trigger condition is permanently resolved. Best for: Opportunity detection, threat monitoring, automated incident response, event-driven workflows. This is implemented via Claude Code Routines GitHub event triggers, webhooks, and MCP connectors that fire when something changes externally. The progression is a maturity ladder. Most engineers start at Turn-Based and never move. Loop engineering means deliberately choosing Goal-Based or Time-Based for the right tasks — and building Proactive loops for the ones that shouldn’t need human initiation at all. Theory without demonstration is incomplete. Let’s build something real. Project : A Python data processing module with intentionally broken code. We use /goal to autonomously fix all failing tests without touching the test files. Then we add /loop to monitor the suite on a recurring schedule. This project is designed to be reproducible or you can clone it, break the code and run the exact same commands to watch the loop work. create a directory and change to itmkdir self-healing-suite && cd self-healing-suite Initialize git in same directorygit init create a virtual environment & activate itpython -m venv .venv && source .venv/bin/activate install pytest environmentpip install pytest pytest-cov Directory structure we’re building: self-healing-suite/├── .claude/│ ├── settings.json ← Hook: block test file modifications│ └── commands/│ ├── goal.md ← /goal command template│ └── loop.md ← /loop command template├── src/│ ├── init .py│ ├── data cleaner.py ← 4 intentional bugs live here│ └── stats engine.py ← 2 more bugs here├── tests/│ ├── init .py│ ├── test data cleaner.py│ └── test stats engine.py├── CLAUDE.md ← Project rules└── pytest.ini src/data cleaner.py four bugs planted: src/data cleaner.py"""Data cleaning utilities for ingestion pipelines.Bug count: 4 deliberately introduced for the Self-Healing Suite demo """from typing import List, Optionalimport redef remove duplicates records: List dict - List dict : """Remove duplicate records based on 'id' field.""" seen = set result = for record in records: BUG 1: should be record "id" , not record.get "name" key = record.get "name" if key not in seen: seen.add key result.append record return resultdef normalize email email: str - str: """Lowercase and strip whitespace from email.""" if not isinstance email, str : raise TypeError "email must be a string" BUG 2: strip removes whitespace, but we also need to lowercase Missing: .lower return email.strip def validate phone phone: str - bool: """Return True if phone matches E.164 format +1234567890 .""" BUG 3: Pattern is wrong - \d{10,14} should be \d{7,14} E.164 allows 7–15 digits total; the + counts as 1 char pattern = r"^\+\d{10,14}$" return bool re.match pattern, phone def fill missing records: List dict , field: str, default value - List dict : """Fill missing or None values for a given field with default value.""" result = for record in records: new record = record.copy BUG 4: condition is inverted - should be if field not in new record Currently fills records that HAVE the field, ignoring ones that don't if field in new record and new record field is None: new record field = default value result.append new record return result src/stats engine.py Two more bugs planted in src/stats engine.py file: src/stats engine.py"""Statistical aggregation engine.Bug count: 2 deliberately introduced for the Self-Healing Suite demo """from typing import List, Optionalfrom statistics import median, StatisticsErrordef compute mean values: List float - Optional float : """Return the arithmetic mean, or None for empty input.""" if not values: return None BUG 5: Integer division - should be / not // return sum values // len values def compute median values: List float - Optional float : """Return the median, or None for empty input.""" if not values: return None return median values def bucket by percentile values: List float , buckets: int = 4 - List List float : """Split sorted values into equal-sized percentile buckets.""" if not values: return sorted vals = sorted values bucket size = len sorted vals // buckets if bucket size == 0: return sorted vals result = for i in range buckets : start = i bucket size BUG 6: Last bucket misses remainder - should use None slice for last bucket end = i + 1 bucket size result.append sorted vals start:end return result tests/test data cleaner.py: tests/test data cleaner.pyimport pytestfrom src.data cleaner import remove duplicates, normalize email, validate phone, fill missing, class TestRemoveDuplicates: def test removes by id field self : records = {"id": 1, "name": "Alice"}, {"id": 1, "name": "Alice"}, duplicate id {"id": 2, "name": "Bob"}, result = remove duplicates records assert len result == 2 assert result 0 "id" == 1 assert result 1 "id" == 2 def test empty list self : assert remove duplicates == def test no duplicates self : records = {"id": i} for i in range 5 assert len remove duplicates records == 5class TestNormalizeEmail: def test lowercases email self : assert normalize email "USER@EXAMPLE.COM" == "user@example.com" def test strips whitespace self : assert normalize email " user@example.com " == "user@example.com" def test combined self : assert normalize email " USER@EXAMPLE.COM " == "user@example.com" def test raises on non string self : with pytest.raises TypeError : normalize email 123 class TestValidatePhone: def test valid us number self : assert validate phone "+12125551234" is True def test valid short number self : 7-digit number with country code is valid E.164 assert validate phone "+1234567" is True def test invalid no plus self : assert validate phone "12125551234" is False def test invalid too short self : assert validate phone "+123" is Falseclass TestFillMissing: def test fills absent field self : records = {"id": 1}, {"id": 2, "score": 5} result = fill missing records, "score", 0 assert result 0 "score" == 0 assert result 1 "score" == 5 def test fills none value self : records = {"id": 1, "score": None} result = fill missing records, "score", 0 assert result 0 "score" == 0 def test does not overwrite existing self : records = {"id": 1, "score": 42} result = fill missing records, "score", 0 assert result 0 "score" == 42 def test empty list self : assert fill missing , "score", 0 == tests/test stats engine.py: python tests/test stats engine.pyimport pytestfrom src.stats engine import compute mean, compute median, bucket by percentileclass TestComputeMean: def test integer values self : assert compute mean 1, 2, 3 == 2.0 def test float precision self : Integer division would return 1, not 1.5 assert compute mean 1, 2 == 1.5 def test single value self : assert compute mean 5 == 5.0 def test empty returns none self : assert compute mean is Noneclass TestComputeMedian: def test odd count self : assert compute median 1, 3, 5 == 3 def test even count self : assert compute median 1, 2, 3, 4 == 2.5 def test empty returns none self : assert compute median is Noneclass TestBucketByPercentile: def test four equal buckets self : values = list range 8 0,1,2,3,4,5,6,7 result = bucket by percentile values, buckets=4 assert len result == 4 All 8 values should be present flat = v for bucket in result for v in bucket assert sorted flat == values def test remainder in last bucket self : 10 values, 4 buckets: last bucket should have 4 items 2+2+2+4 values = list range 10 result = bucket by percentile values, buckets=4 flat = v for bucket in result for v in bucket assert sorted flat == values No values lost def test empty input self : assert bucket by percentile == def test fewer values than buckets self : result = bucket by percentile 1, 2 , buckets=4 assert result == 1, 2 Falls back to single bucket A critical constraint of the demo: Claude must fix bugs in src/ only. The tests define the specification they are immutable. .claude/settings.json: { "hooks": { "PreToolUse": { "matcher": "Edit|Write", "hooks": { "type": "command", "command": "python3 -c \"\nimport json, sys\ndata = json.load sys.stdin \npath = data.get 'tool input', {} .get 'file path', '' \nif 'tests/' in path:\n print f'BLOCKED: {path} is a test file. Fix src/ only.', file=sys.stderr \n sys.exit 2 \nsys.exit 0 \n\"" } } }} This is real policy enforcement. If Claude tries to modify a test file to make tests pass a known shortcut LLMs attempt , the hook blocks the write at the system level and feeds the reason back to Claude. pytest.ini: pytest testpaths = testspython files = test .pypython classes = Test python functions = test addopts = -v --tb=short Before running /goal, confirm the suite is broken: Expected output: Seven failures. Two source files. Six bugs. Let’s let /goal fix them. Open Claude Code in your project directory: cd self-healing-suiteclaude Now set the goal: what happens next - a turn-by-turn trace: Turn 1 : Claude runs /pytest test/ -v and reads the all failures. It identifies the failure patterns and starts with test removes by id field . Turn 2 : Claude reads src/data cleaner.py , finds Bug 1 record.get "name" → record.get "id" , edits the file, re-runs pytest. 6 failures remain. Turn 3 : The evaluator checks the conversation. Reads: “6 tests still failing.” Returns: “No. Tests still failing: 6 remaining. Continue.” Claude continues. Turn 4 : Claude tackles Bug 2 normalize email missing .lower , fixes it, re-runs. 5 failures remain. Turn 5–7: Bugs 3, 4, 5 fall in sequence. Each time Claude runs pytest and shows the output. Turn 8: Bug 6 the bucket by percentile remainder bug. Claude rewrites the slice logic to use None for the final bucket. Runs pytest. Turn 9: pytest tests/ -v26 passed, 0 failed. Claude shows the full output. Turn 10: Evaluator reads the conversation. Sees the full pytest output with “26 passed.” Returns: “Yes. All 26 tests pass. Goal achieved.” Session ends. You didn’t type a single thing after /goal. The project has clean tests. Add /loop to keep it that way. Setup : Create a monitoring command. .claude/commands/monitor.md: The project now has clean tests. Add /loop to keep it that way. Setup: Create a monitoring command .claude/commands/monitor.md: Running the monitor loop: Monitor the test suite every 30 minutes/loop 5m /monitor Or from a non-interactive terminal useful for CI integration : Run continuously, log to fileclaude -p "/loop 30m /monitor" .claude/monitor.log 2 &1 & This is how the loop will work, in our example it’ll start after every 5m and run the test validation. Just for demo purpose I’m changing src/data clearner.py and again planting same bugs. The health log it produces .claude/health.log : 2026-07-09 13:23:36 STATUS: healthy TESTS: 26 passed/26 total 2026-07-09 13:28:26 STATUS: healthy TESTS: 26 passed/26 total 2026-07-09 13:33:18 STATUS: healthy TESTS: 26 passed/26 total 2026-07-09 13:38:51 STATUS: fixed TESTS: 26 passed/26 total 2026-07-09 14:30:58 STATUS: healthy TESTS: 26 passed/26 total The mini project self-healing-suite is designed to be cloned and run. Every bug in this article is a real, valid Python bug that produces a real test failure. The fix requires understanding the code, not guessing which is exactly what makes it a good test for autonomous loop reasoning. The complete self-healing system for this project: This is functioning, autonomous test maintenance system. The only time a human needs to look at it is when the system explicitly flags needs human which happens when the bug is architectural, not cosmetic. The XDA field guide on /goal captured the single most important insight from practitioners: “If you can’t say what ‘done’ looks like, you don’t have a loop. You have a wish.” Three principles that separate working /goal deployments from frustrating ones: The test: if there’s a moment when “it’s done” can be verified programmatically, use /goal . If the work never ends and just repeats, use /loop That’s loop engineering. One finish line. No babysitting. /goal and /loop are powerful precisely because they run autonomously. That autonomy is also their risk. Token costs in agent loops compound differently than single-turn calls and an unattended loop without circuit breakers is a machine that ships bugs with high confidence and runs up your bill while doing it. The next article in this series covers production-safe loop design: how to set max budget usd, when to use max turns, the maker/checker pattern with separate verifier sub-agents, and how to design stopping criteria that prevent the four most common loop failure modes. If you’ve ever woken up to a surprise API bill, that article is for you. Follow me for more practical engineering takes & usage of AI systems. Stop Prompting And Start Looping. A Claude Code Engineer’s Guide to /goal and /loop https://pub.towardsai.net/stop-prompting-and-start-looping-a-claude-code-engineers-guide-to-goal-and-loop-e7662aaaafd6 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.