/goal is a powerful Claude Code command that makes your agent much more reliable and frees up the time you have spend watching over them.
It lets you give Claude an end state and have it keep working until it gets there.
Instead of prompting Claude one turn at a time and checking if it has achieved the results you want, you can define a clear result:
/goal all tests in test/auth pass and lint is clean.Claude then works across multiple turns. It tests its changes, responds to failures and keeps going until the goal is met or it needs you to step in.
This makes Claude Code much more useful for longer tasks like debugging, refactoring and migrations — you spend less time managing the agent and more time on higher-value work.
1. Goal-oriented execution: Spend less time supervising the agent
A normal coding-agent session often looks like this:
Prompt → Work → Stop → Continue → Work → Stop/goal changes the loop:
Goal → Work → Evaluate → Continue → Evaluate → DoneClaude checks the goal after each turn. If it has not reached the goal it keeps working.
This works well for migrations, refactors and test fixes — tasks that often need several attempts.
You free up your time as you no longer have to constantly supervise the mode. You define the outcome and spend more time on architecture, reviews or other work.
The key is to define a clear finish line:
/goal all authentication tests pass,
lint is clean and public APIs remain unchangedYou define where Claude needs to get — Claude works out the steps.
2. Evidence-based verification: Know that “done” really means done
More autonomy creates a problem. What stops Claude from deciding that the work is complete too early?
/goal separates doing the work from checking it.
The main Claude model writes code and uses tools. After each turn a smaller model checks whether the goal has been met.
It can use evidence surfaced during the session:
42 tests passed
0 failed
npm run lintProcess exited with code 0
That is stronger than Claude simply saying the problem should now be fixed.
The evaluator does not run commands itself — it checks the evidence already available in the conversation.
This creates a stronger definition of “done” for you. Tests, compiler output and command results can show that the work actually meets the goal.
3. Continuous self-correction: Debug for longer without stepping in
Most bugs do not disappear after the first fix.
Claude might change some code and run the tests. Three fail.
With a normal session it may stop and wait for another prompt.
With /goal those failed tests show that the goal is incomplete — so Claude can keep working.
Change → Test → Observe → Evaluate → Adapt → Test AgainClaude reads the error, changes its approach and tests again. It can also use background commands or delegated subagents during harder investigations.
For us developers this means fewer interruptions during debugging.
A bug that takes several attempts can become one continuous process — failure becomes feedback for the next attempt instead of the end of a turn.
4. Cost and quota protection: More autonomy without runaway usage
Continuous execution also creates risk.
If Claude gets stuck it could keep trying similar solutions while using more tokens.
Claude Code includes safeguards for this. It can detect several turns without useful tool activity or progress — then stop and return control to you the developer.
Goal checks also use a smaller and faster model by default.
So Claude Code can use the more capable model for engineering work — then use a cheaper model to check whether that work is complete.
You get more autonomy without giving the agent an unlimited license to keep running when progress stalls.
5. Session persistence: Hand off work that takes longer
Not every engineering task fits into one sitting.
Claude Code lets you resume sessions with commands like claude --continue and --resume. Active /goal state can carry into the resumed session.
If your goal was:
/goal all acceptance criteria are implemented
and the payment tests passClaude can return to that same finish line later.
This makes /goal useful for larger migrations, implementations and debugging sessions — not just quick tasks.
More broadly, /goal changes how developers work with coding agents.
Instead of managing each step: Fix this, Run the tests, Try again, Continue… you define the outcome:
Here is the state I want.
Here is how we know it works.
Keep going until that is true.
You define the finish line — Claude finds the path.