Claude Code Goal Command for Client Work: Turn the Acceptance Criteria Into the Finish Line

What the Claude Code Goal Command Does

The /goal command sets a completion condition, and Claude Code keeps working toward that condition without you prompting each step. You type /goal followed by the condition. That starts a turn immediately, with the condition as the instruction. After each turn, a small fast model checks whether the condition holds. If it judges the condition not yet met, Claude starts another turn instead of handing control back to you. The goal clears on its own when the condition is met, when the model judges it impossible to satisfy, or when a turn fails on an error you have to fix.

The detail that matters for client work is who decides the work is done. Without a goal, Claude stops when it judges the work finished. With a goal, a fresh model decides, and it decides against the words you wrote. The docs describe /goal as a wrapper around a session-scoped prompt-based Stop hook, which is the same mechanism covered in [hooks for client work](/blog/claude-code-hooks-for-client-work), packaged so you type one line instead of editing a settings file.

One goal can be active per session. Setting a new one replaces the old one. While it runs you see a goal-active indicator with the elapsed time, and the transcript shows each verdict the evaluator returns. Running /goal with no arguments shows the condition, how long it has been running, how many turns have been evaluated, the current token spend, and the evaluator's most recent reason. Running /goal clear removes it, and so does /clear when you start a new conversation. According to the docs, /goal works in the desktop app, in non-interactive mode, and through Remote Control, so nothing here requires the terminal.

Why a Goal Fits Client Builds

A client build already has a written finish line. It is the acceptance criteria in the [scope of work](/blog/scope-of-work-that-prevents-scope-creep). The problem I kept running into was that the finish line lived in a document and the work happened in a session, and the two drifted. Claude would finish a feature, report that it was done, and I would find on review that one criterion had been skipped or one test was still red. Nothing dishonest had happened. The session had simply stopped at what looked finished to the model doing the work.

A goal closes that gap, because the check is made by a different model reading the condition, not by the one that wrote the code. The docs list the kinds of work a goal suits, and they read like a client backlog: migrating a module until every call site compiles and tests pass, implementing a design doc until all acceptance criteria hold, working through a labeled issue backlog until the queue is empty. Each of those has a verifiable end state. That is the requirement. If the end state of a task cannot be checked, the task is not ready for a goal, and it is probably not ready to be quoted either.

A goal only covers the session that is open. Work that should run with no session open, such as a nightly check on a client's production site, belongs in [routines](/blog/claude-code-routines-for-client-work), not in a goal.

The Sign-Off Condition

The evaluator judges your condition against what Claude has surfaced in the conversation. It does not run commands and it does not read files on its own. That single fact decides how a client-build condition has to be written: as something Claude's own output can demonstrate. The docs give the example that a condition about tests passing works because Claude runs the tests and the result appears in the transcript for the evaluator to read.

The Profit Room's Sign-Off Condition is the way I turn a client's acceptance criteria into a goal. It has four parts, and the first three come straight from what the docs say a durable condition contains.

1. One measurable end state per criterion. Take each line the client agreed to and rewrite it as a result: a test that passes, a build that exits cleanly, a count that reaches a number, a queue that is empty. If a criterion reads the booking form should feel fast, it is not measurable yet. Go back to the client and agree on what fast means before the build, not after.
2. A stated check. Say how Claude should prove it, such as the test command exits 0 or git status is clean. This is the difference between Claude saying the tests pass and the transcript showing them pass.
3. The constraints that matter. Name what must not change on the way there. On client work these are usually the most important words in the condition: no other test file is modified, no file outside the feature folder is touched, no dependency is added. A model working toward a passing test can reach it by weakening the test. The constraint is what rules that out.
4. A stop clause. Add or stop after a set number of turns to the condition. The docs confirm this works: Claude reports progress against the clause each turn and the evaluator judges it from the conversation. On a fixed-price build, an unbounded goal is an unbounded cost.

The condition can be up to 4,000 characters, which is enough for a real set of acceptance criteria and not enough for an essay. When mine do not fit, the task is too big for one goal and I split it into two scoped pieces, each with its own condition. That usually matches the milestones in the agreement anyway.

Permissions, Unattended Runs, and What a Goal Does Not Change

