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 cannot establish whether a run succeeded.

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.

Before activation, confirm the timezone and numeric budgets with the owner. If proposing defaults in a design, label them unapproved and keep them out of executable configuration until accepted. Never imply a placeholder host tool is installed or that a subscription has an API spending allowance.

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