loop-builder

Automate a recurring task, schedule an agent, set up monitoring or triage, run an agent overnight, or turn a manual workflow into a self-running one — even if you never say the word "loop."

At a glance

What it does	Turns "automate / schedule / monitor / compare …" into a real, runnable loop folder
What you get	A skill, a separate verifier, a state file, human-gates, and a trigger stub
How you start	Just describe the task — it triggers without the word "loop"
What's built in	A separate checker, a human gate on irreversible actions, and a budget/stop
Install	/plugin install loop-builder@loop-builder (jump ↓)

---

Why this exists

A loop is not one long prompt. It is a small self-running system in which an agent finds work, acts, gets graded against explicit criteria by a separate checker, and repeats — until the criteria pass or a budget runs out, without a human typing each turn.

The reason loops need engineering at all is one blunt fact:

The agent starts cold every run. It forgets everything between runs. So conventions, commands, and "what's already done" must live outside the context window, on disk. The agent forgets; the repo does not.

Designing that system by hand each time is error-prone — people forget the verifier, leak mutable state into the wrong place, or ship a loop with no stop condition. loop-builder turns the design into a repeatable interview + scaffold so every loop you build has the parts that keep it safe and trustworthy.

---

How the skill works

When it triggers, it runs in phases — elicit → survey reuse → select → scaffold — and never skips ahead, because a loop with a missing part is the failure mode, not a shortcut.

  describe          elicit            survey            select           scaffold
  the task    →   7 decisions   →   reuse what's   →   simplest     →   6 blocks as
                  one at a time     installed          pattern          real files

flowchart TD
    U["You: 'automate / schedule / monitor / compare ...'"] --> T{loop-builder triggers}
    T --> P1["Phase 1 · ELICIT<br/>the 7 decisions, one at a time"]
    P1 --> A
    subgraph SV["Phase 1.5 · SURVEY REUSE"]
      direction TB
      A["1.5a · installed<br/>skills / MCPs / sub-agents already on the machine"] --> B
      B["1.5b · skill-bank search sub-agent<br/>reads recommended.md (curated standouts)<br/>+ catalog/*.md — 5 sources, searched on demand"]
    end
    B --> P2["Phase 2 · SELECT<br/>simplest fitting pattern<br/>(load only that reference)"]
    P2 --> P3["Phase 3 · EMIT<br/>the fill-in template, populated"]
    P3 --> SC["SCAFFOLD the 6 building blocks<br/>as real files"]
    SC --> OUT["A loop folder you can run"]

    P1 -. enforces .-> R1{{"Goal must be a checkable<br/>predicate, not a vibe"}}
    SV -. compose, don't rebuild .-> R4{{"Reuse needs a named fallback<br/>(skills are changing state)"}}
    SC -. always emits .-> R2{{"Human-gate list<br/>+ budget / stop condition"}}
    SC -. enforces .-> R3{{"Durable → skill<br/>Changing → state file"}}

The seven-question blueprint (Phase 1)

Every loop, whatever its purpose, comes down to seven decisions. Each maps to a building block: