sl-debuggerlisted
Install: claude install-skill willprout/superlooper
# sl-debugger — diagnose and repair a live loop instance
The patient is a running superlooper instance: a deterministic **runner** (one foreground
process in a cmux tab, tick loop ~15s) driving GitHub-issue work through worker sessions,
its **state home** at `~/.superlooper/<owner>__<name>/` (journal, per-issue state, liveness
markers, heartbeat), and optionally the **command-center dashboard** on `127.0.0.1`. Where
truth lives: the state home; the engine source (`skills/superlooper/skill/` in the
superlooper repo) — the installed copy at `~/.claude/skills/superlooper/` is what actually
runs (they drift; the `VERSION` file arbitrates); the incident corpus in
`skills/superlooper/docs/`; and the superlooper skill's runner-ops reference — the plugin
sibling `../superlooper/references/runner-ops.md` (this skill and the ops skill ship as
siblings in the installed plugin, so the relative path resolves inside the plugin cache;
runner-ops moved out of the engine's installed `references/` into the plugin) — for how the
loop is *meant* to be operated.
**Diagnosis before repair, always.** The readout is read-only; run it fully before mutating
anything. Most documented incidents needed rung 1–2 repairs or none at all.
## Router — open the one reference the moment needs
| Situation | Read | For |
|---|---|---|
| any symptom, or "how is the loop doing?" — **always start here** | `references/health-readout.md` | the read-only forensics pass: process-vs-progress, heartbeat/ALERT, journal