With how fast AI companies have been iterating, we're now at the point of this technology where all the feature launches sound like variations on the same thing. No matter how often you use AI, one term that has surely made it to your daily vocabulary is "prompt," and it's become such a reflex that every new feature gets quietly filed as just another way to prompt.

That's exactly the road I took when Anthropic launched the new /goal slash command within Claude Code. I treated it like a fancier prompt, typed in what I wanted, and didn't really see what was so special about it. That's when I figured I was using it all wrong.

The /goal command pushes Claude to keep going

It keeps working until a condition is met

While Claude Code and other AI tools in a similar vein are certainly not limited to just programmers, I'm assuming you know some of the basics if you're willingly reading an article about a slash command that Anthropic launched. The best way to understand what the /goal command does is to picture a while loop.

Normally, Claude Code runs like a function call. You ask it for something, it does the work, it stops, and hands control back to you. From there, you check what it did manually, and you either approve it or tell it what to fix next. For instance, if you're working on a coding problem and have a few test cases you're trying to pass, Claude takes a crack at it, stops, and waits. You run the tests yourself, see what failed, paste the errors back, and it tries again. You repeat that little back-and-forth until everything's green.

The /goal slash command changes that. Instead of stopping after one pass, it keeps looping until a condition is met. I like to think of it as:

You set a condition, and Claude doesn't return to you until the condition you set is fully met or until you stop it manually. If you've ever read a system card that Anthropic publishes when it drops a new model, you're likely familiar with how a model can game a task and quietly find a shortcut that technically satisfies what you asked for while completely missing what you meant. That's exactly the risk you'd run if Claude were left to grade its own work here and analyze if it should keep going.

Ultimately, the condition isn't checked by the model doing the work. There's a second, smaller model whose only job is to read the session transcript and decide one thing — has the goal been met, yes or no? That's the entire crux of the /goal slash command. Without this command, you'd typically need to sit there and drive that loop yourself. You read each result, decide whether it's good enough, and type "keep going" or "no, fix this," until it finally is. The /goal command just moves that job off your plate and keeps iterating until the condition you've set is met.

/goal only works if the finish line is measurable

If the evaluator can't check it, the loop can't stop

Now, here's where the "not treating it like a prompt" bit comes in. The issue with how I was using the /goal command for a while was that I wasn't really giving it a finish line it could actually check. So, for instance, say I'm done with a coding session but I want my code to be a bit cleaned up. My definition of clean and a LLM's definition of clean is likely worlds apart. Worse, there's really no way to measure it. There's no command the evaluator can run, no output that flips from a "no" to a "yes," no point where "messy" objectively becomes "clean." So the loop is left guessing, and it'll either keep churning on something it can't actually finish or quietly decide it's done the moment it feels like it.

With the /goal command, the key is giving it a finish line that's actually measurable. So, something the evaluator can point a command at and get a clean yes or no. "The test suite passes." "The build exits with code 0." "This file prints exactly this output." Conditions like that work because there's no interpretation involved. You run the check, and the answer is either true or it isn't. That's the whole difference between a prompt and a condition.

And that links back to treating the /goal command as a prompt. A prompt can be open-ended because you're the one reading the result and deciding if it's good enough. However, a condition can't. It either resolves to a yes or a no, and there's no good enough in the middle.

What it actually looks like in practice

It goes on and on and on

For instance, when I was looking for a solid way to test the /goal command, I remembered a problem set I was trying to solve a while back where I went down the exact rabbit hole that the /goal command is supposed to solve — fix, run, fail, fix, run, fail, over and over. Now, I'm not going to go too deep into the weeds and explain what the question was and the bug that was slowing me down, but the important part is that it was the perfect candidate for /goal. The finish line was about as measurable as it gets: there was exactly one correct output, and a test that either printed a clean pass or a fail. The exact prompt I used with the /goal command was:

/goal running javac Zoo.java ZooTest.java && java ZooTest exits 0, without modifying ZooTest.java and without hardcoding the printed lines — the output must be produced by the Zoo constructor's distribution logic

Notice how everything is packed into one line. The measurable end state (the test command exits 0), the way to check it (javac Zoo.java ZooTest.java && java ZooTest), and the constraints (don't touch the test file, don't hardcode the answer). That last part matters, because without it the easiest way to "pass" is to just print the five expected lines and skip the actual logic entirely.

When I ran this on Opus 4.8, it cracked the fix in about two minutes. The loop didn't really show up, and the model just saw the bug, fixed it, ran the test, and the evaluator confirmed the goal was met. So, I switched to a weaker model, Haiku 4.5, and ran the exact same goal on the exact same broken code. Haiku couldn't see the fix the way Opus did. It tried a restructure, ran the test, failed. Tried a different approach, ran the test, failed again. Then it started spawning diagnostic files, running background shell commands, and at one point it gave up reasoning about the problem entirely and delegated to a subagent to brute-force search for the right answer.

It took 25 minutes to get to the answer and 46,000 tokens, but what I'm trying to illustrate here is that the entire time, I didn't type a single thing. That was all /goal. It kept reading the failure, kept deciding the condition wasn't met, and kept sending the model back in — over and over, for 25 minutes straight, without me driving any of it. That's the loop working exactly as designed. It just looks very different depending on the model underneath it. Without the /goal command, I'd need to sit there for every one of those 25 minutes, reading each failure myself, deciding it wasn't done, and typing "keep going" or "try this instead" every single round.

The /goal command is perfect for the tasks you don't want to babysit

So, the /goal command and a classic prompt aren't really meant to be used interchangeably. A /goal command needs a measurable finish line, clear constraints, and a condition a second model can actually check. Give it that, and it'll grind through the boring, repetitive work you'd rather not babysit. This way, you can walk away and come back to a passing test.