Prospere AI - AI Automation Solutions for Business Growth

Claude /goal — one command, AI finishes the task

Claude /goal: the one command that forces AI to ACTUALLY FINISH the task

Most people prompt Claude like ChatGPT. Ask a question, get an answer, stop. Power users use one command — /goal — and that changes everything.

In this post I'll show you exactly:

  • What /goal does and how it differs from /loop and Stop hook
  • 4 rules without which the command is useless (3 from official docs + 1 from practice)
  • 3 proven copy-paste prompts (QA, feature, refactor)
  • 5 real-world use cases — from overnight bug fixing to API migrations
  • Why this economically changes how an AI agency works

Comment GOAL under my carousel on Instagram — I'll send you the full toolkit (10 prompts + workflow diagram + best-practices cheat sheet) by DM.

What is /goal

/goal is a built-in Claude Code command (requires v2.1.139 or later). You set a completion condition and Claude keeps working automatically until the condition is met — no need to prompt each iteration.

Mechanics from official Anthropic documentation:

  1. You type /goal plus a condition (up to 4,000 characters)
  2. After each turn, a small fast model (defaults to Haiku) checks whether the condition holds
  3. If no — Claude starts another turn with the "why not yet" reason as guidance
  4. If yes — goal clears, achieved entry lands in the transcript
  5. While active, a ◎ /goal active indicator shows duration

The evaluator does not call tools. It only judges what Claude has surfaced in the conversation. The condition must be something Claude's own output can demonstrate.

What the developer community calls a "Ralph loop" — a pattern where AI verifies its own work instead of declaring "looks good." Anthropic shipped this as an official command.

How /goal differs from /loop and Stop hook

Three approaches keep the session running between prompts. Pick based on what should start the next turn:

Command Next turn starts when Stops when
/goal Previous turn finishes A model confirms the condition
/loop A time interval elapses You stop it or Claude decides the work is done
Stop hook Previous turn finishes Your own script or prompt decides

/goal is a session-scoped shortcut — active only in the current session. Stop hook lives in your settings file and applies to every session in its scope.

Combine /goal with Auto mode — which approves tool calls within a turn. Auto mode removes per-tool prompts, /goal removes per-turn prompts. Together = full autonomy.

Get the full toolkit — workflow diagram + 10 prompts + cheat sheet. Drop your email below, we'll send the PDF.

4 rules without which /goal doesn't work

Here's the catch. Command quality = output quality. Official docs list 3 elements of a good condition. In practice I add a fourth — time budget. Without all four the command stalls, takes shortcuts, or stops prematurely.

Rule 1 — Measurable end state

❌ "Fix the code" ✅ "All tests in test/auth pass + lint is clean"

From docs: "one measurable end state — a test result, a build exit code, a file count, an empty queue". Something with a binary answer: yes or no.

Rule 2 — Stated check (how to prove it)

❌ "Make it work better" ✅ "npm test exits 0, coverage > 90%, lint clean"

From docs: "a stated check: how Claude should prove it, such as 'npm test exits 0' or 'git status is clean'". A concrete command or file state to verify.

Rule 3 — Constraints

❌ "Refactor the API" ✅ "Refactor API to v2. DO NOT delete tests. Max 15 files changed. Performance ±5%."

From docs: "constraints that matter: anything that must not change on the way there". Without this Claude can "take shortcuts" — delete annoying tests.

Rule 4 — Time budget (from practice, NOT docs)

❌ No time limit — session can drag for hours ✅ Add or stop after 20 turns or or stop after 60 minutes to the condition

From docs: "To bound how long a goal runs, include a turn or time clause in the condition". Claude reports progress against that clause and the evaluator sees it.

3 copy-paste prompts

Copy, adapt to your project, run in Claude Code with Auto mode on (Shift + Tab cycles in CLI: default → acceptEdits → plan → auto).

Prompt 1 — QA / autonomous bug fixing

/goal all tests in test/auth pass and the lint step is clean, or stop after 20 turns

The minimum. Brilliant for "leave it overnight, check in the morning." Practical use case: after a big merge auth tests fail — fire /goal, go to bed. In the morning Claude shows what it fixed + reason for each iteration in the transcript.

Prompt 2 — feature implementation with verification

/goal implement dark mode matching the Figma spec, all components updated,
test coverage >90%, no console errors, performance impact <5ms on load,
do not modify existing API contracts, or stop after 30 turns

Claude doesn't just build the feature — it must prove with tests that it works. You get feature + test coverage + perf benchmark in 1 session.

Prompt 3 — refactor / migration

/goal migrate all API calls to the new v2 client, update error handling,
all existing tests pass, add 3 new integration tests, no new TypeScript errors,
do not delete any existing tests, max 25 files changed, or stop after 40 turns

The hardest use case — a large migration. With /goal Claude does it systematically and checks progress after each change.

Operational commands

Status check

Type /goal with no args to see:

  • Current condition
  • Duration
  • Number of evaluated turns
  • Token spend
  • Evaluator's most recent reason

Clear goal

/goal clear

Aliases: stop, off, reset, none, cancel. Running /clear (new conversation) also removes any active goal.

