"Did you do everything I asked?"
"You skipped this - review it again."
"You need to do this part too."

You hand a job off to an AI, and then checking the result becomes a job of its own.

If it's the kind of thing you'll end up going back over anyway, you're better off setting it with /goal than tossing it out as a single prompt.

The /goal here is a feature of Claude Code and Codex. How to turn it on, and the version requirements, are at the very bottom.

Why I keep ending up as the checker

The reason is simple. A model stops once the work "looks done."

The moment an agent stops responding is itself a declaration that it's "finished." But the basis for that judgment isn't whether the work is actually done - it's whether it looks done. The two are not the same.

Anthropic wrote this problem into its official docs.

Claude stops when the work looks done. ... "looks done" is the only signal available, and you become the verification loop.

So "Are you done?" is really a question there's no need to ask. The fact that it stopped already means it's "done."

The question that's actually still open is a different one. Did it do everything it was told, with nothing missing? That part falls to a person.

What /goal actually does

If you see /goal only as "a command for setting a goal," you've seen half of it.

The core is taking the done-or-not call out of the working model's hands.

When you set a goal, that prompt plays two roles at once. It's the starting instruction, and it's the completion criterion. You have to write both what to do and what state counts as finished.

/goal Polish this draft into a publishable piece. Sort out the title, subtitle, lead, the flow of the body, and the conclusion, and don't state unverified things as fact. At the end, write a summary of your edits and a list of items that still need checking.

It's not good because it's long. It's good because the end is in view.

Claude Code and Codex confirm "done" differently

It's the same /goal, but Claude Code and Codex confirm completion in different ways. Knowing this difference gives you a feel for how far to trust each.

Claude Code swaps in a different grader.

When you set a goal, at the end of every turn a different small model (Haiku by default) judges separately whether the condition holds. If it comes back no, instead of handing control back to you, Claude starts the next turn. In the docs' own words, completion is decided by a fresh model, not the one that did the work.

completion is decided by a fresh model rather than the one doing the work

Codex demands evidence from the same model.

Codex doesn't set up a separate model. The working model itself judges completion. Instead, OpenAI baked two things into the instruction injected at the end of every turn (the repository's continuation.md). One, don't shrink the goal into an easier task to fit a single turn. Two, treat completion as not proven, and verify it against the actual state.

It's the same problem solved by a different route. One side swapped the grader; the other demanded evidence from the grader.

Why pull the grader out at all

Before releasing /goal, Anthropic made this diagnosis in a separate engineering piece: when you ask an agent to evaluate the work it produced, it tends to confidently praise it even when the quality is plainly mediocre to anyone watching. And it wrote that "separating the model doing the work from the model judging it" is a strong lever.

That piece doesn't mention /goal directly. So I can't state for certain that this is "the reason /goal was built." Still, when I line up the design thinking the same company published around the same time, /goal's separate evaluator looks like that thinking put into a product.

Bringing Codex in makes it more interesting. Two companies shipped a command feature under the same name, and both appear to stand on the same assumption - that a model doesn't judge well on its own whether it has finished. One handles that assumption by separating the grader, the other by forcing evidence.

This is my own read from lining the two designs up, not anything either company has stated officially.

Four basics for a /goal prompt

When I use the /goal feature, I try to write it like this.

/goal Make [target] into [done state]. Hold to [what to do or avoid], and when it's finished, verify it with [how to check].
  1. Target - what to handle
  2. Done state - what state counts as finished
  3. Constraints - what to hold to (what must be done, or must not be)
  4. How to check - what proves it's finished (test results, command output, a checklist, and so on)

The last one drops out most often. And it's the heart of /goal.

"Make it good" is a vague instruction. "Make it into a publishable draft, and write down the items still left to check" is a completion condition.

The Claude Code docs, too, boil a good condition down to three things. One measurable end state (a test result, a build exit code, an empty queue), what proves it (npm test exits 0, git status is clean), and the constraints to hold to. It comes to the same thing - the more you can anchor the end to a number or command output, the better.

The frame is the same for other work

Handing off code.

/goal Fix the login error. Check the related files, fix it with the smallest change, then run the existing tests and leave the pass/fail in a log. Briefly summarize the cause and the fix at the end.

Folding in a review.

/goal Check the review comments on this PR and address them. For comments you find hard to agree with, don't fix them outright - write down why. After the edits, tell me a summary of the changes and the tests you checked.

What still remains, even when you hand it off fully

/goal isn't a cure-all.

Claude Code's evaluator has a clear limit. That model doesn't run tools or read files itself. It judges only from what's already surfaced in the conversation.

What that means is - if Claude doesn't actually run the tests and leave the results in the conversation, the evaluator (the other model) can mark it passed on nothing but the words "it passed." Having a completion criterion doesn't guarantee verification.

So the way to check has to be tied to tool output, not the model's self-assessment. It's better to write "run the tests and leave the output" than "check whether you tested." You put the basis for the end outside the model. In the earlier code example, "leave the pass/fail in a log" is exactly that safeguard.

The basis for completion has to rest on execution results, not a plausible-sounding explanation. /goal doesn't do that for you. It just makes it easier to write it that way.

One-off questions vs work to hand off

Not every request needs to be set with /goal.

Work that's done once you get an answer back - brainstorming ideas, polishing a sentence, explaining a concept, comparing options - is better as a plain prompt.

/goal is a command for big jobs. More precisely, it's a command for the kind of work I'll want to go back and check on midway.

Before I hand it off, I look at one thing.

Is this something I'll end up checking again midway?

If I'm likely to ask whether the tests passed. If I'm likely to ask again about the items left over. Then it's better to put it into the goal from the start.

One-off questions as prompts. Work to hand off fully, with /goal.

Work you have to keep watching the state of is a different thing again. Claude Code's /loop or Codex's Automations are a different matter - I cover those in a separate piece.

Setup - turning it on, and versions

For both tools, /goal may not show up right away. One option is to ask directly, in that AI tool's prompt window, whether the feature is on and how to use it.

Sources