Goal — let Claude run itself until a condition is met
Set a verifiable completion condition, and Claude iterates until it's reached — no need to keep telling it to continue
⏱ Est. ~6 min
01 · Read
On big tasks, you often end up shouting "continue," "fix the next one," "run the tests," "try again" — because Claude only does one thing per turn and then stops to wait for you.
/goal lets you set a verifiable completion condition, and Claude iterates on its own, turn after turn, until it's reached. For example: "all tests under test/auth pass and lint is clean." You set it, hit Enter, and go grab coffee. When you come back, either the condition has been met and it ended automatically, or Claude is stuck waiting for a decision.
💡 Picture thisLike giving an engineer a ticket with acceptance criteria — "this PR has to be green before it ships." They'll iterate, make changes, run tests, change more, run again, without checking in with you on every little step. You only show up when they're truly stuck or when it's done.
Key points
- /goal <condition> sets the completion condition and starts the first round immediately
- Claude runs a turn → evaluates whether the condition is met → if not, runs another
- It auto-ends when met; if not, you can stop it manually with /goal clear
- Good fit for tasks with "clear acceptance criteria" (tests pass, file exists, queue empty)
02 · Read
How it works internally: After every turn, a separate small model (usually Haiku) reads the conversation transcript and decides whether the condition is met. It can't run commands or read files itself — it only sees what Claude has shown in the conversation.
That means your condition has to be something Claude can "show" in the conversation:- Good: "npm test exits 0" (Claude runs the tests, the output appears) - Good: "git status is clean" (Claude runs git status, the output appears) - Bad: "code quality is good" (not verifiable, the evaluator can't read into it) - Bad: "no bugs" (no way to prove it in the conversation)
The other key point: the "working model" and the "evaluation model" are separate — the Claude doing the work can't declare itself done to fool you; Haiku decides independently.
Key points
- The evaluator (Haiku) judges separately from the working model
- The evaluator can't run commands or read files — only sees the conversation
- Conditions need evidence Claude can "show" in the conversation
- 4000-character cap; add "or stop after N turns" as a safety net
03 · Code example
The three core commands: set, check progress, clear.
Inside a Claude Code session
# 設定 goal — 立刻開始第一輪
/goal all tests in test/auth pass and lint is clean
# 看當前進度 (條件、跑了幾輪、花了多少 token、評估器最新理由)
/goal
# 手動清除 (條件達成會自動清，不需要這步)
/goal clear
# 別名： stop, off, reset, none, cancel
# /clear 開新對話也會清掉
headless / one-shot run
# 非互動模式，跑到完成才回 shell
claude -p "/goal CHANGELOG.md 有這週每個 PR 的條目"
# Ctrl+C 中斷
When a goal is active, the prompt shows ◎ /goal active with elapsed time next to it. Headless mode (-p) is great for CI or scheduled runs — for example, generating changelog entries daily until done.
04 · Code example
Good conditions vs bad conditions make a huge difference — here are real examples:
Bad condition (evaluator can't verify)
/goal 把 auth.js 拆得更好
/goal 修 login bug
/goal 確保程式碼品質夠
/goal 完成所有 TODO
Good condition (clear acceptance + safety limit)
/goal 把 auth.js 拆成多個 module、每個 <300 行、所有測試通過、或 20 輪後停
/goal 修登入特殊字元 bug，跑 `npm test test/auth` 全綠、或 15 輪後停
/goal 把所有 import 從 old-api 換成 new-api、lint 乾淨、grep 找不到 old-api
Good conditions share three things: a quantifiable end state (exit code, file count, queue empty), a stated "how to prove it" (which command to run), and a safety time limit ("or stop after N turns" to avoid burning tokens forever). Bad conditions usually fail on subjective words like "better quality" or "more cleanly split" — the evaluator can't read those.
05 · Read
Claude Code has several "auto-continue" tools — don't mix them up:- /goal — Set a condition, Claude iterates until it's met. The point is "run until done," no matter how many turns. - /loop — Set a schedule ("do X every 5 minutes"), runs when the time comes. The point is "periodic check-ins," not running to completion. - Stop hook — A script in your config that runs your own judgment logic at the end of each turn. The point is "custom rules that apply across sessions." - Auto mode — Removes the "yes" prompt before every tool call. The point is "no approval needed," not Claude deciding when to stop.
They pair nicely: Auto mode (no approvals) + /goal (run until done) = really hand off and let Claude run.
Key points
- /goal = run until condition is met (session-scoped)
- /loop = time schedule (periodic)
- Stop hook = custom logic across sessions (in config)
- Auto mode = no yes-clicking
- Auto mode + /goal together let it truly run in the background
06 · Quiz
You want Claude to rewrite old React class components into hooks across 30 files. Which /goal condition has the best chance of running to completion?
- /goal rewrite all class components into hooks
- /goal rewrite all class components into hooks, each file passes its existing tests, grep finds no extends React.Component, or stop after 40 turns
- /goal make the code more modern and easier to maintain
- /goal rewrite components until I'm satisfied
07 · Match
Match each scenario to the best tool.
(This section is interactive — please enable JavaScript.)
Other lessons in this chapter
⚠ The full interactive experience needs JavaScript. Please enable it and reload.
※ This is an independent Traditional Chinese teaching project — not an official Anthropic product. Claude™ is a trademark of Anthropic, PBC.