The /goal Command: Give Claude a Finish Line and Walk Away

Here's the change that makes everything else click. For years we used AI like a power tool: hand it a small task, watch it work, catch where it stopped early, hand it the next chunk. You were the supervisor and the AI was the drill. With a frontier-class model (the source video calls it 'Fable 5' — its stand-in name for Claude's most capable model), Anthropic's own Claude Code team describes the inversion plainly: they used to check whether Claude was doing the work right; now they increasingly check whether it's doing the right work. The model can run for hours, test its own output, and often produces better code than they would by hand. Their job moved from supervision to direction and setup. That is the whole game of this series: stop giving Claude tasks like it's a tool, and start giving it responsibilities like it's on your payroll. A tool stops when the obvious step is done. An employee with a goal keeps going until the job is actually finished.

/goal is a real, shipped Claude Code command (it landed in version 2.1.139 in May 2026). You give it a high-level objective plus a completion condition, and it stops being a one-prompt-one-reply assistant. The trick is in how it knows when to stop: after each turn, a small, fast evaluator model checks whether your completion condition is met. If it isn't, Claude takes another turn — observe, act, check — and it keeps doing that until the condition is satisfied, at which point the goal clears itself and hands control back to you. That evaluator is the magic. It formally separates the agent that does the work from the judge that decides it's done, so the agent can't just declare victory and quit early. Older models behaved like a contractor who leaves at 5pm whether or not the job's finished. With /goal, the loop doesn't break until the finish line is crossed.

• It is invoked as: /goal followed by your objective and your definition of done.
• A separate fast evaluator model checks the completion condition after every turn — execution and judgement are split on purpose.
• It loops (observe → act → verify) and only returns control when 'done' is provably true.
• The goal clears automatically once met — you don't have to babysit or manually stop it.
• It works in interactive mode, in headless mode (the -p flag), and via Remote Control / mobile — so a long job can run while you're away.

Most people write the objective and forget the finish line — and a goal without a checkable 'done' is just a wish. The evaluator can only loop you to completion if 'completion' is something it can actually verify. So the real skill isn't describing the work; it's describing the proof. A good goal has two halves: (1) the spec — plainly what you want built or done — and (2) a definition of done the model can test by itself, not a vibe. 'Make it nice' is unprovable. 'Builds with zero errors, all tests pass, the page loads and renders without console errors' is provable. The tighter and more checkable your 'done', the more autonomously the agent can run, because it never has to come back to ask whether it's finished.

• Weak 'done': 'a good Minecraft-style game.' Unprovable — the loop has nothing concrete to check.
• Strong 'done': 'a playable browser game that runs with zero console errors, lets you move, place and break blocks, and never crashes on a 5-minute play session.'
• Make 'done' testable: compiles / passes tests / produces a named output file / hits a measurable threshold.
• Bundle the verification in: ask it to run the tests or open the result and confirm, not just to claim it's done.
• If you can't write a checkable 'done', the task isn't ready for /goal yet — tighten the spec first.

This is the whole loop, start to finish. You're in Claude Code (the terminal/desktop agent, not the chat box — long-running jobs and file output belong in Code). The steps are deliberately short because the work is in the spec, not the ceremony.

1. Open Claude Code and make sure you're on the most capable model — in the model selector pick the top-tier 'Fable 5' / frontier model (the source notes it may only appear after you quit and reopen the desktop app once after the release). This is the model built for long, agentic jobs.
2. Write the spec in plain language: what you want built or done, and exactly what working means — the provable 'done' (compiles, tests pass, named file produced, runs with zero errors).
3. Type /goal, paste your spec + 'done', and run it. For a big job, kick it off and walk away — overnight on a spare machine is exactly the use case. Come back to a finished result and review it.

This is a fill-in template that bakes in the two things that make goals work: a concrete objective and a finish line the agent can verify on its own. Swap the brackets for your task. The structure matters more than the example — keep the explicit 'Definition of done' and 'Keep working until' lines in every goal you write.

• PROMPT (paste after typing /goal):
• Build [what you want — e.g. a playable browser Minecraft-style block game with move, place and break].
• Definition of done (all must be true): (1) it builds/runs with zero errors; (2) [the core thing works — e.g. I can move, place and break blocks]; (3) it survives a [5-minute] run without crashing or console errors; (4) you have opened/run it yourself and confirmed each of the above.
• Keep working until every item above is provably true. Find and install whatever libraries you need. Test your own work after each change; if a check fails, fix it and re-test — don't stop and ask me unless you hit a genuinely ambiguous decision.
• When done, write a short report of what you built, what you verified, and anything you'd flag for me to review.

A Minecraft build is a fun demo, but the point is what it represents: jobs that are too long and too tedious to babysit. Because /goal can run for hours and the model tests its own work, you can hand off the kind of task that used to eat an evening — and let it grind while you sleep or do something else. In the walkthrough, the creator literally runs these on an always-on Mac Mini so the agent can keep looping in the background. The mental model: queue the job before you log off, define 'done' tightly, walk away, and review the finished result in the morning.

• Codebase clean-up that runs overnight — refactors, dead-code removal, dependency bumps, with tests as the 'done'.
• Migrations to completion — e.g. move every call site from a v1 API to v2 until the whole project compiles.
• Grinding a backlog to empty — work a list of well-specified tasks one by one until none remain.
• Build-something-from-a-spec jobs where 'done' is 'it runs and passes its own checks'.
• A spare always-on machine (a Mac Mini, a cheap VPS) is the ideal home for these — the agent loops there while your main machine is free.

Treating Claude like an employee includes managing it like one. /goal is safe and powerful for jobs with a checkable, self-contained finish line. It is NOT a licence to let an agent loose on anything irreversible without you in the loop. Two rules keep you out of trouble.

• Scope the goal to work that's reversible and checkable — building, refactoring, generating, migrating with tests. Great fits for an unattended loop.
• Keep a human review on anything that touches the outside world or can't be undone: sending messages, spending money, deleting data, pushing to production. Let the agent prepare it; you approve and pull the trigger.
• Write a 'done' the evaluator can actually verify. A vague finish line either loops forever or stops too early — both waste a run.
• Skim the agent's end-of-run report. A two-minute read on a job that saved you three hours is the cheapest insurance there is.

This guide is Part 1 of 5. Each part puts Claude on the payroll for a different job — and they build on the same /goal + workflows foundation you just learned. Bookmark the ones you want next.

• Part 1 — The /goal command: give Claude a finish line and walk away (you're reading it). guides.kno2gether.com/fable5-payroll-goal
• Part 2 — The bookkeeper: Claude reads your statements and cancels the subscriptions you forgot you were paying for. guides.kno2gether.com/fable5-payroll-bookkeeper
• Part 3 — The ad-maker: one agent generates a folder of image + video ads and QAs them into approved vs rejected itself. guides.kno2gether.com/fable5-payroll-admaker
• Part 4 — The red-team researcher: spin up sub-agents to argue both sides of an idea and pressure-test it (research rigour, NOT financial advice). guides.kno2gether.com/fable5-payroll-redteam
• Part 5 — The client-finder: find the right people, research each one, and draft personalised outreach you review before sending. guides.kno2gether.com/fable5-payroll-clients