← ClaudeAtlas

autonomous-looplisted

Run an autonomous, self-directed build loop that keeps working across many goals without per-step prompting — design the system that does the work, then let it run (Addy Osmani's "loop engineering"). Use whenever the user wants to "keep going on your own", "run until done", grind through a backlog or goal-list unattended, set up a maker/checker agent workflow, run a self-improving or nightly loop, or build a durable externalized spine (goals + board + handover) so work survives context resets. Also covers Relay — the multi-node mode where two or more Claude instances on different machines run the same loop on the same repo and hand work to each other via GitHub issues. Trigger on phrases like "autonomous loop", "keep working without me", "no human intervention", "loop engineering", "self-improving loop", "run the loop", "ralph loop", "multi-agent coordinator", "agent roster", "autonomous-loop relay", "relay setup", "sync two claudes", or "cross-machine handover" — even if they don't say "skill".
asiridalugoda/autonomous-loop · ★ 1 · AI & Automation · score 65
Install: claude install-skill asiridalugoda/autonomous-loop
# Autonomous Loop A harness for running long, unattended, multi-goal work — the kind where a human isn't approving each step. It is a direct application of Addy Osmani's **loop engineering** (`https://addyosmani.com/blog/loop-engineering/`). The four ideas that make it work: > "You design the system that does it instead." — don't do the task by hand; build the > machine that does the task, then let it run. > > "The model forgets, the repo doesn't." — externalize all state to files on disk, so any > fresh session (or a cron run) can resume with zero lost context. > > "Split the one who writes from the one who checks." — the agent that implements a goal > never grades it. A separate agent verifies. Maker ≠ checker. > > "Verification is still on you." — autonomy multiplies output, including mistakes. The > guardrails below are what keep it from confidently amplifying drift. ## When this applies Use it when the work is **large, decomposable, and verifiable**: a backlog of features, a migration, a hardening sweep, a spec that expands into dozens of goals, or a standing "keep improving this" mandate. The payoff is that you keep working across many iterations without the user re-prompting, and the work survives your own context being reset. Do **not** reach for it on a single quick edit, a one-shot question, or anything a human wants to steer turn-by-turn. The loop's overhead (spine files, reviewer panels) only pays off across many goals. ## The shape of the system Everything