Most of the time, working with an AI coding assistant looks like a conversation. You ask for something, it does a turn of work, it hands control back, and you decide what happens next. That loop is fine for exploration, but it gets tedious fast when you already know exactly what "done" looks like and just want the assistant to get there.
Claude Code's /goal command removes that friction. Instead of prompting after every step, you state a completion condition once, and Claude keeps working turn after turn until the condition is actually met. It's one of those small features that quietly changes how you work.
What /goal actually does
The /goal command sets a completion condition and Claude keeps working toward it without you prompting each step. After each turn finishes, a small fast model checks whether the condition holds. If it doesn't, Claude starts another turn instead of returning control to you. The goal clears automatically once the condition is met.
The mental shift is the important part: you describe a verifiable end state, not a list of instructions. You don't micromanage the steps. You say what "finished" means, and Claude figures out how to get there while an independent checker confirms when it has.
Setting a goal kicks off a turn immediately, with the condition itself as the directive, so there's no separate prompt to send:
/goal all tests in test/auth pass and the lint step is clean
While it runs, a ◎ /goal active indicator shows how long the goal has been going. After each turn, the evaluator returns a short reason explaining why the condition is or isn't met yet, and that reason shows up in the status view and the transcript so you can see what Claude is working toward next.
Requirements:
/goalneeds Claude Code v2.1.139 or later (released May 11, 2026). Because the evaluator is part of the hooks system, the command only runs in workspaces where you've accepted the trust dialog, and it's unavailable whendisableAllHooksorallowManagedHooksOnlyis set.
When to use it
/goal shines for substantial work that has a clear, verifiable finish line. The official docs call out exactly the kinds of jobs it's built for:
- Migrations — moving a module to a new API until every call site compiles and the tests pass.
- Implementing a spec — working through a design doc until all the acceptance criteria hold.
- Refactoring to a budget — splitting a large file into focused modules until each one is under a size limit.
- Burning down a backlog — working through a labeled issue queue until it's empty.
What these have in common is a measurable end state. There's a moment where you can point at the result and say "yes, that's done" without ambiguity. That's the sweet spot. If you can't describe the finish line in a way Claude's own output can prove, /goal isn't the right tool — a normal back-and-forth conversation is.
Why it's genuinely useful
It's easy to wave this off as "auto mode with extra steps," but the design is smarter than that, and the difference matters.
A fresh model decides when you're done
Here's the clever bit. The model doing the work is not the model that judges whether it's finished. After each turn, the condition and the conversation so far go to a separate small fast model — Haiku by default — which returns a yes-or-no plus a short reason.
That separation is a real safeguard against the classic failure mode of autonomous agents: the model that wrote the code is often the same one that confidently declares it correct. With /goal, a fresh evaluator with no ego invested in the work checks the claim. A "no" doesn't just stop progress — it hands Claude the reason as guidance for the next turn, so each attempt is informed by why the last one fell short.
It composes with auto mode
/goal and auto mode solve two different problems, and they're better together. Auto mode approves tool calls within a turn so Claude doesn't stop to ask permission for each command. /goal removes the per-turn prompt by starting the next turn automatically. Run both and Claude can work unattended through a long task: no per-tool prompts, no per-turn prompts, and a fresh evaluator deciding the actual stopping point.
The evaluation is cheap
Because the check runs on the small fast model, the evaluation tokens are typically negligible compared to the main turns doing the real work. You're paying for the work, not for the supervision.
/goal vs /loop vs Stop hooks
Three approaches keep a session running between prompts. They differ in what starts the next turn and what stops it:
| Approach | Next turn starts when | Stops when |
|---|---|---|
/goal | The previous turn finishes | A model confirms the condition is met |
/loop | A time interval elapses | You stop it, or Claude decides the work is done |
| Stop hook | The previous turn finishes | Your own script or prompt decides |
/goal is the session-scoped shortcut: type a condition, and it's active for the current session only. A Stop hook lives in your settings file, applies to every session in its scope, and can run a script for deterministic checks. Reach for /loop when you want time-based repetition rather than a one-time finish line.
Writing conditions that actually finish
This is where /goal lives or dies. The evaluator judges your condition against what Claude has surfaced in the conversation — it does not run commands or read files independently. So write the condition as something Claude's own output can demonstrate.
"All tests in test/auth pass" works because Claude runs the tests and the result lands in the transcript for the evaluator to read. A condition the evaluator can't see in the conversation can never be confirmed, and the goal will spin.
A condition that holds up across many turns usually has three parts:
- One measurable end state — a test result, a build exit code, a file count, an empty queue.
- A stated check — how Claude should prove it, like "
npm testexits 0" or "git statusis clean." - Constraints that matter — anything that must not change on the way there, such as "no other test file is modified."
And to keep a goal from running forever, bound it. Add a turn or time clause right in the condition — or stop after 20 turns — and Claude reports progress against that clause each turn.
/goal every TODO in src/ is resolved and `npm run build` exits 0,
without changing any public API signatures, or stop after 25 turns
The condition can be up to 4,000 characters, so there's room to be specific. Specificity is your friend here — vague conditions produce vague stopping points.
Day-to-day commands
The same /goal command sets, checks, and clears the goal depending on its argument. One goal can be active per session.
Check status — run it with no argument to see the condition, how long it's been running, how many turns have been evaluated, the token spend, and the evaluator's most recent reason:
/goal
Clear early — remove an active goal before its condition is met. stop, off, reset, none, and cancel are all accepted aliases, and /clear removes any active goal too:
/goal clear
Run it headless — /goal works in non-interactive mode, in the desktop app, and through Remote Control. With -p, it runs the whole loop to completion in a single invocation, which makes it a natural fit for scripts and overnight jobs:
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
Press Ctrl+C to stop a non-interactive goal early.
One nice touch: a goal that was still active when a session ended is restored when you resume with --resume or --continue. The condition carries over, though the turn count, timer, and token baseline reset. A goal that was already achieved or cleared is not restored.
A few practical cautions
/goal is powerful, which is exactly why a little discipline pays off:
- Bound long-running goals. Always include a turn or time clause for open-ended work so a goal that can't converge doesn't run indefinitely.
- Make the proof visible. If the evaluator can't see the result in the conversation, it can't confirm the condition. Make sure Claude's checks land in the transcript.
- Pair it with version control and review. Autonomous turns can touch a lot of files. Run goals on a branch, and review the diff the same way you'd review any change — AI-generated code should never skip code review.
- Start with conditions you can verify mechanically. "Tests pass," "build exits 0," "queue is empty" are far more reliable than subjective end states like "the code is clean."
The bottom line
/goal is a small command with an outsized effect on how Claude Code feels to use. It turns the assistant from something you have to babysit turn by turn into something you can point at a verifiable outcome and trust to keep going until it gets there — with an independent model checking the work along the way.
Describe the finish line clearly, bound the runtime, keep the proof visible in the transcript, and you can genuinely set it and walk away. For migrations, spec implementation, refactors, and backlog burndown, that's about as close to "let me know when you're done" as AI-assisted coding has gotten.