Big Idea

The argument in one line.

The /goal command turns Claude Code into an autonomous loop that runs until a second model declares the condition met from the transcript alone, which means vague conditions pass on hallucinations and specific proof-naming conditions do not.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

A developer who uses Claude Code day-to-day and wants to hand off multi-step feature work without babysitting each turn.
A solo builder or freelancer shipping client apps who wants to fire off a feature and check back when it is done.
Someone who has tried long agentic prompts and had Claude stall out or produce incomplete results.

SKIP IF…

You are new to Claude Code itself -- this assumes you already have it running and know the basics.
You want a cost or speed benchmark comparing /goal to normal prompting -- no numbers are given here.

TL;DR

The full version, fast.

/goal sets a condition and spins up worker agents (Sonnet or Opus) that loop until a separate Haiku evaluator declares the condition met from the text transcript alone. A vague condition will pass the evaluator even on a hallucination; conditions must name the proof method (toggle clicked, localStorage persists, screenshots reported). Cap turns with stop-after-N-turns to prevent runaway token burn. Use /goal for multi-turn feature work with a verifiable end state; skip it for simple tasks or subjective work.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:29

01 · Hook and agenda

Goal command shipped 48 hours ago. Video covers how it works, live demos, and when to use it.

00:30 – 01:28

02 · Basic usage

/goal, /goal clear, turn limit flag, token usage warning.

01:28 – 02:58

03 · Worker/evaluator architecture

Flowchart: user sets condition, worker agents execute, evaluator (Haiku) reads transcript only, loop continues until condition met or goal cleared.

02:58 – 03:48

04 · Demo 1: LifeOS deep work timer

Circular elapsed countdown timer built in 9 minutes, passed evaluator on first turn.

03:48 – 05:09

05 · Demo 2: Recruitment CRM AI chat page

Full new AI chat page with LLM agent, candidate matching, draft emails, built in 5 minutes with Dribbble reference.

05:09 – 06:00

06 · Good condition vs bad condition

Bad: dark mode works. Good: toggle clicked, data-theme flips, localStorage persists, CSS variable updates, screenshots reported. 4000-char cap.

06:00 – 07:30

07 · When to reach for /goal vs skip it

Use: multi-turn, verifiable end state, migration/refactor, headless cleanup. Skip: simple tasks, subjective work, conditions Claude cannot prove. Use /loop for polling.

07:30 – 07:50

08 · Subscribe CTA

Subscribe for AI workflows and latest tech news.

Atomic Insights

Lines worth screenshotting.

The evaluator in /goal runs on Haiku by default and reads only a text transcript -- it cannot inspect files, run tools, or check the browser.
A condition like dark mode works will pass the evaluator even on a hallucination because there is nothing in the transcript to disprove it.
Conditions must name the proof method: toggle clicked, data-theme flips, localStorage persists, CSS variable updates, screenshots reported.
Worker agents can use Chrome MCP to produce verifiable browser evidence in the transcript; the evaluator cannot.
Both live demos completed in a single evaluator turn, meaning the workers satisfied the condition on the first attempt with no retry.
Adding stop-after-N-turns is the safety valve that prevents uncontrolled token burn on an underspecified goal.
/loop is the right tool for polling external state on an interval; /goal is the right tool for feature completion with a definable end state.
Passing a Dribbble reference image inside the goal prompt materially improved visual fidelity on the chat page demo.
The evaluator model can be changed from the Haiku default -- useful when you need more rigorous judgment on complex completions.
Conditions have a 4000-character ceiling, which is enough to describe any real feature in verifiable detail.
One-shot full-stack Next.js features are achievable if the condition is precise enough about scope and verification surfaces.
When the goal path is unknown (migration, refactor), /goal lets you state the end state without micromanaging the route.

Takeaway

How the /goal loop decides it is done.

WHAT TO LEARN

The evaluator that grades your /goal reads only a text transcript and has no tool access, so the quality of your condition determines whether it finishes correctly or passes on a hallucination.

