Claude Code Goal Command: How /goal Keeps Claude Working Until the Job Is Actually Done

The Claude Code goal command is /goal followed by a completion condition, for example /goal all tests in test/auth pass and the lint step is clean. Setting it starts a turn straight away, with the condition as the instruction. After each turn, a small fast model checks whether the condition holds. If it does not, Claude starts another turn instead of handing control back to you. The goal clears on its own when the condition is met, when the evaluator judges it impossible, or when a turn fails on an error you have to fix. One goal can be active per session, and it works in the desktop app, in the terminal, and through Remote Control.

The part that matters to me is who decides the work is finished. Without a goal, Claude stops when Claude thinks it is done. With a goal, a fresh model that did none of the work reads the conversation and makes the call. That is the same reason I do not review my own pull requests. The builder is the worst judge of whether the build is complete, and /goal gives you a second opinion on every single turn without you having to be there.

Open a session on the project in the desktop app, type /goal followed by your condition, and send it. You do not need a separate prompt. The condition is the instruction, and Claude starts working as soon as it is set. While the goal is active, an indicator shows that it is running and for how long.

If you close the session with a goal still active, resuming that session brings the goal back. The condition carries over, and the turn count, timer and token-spend figures start again from zero. A goal that was already achieved or cleared does not come back. How to resume a Claude Code session covers the resume routes.

A goal condition has to be something Claude's own output can prove. The evaluator does not run commands and does not read your files. It reads the conversation, and that is all. "All tests in test/auth pass" works because Claude runs the tests and the result lands in the transcript. "The code is clean" does not work, because nothing Claude prints can settle it. The CCC Finish Line Formula is the four parts I write every time.

Put together, that reads: /goal every call site uses the new payments client, npm test exits 0, no test file is modified, or stop after 20 turns. The condition can be up to 4,000 characters, so there is room to be exact. The ceiling is the part people skip. Claude reports progress against a turn or time clause each turn and the evaluator judges it from the conversation, which makes it the simplest way to bound a run you are not watching.

The guardrail line is the one I would not leave out. A model told to make the tests pass has two ways to get there, and one of them is editing the tests. Writing "no test file is modified" into the condition closes that door. If the work is big enough to need a page of acceptance criteria, write them down first. How to write a technical spec for Claude Code is the format I use, and the goal then becomes "every acceptance criterion in the spec holds".

These four get confused because they all make Claude Code do more without you. They answer different questions. /goal decides when the work is finished. /loop re-runs a prompt on a time interval. Auto mode removes the approval prompts inside a turn. A Stop hook is the permanent, scripted version of what /goal does for one session.

/goal and auto mode are built to be used together. Auto mode removes the per-tool prompts and /goal removes the per-turn prompts. Under the hood, /goal is a wrapper around a prompt-based Stop hook that lasts for the current session only. If you find yourself typing the same goal every day, that is the sign to make it a real hook. Hooks that earn their keep covers which ones are worth it. For work that should run when no session is open at all, that is a scheduled task in the desktop app, not a goal.

A goal ends in one of three verdicts or one kind of error. The evaluator returns not yet met, met, or impossible, each with a short reason. Not yet met means Claude keeps going and uses the reason as guidance. Met clears the goal and records it as achieved. Impossible clears it and records the reason, so you are not left with a loop chasing something that cannot happen.

The evaluator itself is cheap. It runs on your configured small fast model, which defaults to Haiku on the Claude API, and the official guidance is that evaluation tokens are typically negligible compared to what the main turns spend. The real cost of a goal is the turns. A goal with no ceiling on a vague condition can take a lot of turns, and every one of them is billed like any other work.

That is why the ceiling is in the formula, and why I check /goal partway through a long run. It shows the token spend so far. If the number is climbing and the evaluator's reason has not changed in a while, the condition is the problem, not the model. Clear it, tighten it, and set it again. What actually eats your limit explains where the rest of the spend goes.

A goal earns its place on substantial work with an end state you can verify. It is the wrong tool for anything where finished is a matter of taste.

Pick one job on your current project that has a test or a build you trust. Commit, switch to auto mode if the repo is yours to risk, and write the condition with all four parts: end state, proof, guardrails, ceiling. Then leave it alone and read the evaluator's reasons when you come back. They tell you more about how well you wrote the condition than about how well Claude worked. If a run goes somewhere you did not want, checkpoints and rewind plus the commit you made at the start get you back.