A goal does not change your permission mode. This surprises people the first time. In Manual mode, Claude still asks before tool calls your settings do not already allow, so a goal can sit waiting on an approval prompt while you are away from the desk. To let goal turns run unattended, the docs say to run /goal in auto mode. They describe the two as complementary: auto mode removes the per-tool prompts, and /goal removes the per-turn prompts.

That combination is powerful, and on a client's codebase it is exactly where the guardrails need to be in place first. Before I let a goal run unattended on client work, the project has its [permission rules](/blog/claude-code-permissions-for-client-work) written so that production credentials and deploy commands are off the table, and the [sandbox](/blog/claude-code-sandboxing-for-client-work) is on. I read through [auto mode for client work](/blog/claude-code-auto-mode-for-client-work) again whenever I set this up for a new client, because what auto mode will and will not approve is the real boundary of an unattended goal.

Background work changes the timing. If a subagent or a background shell command is still running when a turn ends, Claude Code skips the evaluation for that turn and evaluates at the end of the next turn that finishes with nothing running in the background. Once background work has kept the goal waiting for 30 minutes, a check-in is due, in which Claude is asked to read the output of the running tasks, keep waiting if they are progressing, and fix or stop any that are stuck. Check-ins require Claude Code v2.1.234 or later. If your builds lean on [background tasks](/blog/claude-code-background-tasks-for-client-work), expect the goal to wait for them.

The requirement most likely to trip you up is trust. The docs state that /goal is available under the same workspace trust rule as hooks in settings files, because the evaluator is part of the hooks system. It is also unavailable when hooks are disabled by the disableAllHooks setting or restricted by allowManagedHooksOnly in managed settings. If a client's organization manages your Claude Code settings, the command tells you why it will not run instead of failing silently.

When a Goal Stops Early

A goal can end in more ways than met. Knowing them is what lets you leave one running and trust what you find when you come back.

• Impossible. The evaluator can judge that the condition can never be satisfied. Claude Code clears the goal and records a failed entry in the transcript with the reason. On client work this is useful information, not a failure: it often means two acceptance criteria contradict each other, and that is a conversation to have with the client now.
• No progress. If Claude keeps answering the evaluator without using any tools for several turns in a row, Claude Code stops the loop, prints a warning, and returns control to you with the goal still set.
• An error you have to fix. An authentication failure when Claude Code manages its own credentials, an exhausted credit balance, a context overflow that auto-compaction could not clear, or a model that is not available will clear the goal with a warning. You fix the cause and set the goal again.
• A pause. On Claude Code v2.1.269 or later in an interactive session, a failure that a retry would only repeat, such as an API rate limit or a claude.ai usage limit, pauses the goal with a notice naming the cause. Failures that tend to clear on their own, such as an overloaded server or a dropped connection, are retried automatically up to three times before the goal pauses.

The usage-limit case is the one to plan for on a deadline. A goal that runs many turns keeps drawing on your plan's usage while you are not watching, and hitting the limit in the middle of a delivery day is its own problem, covered in [what to do when you hit a rate limit during a client build](/blog/claude-code-rate-limit-during-a-client-build). Check /goal before you walk away. The status shows the turns evaluated and the token spend so far, and that is the number to watch.

If you close the session with a goal still active and resume it later, Claude Code restores the goal. It carries the condition over and resets the turn count, the timer, and the token-spend baseline. A goal that was already achieved or cleared is not restored.

What a Goal Costs and When Not to Use One

The evaluation itself is cheap. The docs say evaluation tokens are billed on the small fast model configured for your provider, which defaults to Haiku on the Claude API, and are typically negligible compared to main-turn spend. The real cost of a goal is the main turns it starts. A condition that takes thirty turns to satisfy costs thirty turns. That is the reason the stop clause is part of the Sign-Off Condition and not optional.

There are three cases where I do not use a goal on client work. The first is any task without a verifiable end state: design judgment, copy, anything where done means the client likes it. The second is discovery work on a codebase I have just taken over, where I want to read every step and a loop that keeps going is the opposite of what I need. The third is anything that touches production data or sends something to the client's customers. Those steps get a human approving each one, whatever mode the session is in.

When a fixed-price build starts running long, a goal will not rescue it. It will keep working toward the condition you wrote, and if the condition was wrong, it will spend your margin getting there. That situation is a scope conversation, laid out in [when a Claude Code build runs over budget](/blog/when-a-claude-code-build-runs-over-budget).