The evaluator agent (Haiku by default) reads only the text transcript from the worker run -- it cannot open files, run tools, or inspect the browser state.
A condition that describes only an end state (dark mode works) can pass even when the feature is broken; conditions must name the proof method (toggle clicked, localStorage persists, screenshots in the transcript).
Worker agents can use Chrome MCP to generate verifiable evidence in the transcript; build that into your conditions so the evaluator has something concrete to check.
Capping turns with stop-after-N-turns prevents uncontrolled token burn when a condition is underspecified or the task turns out harder than expected.
/loop is the right tool for polling external state on an interval; /goal is for completing a feature whose end state you can define and verify.
Short two-turn tasks do not need /goal -- the overhead of the evaluator loop adds latency and token cost with no benefit for work that can be done in a single prompt.
Including a reference image (Dribbble, screenshot, existing screen) inside the goal prompt gives workers a concrete visual target and measurably improves fidelity on UI work.

Glossary

Terms worth knowing.

Worker agent: The Claude model (Sonnet or Opus) that executes code edits, runs tools, and uses MCP on each turn of the /goal loop. One or more can run per turn.
Evaluator agent: A separate Claude model (Haiku by default) that reads only the text transcript of the worker run and decides whether the stated condition has been met. It has no file or browser access.
Next-turn guidance: When the evaluator returns a no, the reason it gives becomes attached to the next worker turn as context so the workers know what is still missing.
/loop: A separate Claude Code slash command that reruns a prompt on a fixed interval (e.g. every 5 minutes), designed for polling external state rather than completing a feature.

Resources

Things they pointed at.

00:57linkClaude Code /goal Docs ↗

00:57linkClaude Code v2.1.139 Release Notes ↗

00:57linkClaudeLog Changelog ↗

00:57linkChrome DevTools MCP vs Playwright MCP ↗

Quotables

Lines you could clip.

02:05

“It's important to note that this actual agent can't inspect the work. It just has the transcript.”

Counterintuitive architectural fact that changes how you write conditions -- standalone without any setup→ TikTok hook↗ Tweet quote

05:45

“The end state alone is not enough. Just saying dark mode is not it.”

Punchy rule, immediately actionable, no context needed→ IG reel cold open↗ Tweet quote

05:09

“Write conditions that name the proof method.”

Single-sentence framework that applies to every /goal use→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

analogy

The long awaited goal command in Code has shipped. It's now available in Claude Code as of about forty eight hours ago.

If you don't know, this lets you set a condition, and Cloud Code will work on that task until it is completed.

A must have tool in your toolkit. By the end of this video, you'll understand all the flexibility you have with the goal command, how the agents work under the hood. We'll demo a couple uses of goals and teach you how to effectively get the most out of this command.

I'm Matt Kuda. Let's dive in. Using goal is straightforward in Cloud Code.

Make sure you update your Cloud Code. If you haven't, then use slash goal, and you'll see the command there.

Set a goal. Keep working until the condition is met. Looking at the docs here, they give a bunch of examples, explain how it works, how to write effective conditions, which we'll talk about later.

You can use slash goal again to see the status of the goal or slash goal clear to clear a new one. You could also add on additions like stop after 20 turns so that way it doesn't burn through all your tokens because this goal command will possibly up your token usage.

Now let's talk about how the actual loop works under the hood. So you, the user, put in your goal here.

So goal, add a user settings page. And then worker agent or agents are gonna spin up to work on this task.

They're gonna be Sana or Opus depending on what you have set. Now these agents work just like the ones when you prompt Cloud Code. They can edit the code, run tools, use MCP, stuff like that.

Then when they're done, they're gonna give a text transcript to a separate evaluator agent.

Now this is Haiku by default. That can be changed. It's important to note that this actual agent can't inspect the work.

It just has the transcript of what the worker agents give you. Now this agent will say, based on that transcript, is the work done or not?

If it's a no, it's gonna go back into the worker agent. They'll have a new reason that becomes this next turn guidance to operate off.

So if you wanted to build a settings page, these guys build it out, but there was no default dark mode toggle.

The valuer agent says, hey. Not in there. That missing default dark toggle will be in this next turn guidance, then the workers will complete it again in a new turn.

So this loop will continue until the goal is met determined by the evaluator, which case the goal is cleared and full control is given back to the user. Okay.

Now let's see this goal feature in action. So here I'm in my LifeOS application where I track my tasks, deep work, goals, stuff like that.

