loop-ops

# Loop Ops — outer-loop design discipline **A loop is not a prompt.** Turn-by-turn prompting puts you in the loop forever. *Loop engineering* inverts it: you design a **recurring process with memory, verification, and boundaries** that discovers work, hands it to agents, verifies the result, and decides — on a schedule or until a goal is met — whether to **land it or escalate to a human**. > "You shouldn't be prompting coding agents anymore. You should be designing the loops > that prompt your agents." — Peter Steinberger This skill is the **outer loop**: the orchestration layer *above* a single agent run. It is the twin of [`iterate`](../iterate/SKILL.md) — `iterate` is the *inner* loop (one metric, one session, git-as-memory); `loop-ops` is the design discipline for the loop that *schedules and gates* inner runs. It does not reimplement spawning or landing; it **composes** what this repo already ships. ## Native primitives schedule; loop-ops governs Claude Code now ships the *cadence* half natively. **Do not hand-roll a scheduler** — pick a native host, declare it as `host:` in the config, and spend the discipline where the primitives leave a hole. Verified surface, parameters and limits (2026-08-30): [references/native-scheduling.md](references/native-scheduling.md). | Native primitive | What it gives you | What it does NOT give you | |---|---|---| | **`/loop`** — a *bundled* skill ([docs](https://code.claude.com/docs/en/scheduled-tasks)), driving `CronCreate`/`CronL...