Design and ship autonomous loops in Claude Code — systems that find work, act on it, verify the result, and decide the next step, instead of you hand-prompting each turn.
A Claude Code Skill and a small library of ready-to-adapt patterns for loop engineering — the practice of replacing yourself as the person who prompts the agent and designing the system that does it instead.
The phrase comes from two near-simultaneous statements in June 2026 that lit up the AI dev community:
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." — Peter Steinberger, creator of OpenClaw
"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." — Boris Cherny, head of Claude Code at Anthropic
This repo answers the obvious follow-up question: how do we actually do that?
loop-engineering.skill— a one-click installable Claude Code Skill. Triggers automatically when you ask Claude to "automate this," "run this every morning," "keep going until tests pass," "set up a triage bot," and similar phrases. Walks Claude through specifying the loop, picking the right primitive, assembling the six pieces, and avoiding the common ways unattended loops go wrong.skill/— the source of the skill (SKILL.md, references, assets) for anyone who wants to read, fork, or extend it.examples/— five working starter setups you can drop into a real project: morning triage, goal-to-green, backlog burndown, watch-and-fix, and parallel migration. Each is a self-contained.claude/folder with subagents, state-file templates, and a README that says exactly how to wire it up.
Option A — drop the .skill file in:
mkdir -p ~/.claude/skills
unzip loop-engineering.skill -d ~/.claude/skills/Option B — symlink the source folder (better if you want to edit and iterate):
git clone https://github.com/iamarvindh/claude-loop-engineering.git
ln -s "$(pwd)/claude-loop-engineering/skill" ~/.claude/skills/loop-engineeringRestart Claude Code. Verify with /skills — you should see loop-engineering in the list.
After that the skill triggers itself when you say things like:
- "set up a daily triage that fixes flaky tests overnight"
- "keep going until all the auth tests pass"
- "migrate every call site of the old PaymentsClient to the new one"
- "build me a loop that babysits open PRs"
A loop is a recursive goal: define a purpose and a stopping condition, and let an agent iterate — find work, act, observe the result, decide the next move — until the condition holds or it escalates back to you.
The difference between a loop and a cron job is the decision-maker inside it. A cron runs a fixed script; a loop runs an agent that reads current state, picks the next action, does it, checks the result, and decides what to do next.
Every durable loop needs the same six pieces:
- A trigger —
/goal,/loop, a scheduled task, or a Stop hook. - Worktree isolation — so parallel agents don't collide on the same files.
- Skills — codified project knowledge so the loop doesn't re-derive your conventions every cycle.
- Connectors (MCP) — so the loop can touch your real tools (issue tracker, CI, Slack).
- Maker + checker subagents — never let the writer grade its own work.
- A state file — the spine; memory that lives on disk because the model forgets between runs.
The skill walks Claude through all of this whenever you ask for it.
Each lives in examples/<name>/ with its own README explaining the trigger, the assembly, and exactly how to run it:
| Example | When to use | Trigger |
|---|---|---|
goal-to-green |
Drive one task to a verifiable finish line in one sitting | /goal |
morning-triage |
"Every morning, look at what changed and surface what's worth doing" | Scheduled task |
backlog-burndown |
Work a labeled issue queue until it's empty | /goal or scheduled task |
watch-and-fix |
Babysit a long-running thing (CI, deploys) and react when state changes | /loop |
parallel-migration |
Mechanical change across hundreds of files | Dynamic workflow |
The skill enforces these and so do the examples. They exist because they're exactly where unattended loops go wrong:
- Verifiable stop conditions. "The code is good" is not a condition. "
npm testexits 0 and lint is clean" is. - Bounds. Always include a turn/time clause. An impossible condition without a bound loops to the wallet limit.
- Maker ≠ checker. A model grading its own work is too generous; "done" means nothing without a separate verifier.
- State on disk. The model forgets between runs. The repo doesn't.
- Escalate, never auto-merge. Unattended work opens PRs for review; risky or stuck work writes to an inbox and stops.
- Supervised first run. Never ship a loop straight to unattended-at-scale. Watch one cycle, read what it produced, then expand.
Two people can build the same loop and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do.
The leverage point moved from writing prompts to designing verification, isolation, and stop conditions. That makes loop design harder than prompt engineering, not easier.
Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.
New patterns, fixes to the references, additional example loops — all welcome. See CONTRIBUTING.md.
If you ship a loop in production using this skill, an issue or PR with a brief writeup is a great way to help others learn what actually works.
This skill stands on top of work by people who named the practice publicly first:
- Addy Osmani — Loop Engineering (the canonical essay; the six-piece framing is his)
- Boris Cherny — Claude Code, Anthropic
- Peter Steinberger — OpenClaw / OpenAI
- The official Claude Code docs at code.claude.com/docs —
/goal,/loop, scheduled tasks, hooks, subagents, dynamic workflows
MIT — see LICENSE. Use it, fork it, adapt it, ship something that ships work for you.