And the deep work page isn't very fleshed out. The styling is not great. I can't set a goal limit.

Clearly not complete. So I'll go to Cloud Code using the goal command. I'll give it a pretty thorough prompt on exactly what I want, what the conditions are, like a circular elapsed countdown time, and allow people to add deep work sessions outside of the timer.

So when I kick this off, this prompt again will get sent to the worker agents and will continue to work until the evaluator deems it as done. And after nine minutes and only one turn, meaning the evaluator agent approved the work on the first try, We can see the feature is done.

Here, we have the stopwatch functionality or count now, which is what you wanted. Click start.

We get that nice elapsed circle thing here. Probably a couple style things I'd still give as feedback.

As another example for how far you can push this goal feature in this recruitment CRM I'm building for a client, we have AI matching functionality to put candidates to positions.

Though right now, you could really only do this through the candidate page along with some other features like drafting follow-up emails. So I wanted a dedicated AI chat page that had an agent that could do any of these tasks based on what the user is chatting on and keep it all in context. So for my goal command, I was pretty thorough about what I wanted, a full new page, use a LLM agent, no need to store chat history.

So I had what I wanted and what I didn't want just so it didn't go overkill and burn too many tokens and knew what the scope was. So this ran for, let's see, only five minutes and one turn, and it got it done.

Did have a little style follow-up prompt at the end. And if we go to this page, it is exactly what we wanted, a free form text box with some ready prompts already to show off the tools available. I did pass it a dribble example just for some inspiration.

Highly recommend doing that in general, and it was able to nail it in one turn. And when you're using the goal command, you wanna make sure your conditions are thorough. Right?

A bad command might just be dark mode works. You know? That can mean a lot of things, but having a good prompt, like, there's a toggle clicked, the data theme fixed, that works with your style guide, local storage to store it, CSS variables, screenshots reported.

That way, your worker agents can use Chrome MCP. Remember, your evaluator agent can't. But in my tasks, all the worker agents do have access to that to formalize the transcript.

So make sure you're thorough. And remember, just the end state is not enough. Just saying dark mode is not it.

Add as much context as you have. Use voice to text to really get it down easily.

Remember, the condition can be a max of 4,000 characters, but that should be plenty for an effective goal. So when should you use goal and when to skip it?

Anything that has multi turn work such as build the settings page, then build the APIs on top of it, then use Chrome MCP to verify it. That'd be a great use case for GOL.

Or if there's a big migration or refactor where the work is a little vague, the path is unknown, use GOL to state exactly what you want, what you currently have, put that in your condition.

Any big features you wanna try to one shot similar to the Ralph Wiggum loop as before. I'm sure you could build a lot of full stack Next. Js apps if you're crisp enough with what you want and you don't want it to stop and ask requirements just to work until it's done.

And any type of headless runs, like you wanna clean up all your backlog, get that work done, you can use goal. When to skip it, subjective work with no clear end state. Like, if you were just to say improve the onboarding experience, that'd be a little vague because you wouldn't have actually the requirements for the screens and questions you wanna ask there.

Simple stuff like fix the styling on this button or show the username on the top right. No need to use goal. Just prompt directly.

Save yourself the time. Any conditions that Claude can't prove in the transcript, whether it doesn't have tool access or it's way too vague, don't use goal for that. If you wanna pull eternal state consistently, use the slash loop command.

This will allow you to run a command every five minutes. Like, hey. Check this endpoint.

Pull every five minutes until the cache is cleared. I wanna make sure our changes went live. That will do it for today's video.

If you learned anything, you are obligated to like. Subscribe for more AI workflows like these and the latest news in the tech world. Thank you guys so much for watching.

I'll see you in the next one.

The Hook

The bait, then the rug-pull.

Forty-eight hours after shipping, the /goal command already has a clear failure mode baked in -- and the video opens by naming it before most developers have even typed the command once.

Frameworks

Named ideas worth stealing.

05:09concept

Good Condition vs Bad Condition

Bad: state end result only (dark mode works)
Good: name the proof method (toggle clicked, data-theme flips, localStorage persists, CSS variable updates, screenshots reported)

The evaluator can only read the transcript, so conditions must give workers something provable to produce.

Steal forAny agentic task where you need the model to self-verify before finishing

06:00list