We were filing a batch of articles into our notes on 17 August. One of
them was about /goal, and it opened with the word
"Command:". It went in as a slash command rather than into the chat
box.
So the article became the goal. Several hundred words describing how the command works, locked in as the thing the session had to achieve, with a Stop hook standing behind it refusing to let the session finish.
What the command is for
A normal prompt finishes when the model responds. A goal finishes when the goal is met — the session plans, runs, checks its own work, calls whatever tools it needs, and only exits when the condition you wrote is satisfied. That is the entire appeal. You can step away.
Which means the condition is carrying the whole thing. The walkthrough we were filing says exactly that, and it is the sentence to keep:
"State success in concrete terms. Works on mobile and formats correctly is fine. Fix it is not."
What we handed it instead
An explanation. The text we pasted contains no project path, no evidence of a working state or a broken one, no route to verify anything, and no sentence that any amount of work could satisfy. It describes a mechanism. It never says what done looks like.
That is fix it in a longer coat, and a longer coat is worse, because it reads like a specification. A short vague goal looks vague. A thousand-word vague goal looks thorough.
The hook did its job perfectly. Every time the session tried to stop, it was asked whether the goal had been met, and there was no answer that could be yes. Nobody planned that demonstration.
The test we use now
A success condition has to be something a command can answer.
An HTTP status. A file that exists. A test suite that exits zero. A
fresh screenshot compared against a known-good one. Looks right
is not a condition. curl returning 200 is.
If you cannot name the command that would settle it, you have written
a description, and a loop pointed at a description does not stop. Ours
has form on this: an agent on this machine once spent six hours typing
echo hello into a shell that had already died, thirty
times, and wrote nothing. It never looked idle for a second.
The recovery is also worth saying, because the instinct is wrong. When a loop cannot close, working the loop harder does nothing — nothing satisfies the condition, so every pass costs money and gets no nearer. Clear the goal and set a real one.
What it is genuinely good at
Three jobs on our own list qualified once we applied the test, and they share a shape: each one currently eats an afternoon of back-and-forth with a person sitting in the middle.
Sweeping the site for drift, where the condition is that every page renders and matches its reference screenshot. Reconciling the deploy path, where the condition is that both forms still answer correctly after a deploy. Auditing our configuration file, where the condition is that no rule appears twice and no passage contradicts a later one.
All three can be checked by a command. That is the only thing they have in common, and it is the only thing that matters.
The limit that is ours, not the tool's
"Trust the loop, do not jump in halfway" is good advice and it sits against our own standing rule that somebody checks work before it reaches a person. Those two are compatible in exactly one case: when the checker is real. A loop whose condition a machine can verify is safe to leave alone. A loop whose condition is a judgement call still needs a person, and no amount of automation moves that.
What to do
Before you start any unattended run, write the success condition as a command you could type. If you cannot, you are not ready to walk away — and the thing you are about to leave running has no reason to ever stop.