Loop Designer
A chore in, a loop out — designed verification-first: what a correct run produces is written before the executor prompt exists, and the executor never grades its own homework.
Verification gates (defined first; output is blocked until all pass)
- G1 — Step 0 present, first: before any anatomy is written, Step 0 defines the checkable conditions of a correct run (counts reconcile, citations real, required elements present). The verifier checks these conditions — a loop whose success criteria were written after (or by) the executor fails.
- G2 — Executor ≠ verifier: the Verify stage is structurally separate from Execute — an independent pass or mechanical check suite with its own instructions, receiving the artifact and raw source references, not the executor's reasoning. "The agent double-checks its own work" fails the gate.
- G3 — Five parts, five guardrails: Discover / Plan / Execute / Verify / Stop all present and named; all five guardrails present, each with named failure + trigger: scope ceiling · output gate (verify fails → no output ships) · kill switch (N consecutive failures → loop disables + alerts) · cost/step budget · no-silent-drift (source anomaly → halt, don't improvise).
Steps
- Define done, first. From the chore, write the correct-run conditions as checkable statements ("every theme cites ≥2 ticket IDs", "counts reconcile to the ticket total", "zero invented quotes"). These become the verifier's checklist verbatim.
- Discover: the source, the window, the query — stated exactly (last 7 days of tickets from X). Anomaly bounds here feed the no-silent-drift guardrail (volume ±3x usual → halt).
- Plan + Execute: the transformation, method named (cluster by underlying complaint; draft the post). The executor prompt contains the task and the guardrail ceilings — it does not contain the authority to ship.
- Verify — independently. A second pass (separate agent, or mechanical checks) runs the Step 0 checklist against the artifact plus raw source IDs. State the separation mechanism: what the verifier receives, what it can't see (the executor's self-assessment), and its verdict format (pass → Stop may ship; fail → failure report, nothing posts).
- Stop: on pass — deliver + one-line run report; on fail — report instead of output; kill switch after 2 consecutive fails (loop disables itself and alerts); every run logs what it read, produced, and verified.
- Emit the runner: a paste-ready scheduled prompt (Claude Routine or cron +
claude -p) whose body carries the full anatomy and guardrails, plus the schedule taken from the chore. One runner recommended, not two half-configured ones.
- Gate pass: Step 0 precedes and feeds Verify (G1), separation stated (G2), 5 parts + 5 guardrails each named+triggered (G3). Fix and re-run; maximum 2 repair loops, then report the failure.
Output format
LOOP: weekly support-themes digest (Mondays)
STEP 0 — CORRECT-RUN CONDITIONS (written first; the verifier's checklist)
C1 every theme cites ≥2 ticket IDs · C2 theme counts reconcile to ticket total ·
C3 zero quotes absent from source tickets · C4 post ≤300 words
ANATOMY
Discover: tickets from <source>, trailing 7 days; expected volume 60-120 (drift bound)
Plan/Execute: cluster by underlying complaint → draft #product post [executor prompt: task + ceilings, no ship authority]
Verify [independent]: verifier pass receives draft + raw ticket IDs only; runs C1-C4; verdict pass/fail with evidence
Stop: pass → post + run report · fail → failure report, no post
GUARDRAILS (failure → trigger)
1 scope ceiling: >200 tickets → halt, human · 2 output gate: any C fails → no post ·
3 kill switch: 2 consecutive fails → disable + alert · 4 budget: ≤X steps/tokens per
run [ceiling instructs the model; runner cap enforces] · 5 drift: volume outside
60-120 or schema change → halt, don't improvise
RUNNER (paste-ready): [scheduled prompt embedding all of the above · Mondays 08:00]
LIMITS: novel complaint types are flagged, not force-classified; human reads before
acting on weeks 1-4.
GATE CHECK: G1 pass (Step 0 first) · G2 pass (verifier separate) · G3 pass (5+5)
Hard rules
- Step 0 comes first and the verifier checks exactly it. Success criteria written by or after the executor are self-grading with extra steps.
- The executor never ships its own output. The output gate sits between Execute and the world, held by the verifier.
- All five guardrails, always — a loop that "doesn't need" a kill switch is a loop that hasn't failed yet. Cost ceilings are honest about enforcement: the prompt instructs, the runner's caps enforce.
- Never design a loop for a chore whose correct output can't be checked (no Step 0 conditions exist) — say so; that chore needs a human or a redesign, not automation.
Limitations
- The design assumes the runner platform provides scheduling and hard caps; prompt-level budgets instruct the model but don't meter the account.
- Verifier independence is structural (separate pass, separate inputs), not adversarial — a shared systematic blind spot can pass both; golden cases from real runs (failure-to-eval-capture) close that over time.
- Week-1-4 human readership is part of the design, not a disclaimer — trust is earned by verified runs, and the loop spec says when to revisit it.
- Loops compose poorly: one chore, one loop; chains of loops need their own design pass, flagged when detected.
1---2name: loop-designer3description: Iterate-stage skill: turns a recurring chore into a guarded autonomous loop — five-part anatomy (Discover/Plan/Execute/Verify/Stop), five non-negotiable guardrails, and a verifier that is never the executor. Use when a repeated manual task should run on a schedule — 'turn this weekly chore into an autonomous loop', 'design a guarded loop for the digest', 'automate this triage safely' — or when /pm routes such a request here. Do NOT use for one-shot workflow hardening (guardrail-designer), for plain cron scheduling of a script, for executing the loop, or for definitions of autonomous loops.4---56# Loop Designer78A chore in, a loop out — designed verification-first: what a correct run produces is written before the executor prompt exists, and the executor never grades its own homework.910## Verification gates (defined first; output is blocked until all pass)1112- **G1 — Step 0 present, first:** before any anatomy is written, Step 0 defines the checkable conditions of a correct run (counts reconcile, citations real, required elements present). The verifier checks these conditions — a loop whose success criteria were written after (or by) the executor fails.13- **G2 — Executor ≠ verifier:** the Verify stage is structurally separate from Execute — an independent pass or mechanical check suite with its own instructions, receiving the artifact and raw source references, not the executor's reasoning. "The agent double-checks its own work" fails the gate.14- **G3 — Five parts, five guardrails:** Discover / Plan / Execute / Verify / Stop all present and named; all five guardrails present, each with named failure + trigger: scope ceiling · output gate (verify fails → no output ships) · kill switch (N consecutive failures → loop disables + alerts) · cost/step budget · no-silent-drift (source anomaly → halt, don't improvise).1516## Steps17180. **Define done, first.** From the chore, write the correct-run conditions as checkable statements ("every theme cites ≥2 ticket IDs", "counts reconcile to the ticket total", "zero invented quotes"). These become the verifier's checklist verbatim.191. **Discover:** the source, the window, the query — stated exactly (last 7 days of tickets from X). Anomaly bounds here feed the no-silent-drift guardrail (volume ±3x usual → halt).202. **Plan + Execute:** the transformation, method named (cluster by underlying complaint; draft the post). The executor prompt contains the task and the guardrail ceilings — it does not contain the authority to ship.213. **Verify — independently.** A second pass (separate agent, or mechanical checks) runs the Step 0 checklist against the artifact plus raw source IDs. State the separation mechanism: what the verifier receives, what it can't see (the executor's self-assessment), and its verdict format (pass → Stop may ship; fail → failure report, nothing posts).224. **Stop:** on pass — deliver + one-line run report; on fail — report instead of output; kill switch after 2 consecutive fails (loop disables itself and alerts); every run logs what it read, produced, and verified.235. **Emit the runner:** a paste-ready scheduled prompt (Claude Routine or cron + `claude -p`) whose body carries the full anatomy and guardrails, plus the schedule taken from the chore. One runner recommended, not two half-configured ones.246. **Gate pass:** Step 0 precedes and feeds Verify (G1), separation stated (G2), 5 parts + 5 guardrails each named+triggered (G3). Fix and re-run; maximum 2 repair loops, then report the failure.2526## Output format2728```29LOOP: weekly support-themes digest (Mondays)30STEP 0 — CORRECT-RUN CONDITIONS (written first; the verifier's checklist)31 C1 every theme cites ≥2 ticket IDs · C2 theme counts reconcile to ticket total ·32 C3 zero quotes absent from source tickets · C4 post ≤300 words33ANATOMY34 Discover: tickets from <source>, trailing 7 days; expected volume 60-120 (drift bound)35 Plan/Execute: cluster by underlying complaint → draft #product post [executor prompt: task + ceilings, no ship authority]36 Verify [independent]: verifier pass receives draft + raw ticket IDs only; runs C1-C4; verdict pass/fail with evidence37 Stop: pass → post + run report · fail → failure report, no post38GUARDRAILS (failure → trigger)39 1 scope ceiling: >200 tickets → halt, human · 2 output gate: any C fails → no post ·40 3 kill switch: 2 consecutive fails → disable + alert · 4 budget: ≤X steps/tokens per41 run [ceiling instructs the model; runner cap enforces] · 5 drift: volume outside42 60-120 or schema change → halt, don't improvise43RUNNER (paste-ready): [scheduled prompt embedding all of the above · Mondays 08:00]44LIMITS: novel complaint types are flagged, not force-classified; human reads before45acting on weeks 1-4.46GATE CHECK: G1 pass (Step 0 first) · G2 pass (verifier separate) · G3 pass (5+5)47```4849## Hard rules50511. Step 0 comes first and the verifier checks exactly it. Success criteria written by or after the executor are self-grading with extra steps.522. The executor never ships its own output. The output gate sits between Execute and the world, held by the verifier.533. All five guardrails, always — a loop that "doesn't need" a kill switch is a loop that hasn't failed yet. Cost ceilings are honest about enforcement: the prompt instructs, the runner's caps enforce.544. Never design a loop for a chore whose correct output can't be checked (no Step 0 conditions exist) — say so; that chore needs a human or a redesign, not automation.5556## Limitations5758- The design assumes the runner platform provides scheduling and hard caps; prompt-level budgets instruct the model but don't meter the account.59- Verifier independence is structural (separate pass, separate inputs), not adversarial — a shared systematic blind spot can pass both; golden cases from real runs (failure-to-eval-capture) close that over time.60- Week-1-4 human readership is part of the design, not a disclaimer — trust is earned by verified runs, and the loop spec says when to revisit it.61- Loops compose poorly: one chore, one loop; chains of loops need their own design pass, flagged when detected.
Abhillashjadhav