Agent /goal Loop

What /goal is

/goal makes an agent persist through plan → act → test → review → iterate. If a turn ends before the goal is met, it auto-continues instead of waiting for input. The loop ends at its stop condition, a user pause, or the token budget limit. It is also called the “Ralph loop”.

Before giving runtime instructions, check goal support in the installed agent and interface through its help, exposed tools, or current official documentation. Verify feature flags, authentication, and limits; do not transfer one agent's requirements to another. Lifecycle states, budgets, and pause/resume vary by runtime.

A goal enforces a contract through verification. It is not a budget command, a safety boundary, “run forever”, or a replacement for /plan.

When to use it

Use for repeated autonomous work with a verifiable stop condition: passing tests, target coverage, eval ≥ X, or a green build. For code work, establish a working build and relevant checks first. No minimum task duration applies.

Fits: migrations, coverage lifts, TDD feature builds, refactors with contract tests, prompt/eval optimization, deploy retry loops, bug-repro-then-fix.

Bad fits: exploratory work, vague "improve this", anything without a "done" definition, prod credentials, destructive shared-infra ops.

The 4-part contract (every goal needs this)

1. Objective, one sentence, one concrete outcome.
2. Constraints, what must NOT change (public API, files, libs, conventions).
3. Validation command, the exact shell command that proves progress (pytest -q, pnpm test, etc.).
4. Stop condition, verifiable: "Stop when X passes" OR "when further changes need human/product input."

Also specify what to read first, checkpoints, and a short progress log.

Writing a goal (the core deliverable)