Field guide · Mercy Thaddeus × Attention Factory
/Goal
The command that makes Claude keep working until the job is actually done.
It isn't a hidden feature or a button. It's a prompt pattern: you hand Claude a success condition instead of a task, tell it to check its own work after every step, and to keep going until that condition is true.
01 What it actually is
You give it a finish line, not a chore.
A normal prompt says “do this thing.” Claude does it once and stops. A /Goal prompt says “this is what done looks like — keep going until it's true.”
That one swap changes the shape of the whole interaction. A task produces a single reply. A condition produces a loop: act, check the result against the condition, and either finish or take the next step. Same model, completely different behaviour. You stop being the thing that pushes it forward between steps.
Everything below is how to write that condition so the loop runs clean instead of wandering.
02 Why it works
A loop needs three things. You supply all three.
Claude's default is one turn: answer, stop. It won't loop on its own — nothing tells it to. /Goal hands it the three parts a loop can't run without:
- a
A stop condition
"Done" has to mean something checkable, or the loop never knows when to end.
- b
A self-check
After each step it compares what it produced against that condition — instead of assuming it's finished.
- c
A "keep going" instruction
The explicit permission to continue without stopping to ask you between steps. This is the line most people forget, and it's the one that unlocks the long runs.
03 Where it runs — and where “8 hours” is real
Same pattern, two very different engines.
Read this part before you promise yourself an unattended overnight run. Where you paste the prompt decides what “keep running” actually means.
In Claude chat
You get one long, thorough, multi-step pass — it plans, works through the steps, and self-corrects inside a single reply. Powerful, but bounded by that one turn. It can't run your tests or open your terminal, so here "keep going for hours" is figurative. Great for reasoning, drafting, and planning work.
●In Claude Code
Now there's a real execution loop. Claude runs commands, reads the actual output, fixes, re-runs, and re-checks — unattended, for as long as the condition stays unmet. This is where a /Goal genuinely runs for hours, and where the multi-hour runs come from. Want the version that literally keeps working? Run it here.
04 Anatomy
Six parts. Each one prevents a specific failure.
- 01
Goal the end state
Written so it can be verified. Not "improve the code" — "the build passes and every test is green." If you can't check it, the loop can't either.
- 02
Definition of Done the checklist
The concrete criteria that make "done" objective. This is what the self-check runs against every pass. Vague here = it never finishes, or finishes wrong.
- 03
The Loop act → check → repeat
Spell out the cycle: take the next action, check the result, finish or continue. Making it explicit is what stops it after one pass.
- 04
Self-check evaluate every pass
"After each step, compare against Definition of Done." Without this it declares victory early — the single most common way the pattern disappoints.
- 05
Guardrails the brakes
Max iterations, no destructive actions, scope limits. This is what stands between "ran until done" and "ran until it broke something."
- 06
Progress log the window
Have it report each pass — what it did, what changed, what's left. So you can watch a long run and interrupt the moment it drifts.
05 The template
Copy this. Fill the brackets. Paste.
The generic version — works for anything with a checkable finish line. The last line is the one that turns it from a to-do into a loop, so don't cut it.
/Goal GOAL: [the end state you want, phrased so it can be verified — not "improve the code" but "the build passes, all tests green"] DEFINITION OF DONE — all of these must be true: - [checkable criterion 1] - [checkable criterion 2] - [checkable criterion 3] LOOP: 1. Take the next action toward the goal. 2. Check the result against Definition of Done. 3. If every item is true, stop and report DONE with a summary. 4. If not, name what's still missing and take the next action. 5. Repeat from step 1. GUARDRAILS: - Stop after [N] iterations. If it's not done, tell me exactly what's blocking it. - Never [delete / deploy / send / pay / overwrite] without asking me first. - Stay inside [scope]. Don't touch [out of scope]. - After each pass, log: what you did, what changed, what's left. Start now. Don't check in for permission between steps — keep going until Definition of Done is met or a guardrail stops you.
06 Two ready-made versions
Coding, and bulk content.
Pre-filled so you can see what “checkable” looks like in practice. The coding one is built for Claude Code on a Next.js / Supabase stack — swap the checks for your own.
/Goal GOAL: The signup → login → dashboard flow works end to end for a brand-new user, with the session persisted on refresh. DEFINITION OF DONE — all must pass: - `npm run build` completes with zero errors - `npm run test` passes (every auth test green) - `tsc --noEmit` reports no type errors - The smoke script `scripts/smoke-auth.ts` exits 0 LOOP: 1. Run the four checks above. 2. For each failure, read the actual error, fix the root cause, re-run that check. 3. Repeat until all four pass in one clean run. GUARDRAILS: - Show me any Supabase migration before applying it — don't touch the schema silently. - Don't modify billing or the Polar integration. - Cap at 20 iterations, then stop and report what's left. - Log each pass: command run → result → fix applied. Begin. Keep running until every check passes.
/Goal GOAL: Every raw transcript in /transcripts becomes a finished caption in /captions — one caption file per transcript. DEFINITION OF DONE: - Every .txt in /transcripts has a matching .md in /captions - Each caption follows hook → tension → CTA - No file is empty, truncated, or a placeholder LOOP: 1. List the transcripts that don't have a caption yet. 2. Write the caption for the next one. 3. Re-check the list. 4. Repeat until the list is empty. GUARDRAILS: - Never overwrite an existing caption — flag it and skip. - Log progress every 5 files. - When the list is empty, stop and give me a summary table (file, status).
07 When to reach for it
It's a loop, so it needs a finish line.
use it
- The success condition is verifiable — tests pass, build succeeds, all rows migrated, every file processed.
- Iterate-until-it-works jobs: debugging, fixing a failing build, getting a flaky flow green.
- Bulk repetitive work where each item has the same "done."
- Anything where "keep going until it's right" beats a single best-effort pass.
skip it
- Open-ended creative work with no objective "done" — it'll loop pointlessly or over-build.
- Actions that are costly if wrong — deploys, sends, deletes, payments — unless you add hard checkpoints.
- Goals you can't verify. If you can't check it, neither can the loop.
- Tiny one-shot tasks. The scaffolding costs more than it saves.
08 The four ways it breaks
And the one line that fixes each.
It loops forever
Fix: cap iterations. "Stop after 15 passes and tell me what's blocking it."
It over-builds
Fix: tighten Definition of Done and add "don't add anything not required to meet it."
It wrecks something
Fix: guardrail. "Never delete, deploy, send, or pay without asking me first."
It drifts off goal
Fix: progress log + restate the goal each pass so it keeps re-anchoring.
09 The 10-second version
No template handy? Paste this.
minimum viable /Goal
Keep going until [goal] is true. After each step, check yourself against [these done-criteria]. Don't stop to ask me — only stop when it's done or you hit [this limit].