| name | goal |
| description | Autonomous Opus loop that pursues a SPEC across multiple turns until every completion condition is satisfied or a real blocker surfaces. Use only when the work is non-decomposable and benefits from sustained reasoning. Always preceded by /spec. |
/goal — autonomous goal loop
Hand the SPEC to an Opus driver that works across many turns until every completion condition is met. Inspired by Claude Code 2.1.139's /goal semantics; sharpened by claudemax's spec-first gate and supervisor verification.
Pre-requisites
SPEC.md exists at the project root.- Every completion condition has a verifyHint a blind reviewer could check.
- The user understands this may run for many turns and incur significant Opus cost.
Loop behavior
- After every meaningful change, the driver re-evaluates the completion conditions.
- When all are met, it emits a
FINISHED block with per-condition evidence and exits.
- When it cannot proceed (missing credential, ambiguous requirement, irreversible decision), it emits
BLOCKED with what would unblock.
- It does not invent success. If verifyHints don't pass a blind check, the driver iterates.
Out of scope for /goal
- Anything not in the SPEC. Even if the driver notices a broken adjacent thing, it logs it and stays in scope.
- Cost downgrades.
/goal is always Opus. If you need cheap, decompose into /dispatch-able packets first.
Output
A status (finished | blocked | max-turns), an evidence map keyed by completion condition id, a summary paragraph, and a session id for resumption.
Always followed by /verify
Never declare success on the strength of /goal's own claim. /verify runs an independent Opus pass.
