DevPawDEVPAW · GROUND-UP DEV NOTES
Search
Menu
EN
한국어English日本語繁體中文EspañolPortuguês简体中文
AI Coding & Agents

[Claude Code #6] /goal: How to Set Conditions for AI to Achieve

Claude Code /goal lets a separate judge model evaluate the goal every turn and continue working until the conditions are met. This covers condition writing, auto mode combinations, and completing runs headlessly.

4 min read
Cover image for [Claude Code #6] /goal: How to Set Conditions for AI to Achieve

When you assign a large task to AI, it keeps stopping midway, asking, “Three tests are still failing. Should I continue?”

Typing “Yes, continue” every time becomes the task itself. If you step away, the work simply remains there.

Claude Code’s /goal solves this with a condition declaration. Set achievement conditions, and Claude keeps working across turns until they are satisfied.

If Claude Code Part 5’s /rewind is a safety net, /goal is the completion mechanism.

How it works: There is a separate judge

The explanation of Official /goal documentation captures the key point. At the end of every turn, a small, fast separate model checks whether the conditions are met. If not, Claude starts the next turn instead of returning to the user.

This is not a setup where the working model declares, “I’m done.” A third-party judge model—Haiku, in the Claude API—evaluates every turn and leaves a brief reason. The evaluation tokens are negligible compared with the main task.

Once the conditions are met, the goal is automatically cleared.

Diagram of Claude Code /goal’s repeated turns and judge-model evaluation loop
Turns continue until the conditions are met

Basic usage

Write the conditions after /goal, and the turns start immediately. No separate prompt is needed.

/goal test/authall tests pass and lint is clean

While active, ◎ /goal active displays the elapsed time.

  • /goal (without arguments): Show the conditions, elapsed time, turn count, token usage, and the latest evaluation reason
  • /goal clear: Clear the goal before the conditions are met (stop, cancel, and others also work)

There is one goal per session. Setting a new one replaces the existing goal.

Writing good conditions is half the work

The judge model does not execute commands or read files directly. It evaluates only the output Claude leaves in the conversation.

Therefore, the conditions must be provable from Claude’s output. The official documentation recommends three elements.

  • One measurable completion state: test results, a build exit code, or an empty queue
  • Specify the verification method: a means of confirmation such as “npm test exits with 0”
  • Constraints to observe: for example, “Do not modify other test files”

If you are concerned about an endless run, add a clause such as “or stop after 20 turns” to the conditions. However, this is not a system-enforced upper limit. It is part of the condition that the judge model evaluates based on progress reports in the conversation.

Permissions are separate

/goaldoes not grant permissions. In the default permission mode, it still asks for approval for every disallowed tool call.

For unattended completion, pairing it with auto mode is the standard approach. auto mode removes tool-approval prompts, while /goal removes prompts between turns.

Here is how it differs from similar mechanisms. /loop repeats at time intervals, whereas /goal continues until the conditions are met.

The goal survives session interruptions

If a session ends while the goal is active, its conditions are restored when you resume with --resume or --continue. Only the turn count, timer, and token baseline start over.

You can also run it in headless mode without a terminal.

claude -p "/goal all items merged this week PRwill be reflected in CHANGELOG.md"

With one invocation, the loop runs until the conditions are met. In the default output, nothing is printed before completion, so it may look stuck. Add --output-format stream-json --verbose to see progress.

Hand-drawn illustration of writing “WRITE THE CONDITION” and a checklist of goal conditions
Completion state, verification method, and constraints: these three belong in the conditions

Summary

/goalis the command that presses “Continue” for you. Declare conditions, and a separate judge model evaluates every turn while the work continues until completion.

The key is condition design. Specify a measurable completion state and verification method, and include a turn-limit clause in the conditions.

The next part covers /background and /tasks, which send the entire session to the background. After the completion mechanism, this time we cover a delegation mechanism.

Sources and verification criteria

Continue reading

Claude Code series