Resume sessions

A session resumed with --resume or --continue restores the active goal. However: turn counter, timer, and token-spend baseline all reset. A goal already achieved or cleared is not restored.

Non-interactive mode

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

Works in headless mode and through Remote Control.

5 real-world use cases

1. Autonomous QA / bug fixing

The classic. "Fixing tests" usually eats 2-3 hours. With /goal — fire before sleep, ready in the morning. An 8-hour Claude session > 30 min of your review.

2. Large refactor / migration

Design system migration, library upgrade, pattern changes across the codebase. Traditionally 2-3 days of work. With /goal + clear constraints — full sweep in 1 session.

3. Feature implementation with proof

Build feature + prove with tests. Without /goal you get "it works" declared by Claude. With /goal you get the tests that confirm it — because the evaluator reads them from the transcript.

4. Tech debt cleanup with quality gates

Backlog burn-down. Set /goal to "fix N items from backlog, each must pass test X, do not introduce new warnings." Claude methodically closes tickets.

5. Long autonomous sessions

Fire /goal with a large scope before lunch or before bed (best in Auto mode), walk away. Check the output and achieved entry in the transcript later.

Requirements (from official documentation)

/goal will not work if:

  • Claude Code version < v2.1.139
  • You haven't accepted the workspace trust dialog (evaluator is part of the hooks system)
  • disableAllHooks is set at any settings level
  • allowManagedHooksOnly is set in managed settings

Auto mode (which lets /goal work without permission prompts) requires:

  • Max, Team, Enterprise, or API plan (NOT Pro)
  • Does not work on Bedrock, Vertex, Foundry
  • CLI/JetBrains: cycle with Shift + Tab (default → acceptEdits → plan → auto)
  • VS Code: enable "Allow dangerously skip permissions" in extension settings
  • Desktop: mode selector next to the send button

In all cases, if /goal won't work — the command tells you why instead of silently doing nothing.

Why this changes the economics of an AI agency

Standard Claude prompting — even in Claude Code — often means "mid-task drift" and premature stopping. Which you fix across 3-5 sessions.

/goal anchors Claude to persistent success criteria. Claude behaves like a $200/h senior engineer — one who finishes the job instead of saying "looks good to me, let me know if you need anything else."

Practical consequence for an AI agency:

  • Before: 5 sessions × 30 min = 2.5h of your time per task
  • With /goal: 1 session × 5 min setup + autonomous in the background = ~5 min of your time

That's a 20-30× productivity improvement for a typical refactor / feature task.

Economically: instead of pricing projects as "hours + rescue overtime" — you price strategy + verified deliverable. Hours billed → outcome delivered.

Evaluator cost is typically negligible compared to main turn spend (Haiku as default). Evaluator tokens are billed on a separate small model.

Most common mistakes (and how to fix them)

Mistake 1 — vague goals → vague output

"Make it better" → Claude improvises. Doesn't converge, evaluator has nothing to judge.

Fix: ALWAYS apply all 4 rules. The condition must be something Claude's own output can demonstrate in conversation.

Mistake 2 — no constraints → Claude takes shortcuts

Without "do not delete tests" Claude can remove annoying tests just to pass the check.

Fix: Explicitly list what NOT to do. "Don't delete X, don't modify Y, keep Z intact, max N files changed."

Mistake 3 — condition requires things not present in the transcript

The evaluator doesn't call tools. Doesn't read files independently. It only judges what was already said in the conversation.

Fix: Every condition MUST include explicit "show proof" that Claude must surface to the transcript. E.g., "run npm test and show 0 failures in output."

Mistake 4 — Auto mode off → Claude asks for every change

Without Auto mode Claude requests approval for every terminal operation. The loop never closes because it waits for your OK.

Fix: Enable Auto mode (Shift + Tab cycles through modes in CLI). Requires Max/Team/Enterprise/API plan.

Mistake 5 — no time budget → goal drags for hours

Without or stop after N turns a goal can drag on if the condition is impossible to meet.

Fix: Always add or stop after 20 turns (or a time clause) as a safety net.

What's next

The /goal command is one of the foundations Claude Code power users leverage daily. The full workflow — combined with /loop, Stop hooks, and Auto mode — is autonomous engineering most agencies haven't yet implemented.

If you're building a product / application / system in 2026 — or using Claude in an agency — /goal should be the first thing you learn after the basic prompts.

Comment GOAL on my Instagram (@prospere.ai_) under the /goal carousel — I'll send you the full toolkit:

  • 10 proven /goal prompts (PL + EN) — ready to copy-paste, per use case
  • Workflow diagram /goal + /loop + Stop hooks + Auto mode
  • Cheat sheet of the 4 best-practice rules
  • Bonus: agency economics with /goal — case study

Or drop your email below — we'll send the PDF + a 5-day deep-dive series (autonomous overnight runs, common pitfalls, how to debug /goal when it doesn't converge).

Official source: code.claude.com/docs/en/goal (Anthropic, verified 2026-05-21).

Bartek — prospere.ai · linkedin.com/in/bartlomiej-golebiowski