loop-designerlisted

Use this skill when the user says turn this into a loop, run this on a schedule, automate this daily, build me a loop, make this recurring, design a loop for a task, or loop this task — any request to make a one-off task a recurring autonomous job. Interviews minimally (goal, sources/inputs, output destination, schedule), then generates a five-part loop spec (Discover, Plan, Execute, Verify with a separate verifier checklist, Stop-or-Repeat), a non-negotiable guardrails block (max-iterations cap, cost ceiling, seen-log cross-run dedup, no-destructive-actions allowlist, completion/trip notification), and two ready-to-paste runners — a Claude Code Routine prompt and a local cron/launchd variant. Do NOT use for improving an existing prompt ("improve this prompt" is prompt-optimizer-loop's job), for one-off tasks, for debugging an already-built loop, or to run something on an interval in the current session — the built-in /loop command does that; this skill designs durable guarded loops, it doesn't run them.
Abhillashjadhav/AI-PM-essential-skills · ★ 2 · AI & Automation · score 58

Install: claude install-skill Abhillashjadhav/AI-PM-essential-skills

# 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 (se