| name | slm-loop |
| description | Run gate-verified bounded loops with SuperLocalMemory as the durable ledger. Use when a task has a checkable acceptance condition (tests, schema, lint, reconciliation) and you must iterate until an INDEPENDENT gate passes — never stopping just because the agent believes it is done. `slm loop demo` runs a keyless convergence demo; `slm loop history` and `slm loop show <run_id>` inspect past runs whose every lap is persisted as queryable SLM memory (tag `loop:<name>`). Terminal statuses are DONE / HALT / PAUSE / KILLED / ERROR — report them exactly, never converting HALT/PAUSE/ERROR into success. |
| when_to_use | run a bounded loop, gate-verified task, iterate until tests pass, verify against an independent gate, don't trust the agent's own done claim, slm loop, convergence loop, loop until green, loop ledger, resume a loop |
| allowed-tools | Bash, recall |
slm-loop — Bounded, gate-verified agent loops
The one rule
A bounded loop is complete only when an independent gate passes — not when
the agent claims it is finished. The agent's own "I'm done" signal is recorded
for audit and is never used to terminate the loop. If you take one thing from
this skill: the gate is the authority.
Use a bounded loop whenever the goal has a mechanical, checkable contract: a
test suite, a JSON schema, a linter, a reconciliation rule, a citation checker,
a security scan. When the goal is subjective, keep a human approval gate (see
rungs below).
What SLM adds
Every lap is written to SuperLocalMemory as a durable, queryable memory (tagged
loop:<name>, session loop:<run_id>). That makes a run:
- auditable — inspect the decision + gate verdict + budget for each lap;
- resumable / historical — a run's ledger survives across sessions;
- discoverable — visible via
slm recall, the dashboard, and any
SLM-integrated tool, alongside everything else the agent remembers.
CLI
slm loop demo [--iterations N] [--json]
slm loop history [--name NAME] [--json]
slm loop show <run_id> [--json]
slm loop demo proposes a fix, checks it against a deterministic gate that
passes on lap 3, and records the run — a zero-setup way to see the control flow
and confirm the SLM-backed ledger works end to end.
The bounds
A loop runs inside a safety envelope. Any bound tripping ends the run with
HALT (never a success):
- max_iterations — a hard lap cap.
- no_progress_window — consecutive no-change laps before halting a spinning
agent.
- token budget / wall-clock — cumulative ceilings.
- kill switch — set
SLM_LOOP_KILL to stop before the next lap.
- approval rung — L1 (report), L2 (assisted, pauses for approval), L3
(unattended). L2/L3 require approval before a passing gate is accepted as
DONE unless approval is explicitly configured off.
Terminal statuses — report exactly
| Status | Meaning |
|---|
DONE | The independent gate passed and approval was granted or not required. |
HALT | A bound tripped (iterations, no-progress, token, or wall-clock). |
PAUSE | The gate passed but required approval is not yet granted. |
KILLED | The external kill switch tripped between laps. |
ERROR | The runner or gate failed to execute; inspect the lap detail. |
Say DONE only when the status is exactly DONE. Never describe HALT,
PAUSE, or ERROR as success. When halted, name which bound tripped; when
paused, name the approval needed; when errored, quote the short detail.
Reporting workflow
- Run or resume the loop.
- Read back the ledger with
slm loop show <run_id> (or slm recall on tag
loop:<name>).
- Report the exact terminal status, the lap count, and the gate's final
verdict. Include the
run_id so the run can be re-inspected later.
Gate discipline
- The gate verifies; the runner only proposes. They are separate.
- Prefer a typed, parseable gate (a test exit code, a schema validation, a
scanner report) over a vague check. A missing tool, an empty report, or a
crashed scanner is not a clean pass — fail closed.
- Never use "an LLM decides it looks good" as the gate. That reintroduces the
exact failure mode bounded loops exist to remove.
Related skills
slm-status — confirm SLM is healthy before relying on the ledger.slm-recall — query a loop's laps directly (loop:<name> tag).slm-session — session lifecycle around a longer loop run.
SuperLocalMemory v4.1.11 · Qualixar · AGPL-3.0-or-later
