---
name: loop-engineering
description: >
  Turn a recurring manual prompt-and-babysit task into a self-running loop: a goal
  with a verifiable stopping condition, a maker agent that does the work, a separate
  checker agent that verifies it, and a state file that persists between runs. Use
  when you keep prompting the same task, or want scheduled autonomous work.
license: MIT
source: https://vibemarketers.ai/starter-pack/loop-engineering/SKILL.md
---

# Loop Engineering

The unit of work is no longer the prompt. It is the loop: a system that finds the
work, does it, checks itself, records state, and decides the next move.

## The model in four words

- **Goal**: a verifiable stopping condition. "All tests in tests/auth pass" is a goal.
  "Refactor the auth module" is not; nothing can check it.
- **Loop**: the system that runs the goal on a heartbeat instead of you prompting turn
  by turn.
- **Task**: a discrete unit the loop hands to a sub-agent, usually in an isolated git
  worktree so parallel agents do not collide.
- **Completion**: the verified stop. Maker and checker are different agents; models
  grade their own homework too generously, so self-verification never counts as done.

## The fast path

- Run until done: `/goal all tests in tests/auth pass and lint exits clean`
- Cap the cost: `/goal --tokens 250K ...`
- On a schedule: `/loop 5m check error logs and open an issue for new stack traces`
- Both: `/loop every morning at 9am: triage CI failures, then /goal each suite is green`

## The build recipe (unattended loops)

1. Pin the goal as something a script or evaluator checks from real command output.
2. Pick the cadence: /goal once, /loop while the session lives, cron or scheduled
   tasks for anything that must survive a restart.
3. Isolate parallel sub-agents in git worktrees.
4. Create a maker agent that implements one task and never self-approves.
5. Create a checker agent with different instructions and a cheaper model. It re-runs
   the real checks itself and returns PASS or FAIL with evidence.
6. Keep a state file (LOOP_STATE.md) in the repo: open, in progress, done, blocked.
   The model forgets between runs; the repo does not.
7. Set a token ceiling, a turn bound, and a fallback for unresolved items.
8. Watch cycle one. Never walk away on the first run.

## Guardrails

Verification stays your job. Read what the loop produced; an unattended loop is an
unattended mistake-maker, and the gap between what exists and what you understand
grows exactly as fast as the loop ships.