Skip to content
Tools/Official Docs
Official DocsOfficial

Claude Code /goal

Official Claude Code feature for keeping Claude working toward a measurable completion condition.

Visit source
Reviewed 2026-07-21
Official documentation
Primary source reviewed

Source type: official-docs. License: not stated or not applicable. The linked source supports the visible capability notes but does not prove production suitability.

Open evidence source
Inference or recommendation
Verify before production

Confirm current maintenance, permissions, data handling, license obligations, failure behavior, and a human approval gate in your own environment.

Practical fit

Use /goal when the task has one durable finish line that may take several turns to reach. It is most useful when the agent can surface the evidence for completion in the conversation, such as a passing command, a finished migration, or a resolved set of review comments.

It is not a substitute for boundaries. A precise completion condition can still reward the wrong shortcut, so the goal should name both the evidence that counts and the changes that are forbidden.

How to evaluate it

Can the completion condition be checked from evidence the agent can show?
Does the goal cover one outcome rather than a backlog of unrelated work?
What stops the run if the condition cannot be reached safely?

Example decision

For one failing pull request, set the goal to make the existing CI checks pass with no deleted tests or unrelated edits, then stop for human review. This is a better fit than asking the agent to 'improve the repository' until it feels done.

Verify before you adopt it

Confirm the current /goal syntax in the official documentation.
Run the validation command once before the loop so the starting failure is recorded.
Keep merge, deploy, and other irreversible actions outside the goal.

Source review note

We reviewed the primary source on July 21, 2026. Product behavior, pricing, licenses, and maintenance status can change, so check the linked source before adopting it.

Best for

Durable coding goals
Multi-turn work
Clear validation conditions

Not for

Vague goals without a definition of done
High-risk actions without human approval

Risk notes

Requires a clear goal and stop condition.