loop-testlisted
Install: claude install-skill restarter/lets-workflow
# loop-test (local experiment)
`/loop` schedules **periodic re-invocations of the same prompt**. Two modes:
| Mode | Syntax | Mechanic |
|---|---|---|
| **Interval** | `/loop 5m /foo` · `/loop /standup 1h` · `/loop check the deploy every 20m` | Cron entry in `.claude/scheduled_tasks.json`. Default `10m` when only `[interval]` shorthand. Survives session restart (durable). |
| **Dynamic / self-paced** | `/loop check the deploy` (no interval anywhere) | Model calls `ScheduleWakeup(delaySeconds, prompt, reason)` at the end of each turn. Skip → loop ends silently. |
**`/loop` is the wrong tool for sequential workflow phases.** It repeats the *same prompt* each tick — to chain `plan → review → check`, the prompt itself has to be phase-aware (read state, advance, write back). For state-convergent autonomy, use `/goal` instead (see `goal-test` skill).
**Right tool for `/loop`:**
- Polling external state (CI runs, deploys, PR comments)
- Periodic checks (every 20m: any new bd-ready tasks?)
- Babysitting a long-running job (check progress, surface failures)
- Continuous monitoring during a long focused session
## How `/loop` actually works
Reverse-engineered from `claude` binary v2.1.150.
### Dynamic-mode contract
This is the mode you care about most — interval is just cron.
1. User runs `/loop <prompt>` (no interval).
2. Model does the work.
3. Before yielding, model calls `ScheduleWakeup(delaySeconds, prompt, reason)`:
- `delaySeconds` clamped to `[60, 3600]`
- `promp