Scaffold a well-designed agent loop with best-practice coaching and a cross-model review council. Use when the user wants to design, build, or set up an agent loop, iterative agent workflow, self-review loop, LLM-as-judge loop, multi-model council, reviewer/judge gate, or /goal-style looping process. Start from a named pattern template (security-scan, code-review, bug-hunt, docs-sync, research-synthesis) or from a blank interview. Guide goal refinement, typed verification criteria, reviewer and judge selection, privacy boundaries, termination guards, no-progress stops, and lightweight observability, then emit a RUN_IN_SESSION.md handoff prompt plus portable loop.yaml, loop.resolved.json, LOOP.md, and run-loop.py.
$npx -y skills add ksimback/looper --skill looperInstalls into the current project.
Run `npx skills use "https://github.com/ksimback/looper" --skill "ksimback/looper"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.
Use the skills in "https://github.com/ksimback/looper" that are relevant to the current task. Run `npx skills add "https://github.com/ksimback/looper"` and select the relevant skills, then follow their instructions.
| 1 | <div align="center"> |
| 2 | |
| 3 | <pre> |
| 4 | _ ___ ___ ____ _____ ____ |
| 5 | | | / _ \ / _ \| _ \| ____| _ \ |
| 6 | | | | | | | | | | |_) | _| | |_) | |
| 7 | | |___ | |_| | |_| | __/| |___| _ < |
| 8 | |_____| \___/ \___/|_| |_____|_| \_\ |
| 9 | </pre> |
| 10 | |
| 11 | <p> |
| 12 | <strong>Design agent loops before you run them.</strong><br> |
| 13 | Goal -> Plan -> Review -> Deliver -> Judge -> Stop clean. |
| 14 | </p> |
| 15 | |
| 16 | <p> |
| 17 | <a href="#quick-start">Quick start</a> | |
| 18 | <a href="#example-loop-diagram">Example loop</a> | |
| 19 | <a href="#how-it-works">How it works</a> |
| 20 | </p> |
| 21 | |
| 22 | </div> |
| 23 | |
| 24 | ## Example loop diagram |
| 25 | |
| 26 | Looper turns a fuzzy automation idea into a reviewable loop shape before any |
| 27 | runner starts changing files. This example comes from |
| 28 | [`examples/ai-workflow-mapping`](examples/ai-workflow-mapping/loop.yaml). |
| 29 | |
| 30 | ```mermaid |
| 31 | flowchart TD |
| 32 | G["Goal + context<br/>process notes + definition of done"] --> P["Draft plan.md<br/>host: codex / gpt-5"] |
| 33 | P --> PG{"Plan gate<br/>judge: reviewer-1"} |
| 34 | PG -- "revise <= 3" --> P |
| 35 | PG -- "pass" --> D["Write delivery-N.md<br/>map the workflow"] |
| 36 | D --> DG{"Delivery gate<br/>programmatic check + judge"} |
| 37 | DG -- "revise <= 3" --> D |
| 38 | DG -- "pass" --> F["Final output<br/>all gates clean"] |
| 39 | |
| 40 | S["State + log<br/>state.json + run-log.md"] -. "records" .-> P |
| 41 | S -. "records" .-> D |
| 42 | Stop["Stop guards<br/>max 12 iterations<br/>no progress x2<br/>budget caps"] -. "watch" .-> PG |
| 43 | Stop -. "watch" .-> DG |
| 44 | ``` |
| 45 | |
| 46 | **A loop design coach for Claude Code.** Looper is a skill that helps you design a *good* agent loop — a sharp goal, checkable verification, and a second model in the review seat — then lets you run it in the same session or save it as a portable spec. It is a design layer first: it writes files and hands the current session a clear execution prompt. |
| 47 | |
| 48 | Invoke it with `/looper`. It interviews you, critiques your design against built-in best-practice rubrics, lets you wire in a cross-model reviewer or judge (including non-Claude models), shows you the loop as a terminal-friendly ASCII flow preview, and writes out `RUN_IN_SESSION.md`, `loop.yaml`, a compiled `loop.resolved.json`, a human-readable `LOOP.md`, a thin `run-loop.py` you own and edit, plus an empty `loop-workspace/` and a README for the loop. |
| 49 | |
| 50 | Maintainer: Kevin Simback · GitHub [@ksimback](https://github.com/ksimback) · X [@ksimback](https://x.com/ksimback) |
| 51 | License: MIT |
| 52 | |
| 53 | --- |
| 54 | |
| 55 | ## Where Looper fits among Claude Code's loops |
| 56 | |
| 57 | The Claude Code team's own taxonomy ("Getting started with loops") sorts loops by what you hand off: **turn-based** loops hand off the *check* (verification skills), **goal-based** loops hand off the *stop condition* (`/goal`), **time-based** loops hand off the *trigger* (`/loop`, `/schedule`), and **proactive** loops hand off the *whole prompt* (routines composing all of the above). Every one of those primitives *runs* a loop. Looper is the layer in front of them: it helps you **design** a loop that's worth running, then emits a spec any of the four can execute. |
| 58 | |
| 59 | Concretely, what each loop type asks you to hand off is exactly what Looper coaches and hardens: |
| 60 | |
| 61 | - **Turn-based** — the check you'd encode as a verification skill is Looper's typed `verification` block: programmatic first, judge rubric second, human signoff last. |
| 62 | - **Goal-based** — `/goal`'s stop condition is Looper's `definition_of_done` plus gates; the difference is *who judges it* (a model family you chose, against a typed rubric) and what surrounds it (revision caps, no-progress stalls, budget guards). |
| 63 | - **Time-based** — `/loop` and `/schedule` re-fire whatever you give them; give them a loop that already passed compile and lint, and each firing follows `RUN_IN_SESSION.md` or `run-loop.py` instead of an ad-hoc prompt. |
| 64 | - **Proactive** — a routine is only as good as the prompt it repeats; the compiled `loop.resolved.json` is a versionable, reviewable artifact you can hand to a routine and audit later. |
| 65 | |
| 66 | ### What `/goal` actually does |
| 67 | |
| 68 | `/goal` sets a persistent objective for the session. Once set, Claude keeps |