loop-designer

Loop Designer

Turn a one-off task into a guarded autonomous loop: five explicit parts, five non-negotiable guardrails, two ready-to-paste artifacts. The architecture is generalized from a production daily-radar loop that has run live — see references/loop-anatomy.md for the anatomy and its provenance, references/guardrail-design.md for why each guardrail exists.

Step 0 — Verification first

Before designing anything, ask: what does a successful run look like, checkably? If the user's task has no verifiable success condition ("keep an eye on things", "make it better over time"), stop and help define one — a file that exists with required fields, a count within bounds, a claim with a source link. No verifiable condition, no loop: an unverifiable loop is an unattended failure generator.

Step 1 — Minimal interview

Ask only what the request didn't already say (one message, not a questionnaire):

1. Goal — the checkable success condition from Step 0.
2. Sources/inputs — what each run scans or consumes (URLs, repos, folders, APIs).
3. Output destination — where results land (file path pattern, branch, email, issue).
4. Schedule — cron-style cadence, or event-driven.

Step 2 — Generate the loop spec (five parts, all explicit)

LOOP SPEC: <name>
DISCOVER  — what each run scans, with recency/scope cutoffs stated
PLAN      — how findings are filtered and decomposed: dedup against the seen-log
            FIRST, then select/rank what survives (selection criteria explicit)
EXECUTE   — the action, with exact output format and destination
VERIFY    — a separate verifier checklist (3-6 binary checks) run AFTER execute;
            the run only counts as successful if every check passes
STOP-OR-REPEAT — exit conditions: work exhausted, nothing new found (say so
            honestly — an empty run writes "nothing new", never padding),
            iteration cap hit, or ceiling hit

Rules for VERIFY:

• The verifier is a distinct step with its own checklist — never the executor grading its own output in the same breath. In a Routine, VERIFY is a separately-delimited checklist pass over the produced artifact; in a multi-agent setup, a separate agent.
• Checks must be binary and artifact-inspectable (file exists, fields present, every claim has a source link, item count within bounds, no seen-log duplicates in output).
• A failed check = failed run, reported as such — never silently shipped.