Loop prompt libraries
`/goal` and `/loop` prompts (Claude Code)
Two related primitives, and the difference is the whole lesson:
Source recipe
Copyable Markdown
# `/goal` and `/loop` prompts (Claude Code)
Two related primitives, and the difference is the whole lesson:
- **`/loop`** re-runs a prompt on a **cadence** (close to cron).
- **`/goal`** runs until a **verifiable condition** is true, with a *separate*
model checking each turn whether you're done.
These are Claude Code's commands and syntax. Codex has a `/goal` command too, but
it's a standing target rather than a per-turn verifier, and it has no `/loop` —
its cadence comes from the Automations tab.
→ Background: [docs/05 — Stop Conditions & Verification](../docs/05-stop-conditions-and-verification.md).
> Every prompt here is written to copy and paste. Primary sources are linked
> inline where a specific claim or primitive depends on one.
---
## `/goal` — run until a condition is true
### The textbook stop condition
```bash
/goal All tests in test/auth pass and lint is clean
```
*Source: the `/goal` primitive and this exact example are documented in Addy
Osmani, "[Loop Engineering](https://addyosmani.com/blog/loop-engineering/)"
(June 7, 2026), where he notes both Claude Code and Codex ship `/goal`.* —
`/goal` keeps working turn after turn until a verifier confirms the condition.
The condition must be **verifiable** — an exit code, a test result — not a vibe.
### A scope-bounded `/goal`
```bash
/goal All tests in test/auth/ pass, lint is clean, and the diff touches only
files under src/auth/ and test/auth/.
```
*Pattern: bake the **scope limit into the goal itself**, so "done" also means
"didn't sprawl."*
---
## `/loop` — run on a cadence
### Stage 1: report-only (start every new loop here)
```bash
/loop 1d Run $loop-triage. Read STATE.md. Merge findings into High Priority and
Watch List. Update Last run. Do not edit code.
```
*Why this shape: run a new unattended loop in **pure report-only mode** for a
week before you grant it write access. Earn trust before granting autonomy.*
### Stage 2: small auto-fixes, with isolation + a verifier
```bash
/loop 1d Run $loop-triage. For high-priority items that are single-file bugfixes:
spawn an implementer in a worktree, then a verifier agent. Update STATE.md.
Escalate ambiguous items.
```
*Why this shape: graduating autonomy (L1 → L2) means worktree isolation plus a
separate verifier sub-agent before any auto-fix.*
### A full daily-triage `/loop` (skill + worktree + reviewer + connectors)
```bash
/loop 1d Run the loop-triage skill on the current project. Append high-priority
items to STATE.md. For any small, self-contained bugfix or CI failure, open an
isolated worktree, draft a minimal fix using the minimal-fix skill, and have a
reviewer sub-agent verify it against project skills and tests. Update the PR or
ticket via connectors if possible. Anything ambiguous or high-risk should be
clearly flagged for human review in STATE.md.
```
*Why this shape: one `/loop` line wiring together every building block: skill →
worktree → minimal-fix → reviewer → connectors → escalation.*
### A complete session-scoped `/loop` contract
```
/loop every 15m
Objective: keep `npm test` green on the current branch.
Each iteration:
1. Run `npm test`. Treat its exit code as the only signal of done.
2. If it passes, stop and say the loop is complete.
3. If it fails, read the last 80 lines of output and fix only the cause of that failure.
4. Append one line to LOOP_PROGRESS.md describing what you changed and why.
5. Read LOOP_PROGRESS.md at the start of each iteration so you do not repeat a failed fix.
Permission boundary:
- Edit only application and test files under src/ and tests/.
- Do not change CI config, add dependencies, or touch files outside this repo.
- Do not weaken or delete tests to make them pass.
Stop conditions:
- Stop when `npm test` passes.
- Stop after 5 iterations.
- Stop if the same failure repeats twice with no new evidence.
```
*Why this shape: this is the gold standard for a session-scoped loop. A
deterministic exit code as the only "done" signal, an explicit permission
boundary, an iteration budget, an anti-cheat clause, and a stall stop. Copy it.*
### High-frequency cadence loops bound to skills
```bash
/loop 5m /pr-babysit check
/loop 30m /slack-feedback
```
*The everyday shape: short-cadence loops bound to slash-command skills.* ⚠️ Treat
the precise `/loop 5m …` wording as illustrative, not a verbatim quote. Boris
Cherny's verified line is that he writes loops, not these exact cadence strings.
---
### Design notes
- **Exit code beats prose.** Wherever a deterministic check exists (`npm test`,
`tsc`, a linter), make *its result* the done-signal — not the agent's opinion.
- **Permission boundary + stop conditions are not optional.** Every unattended
`/loop` above names what it may touch and exactly when it stops.
- **Start report-only.** The single best operational habit: a new loop watches
and reports for a week before it's allowed to write.