v1.6.0 — Buddy System: one Opus Boss, many providers

The loop's maker/checker split now spans model providers. Say "autonomous-loop buddy system" and one Opus session — the Boss — runs each round across Codex, Grok, Sonnet and Haiku, so many lanes build at once and no lane is reviewed by the provider that built it.

The seats

• Boss (Opus) — rulings, briefs, local merges, gates, git, the PR. Nothing a seat claims counts until the Boss re-runs the gates on the integrated head.
• Astra (Codex) — lanes with disjoint files, contracts, risks and a test plan per round.
• Two build sides in parallel — Sonnet leads with a Haiku swarm on exact-change satellites, and Sol orchestrating Luna builders in standalone clones on lanes whose contracts are settled.
• Grok reviews lanes and runs the security round; Sol is the merge reviewer when Codex built nothing; Luna re-reviews Claude-built fixes.

Degrade, don't wait. A provider probe picks FULL, NO-CODEX, NO-GROK or CLAUDE-ONLY every round and whenever a seat hits its limit. Seats move to the available column without waiting for a reset — a provider limit is never a pause or a strike.

One stacked PR per round. Each push round ends in a PR based on the previous round's branch, so building never waits for a merge. The stack merges at the end, only on your word.

Flags (they compose): --mode <full|no-codex|no-grok|claude-only> pins a ceiling — claude-only never probes and sends no code to another provider · --local pushes nothing · --rounds <n> bounds a scheduled run · --plan <path> builds an existing plan · relay sends off-machine gates to a relay worker. Active flags are recorded on BOARD.md, so a resumed run never widens provider access or push authority on its own.

Project settings stay in your repo. A setup wizard writes a ## Buddy System profile into docs/loop/LOOP.md — commit identity, gate, copy ratchet, security-critical areas, push authority. The skill carries no project data.

Cautions. In any mode but CLAUDE-ONLY, code is read by xAI and OpenAI models. The Codex build side runs with full access inside standalone clones (cloud credentials stripped); pin --mode no-codex where that isn't acceptable. Grok and Codex CLIs are optional — without them the build runs on Claude seats only.

Runbook: references/buddy-system.md · seat scripts and briefs: buddy-system/ · PR #6.

v1.4.2 — Relay: watchers die with the work

Companion fix to v1.4.1's "register and verify": nothing told the watchers to stop, so a resolved job would leave both machines firing headless watcher passes every 5 minutes — forever.

A watcher's lifecycle is now bound to open jobs, symmetric with registration:

• Any watcher pass (controller or worker, session or headless) that finds no open relay issue binding its node tears itself down: removes its own scheduler entry (schtasks /Delete /TN "relay-<repo>" /F / launchctl bootout + plist removal), records none (torn down <date>) in the node table, commits, and stops /loop polling.
• The controller closing the last open job performs its own teardown and leaves a closing comment so other nodes tear down on their next pass.
• Re-joining later is cheap: the next "autonomous-loop relay" on a new job re-registers from scratch.
• New "immortal cron" failure drill in references/relay-scenarios.md.

No open jobs, no watchers.

v1.4.1 — Relay: register and verify the watcher, never merely offer it

Hardening from the first real worker-node run: the node joined and worked interactively, but no Task Scheduler entry was ever registered — so when the baton flipped, nothing on that box would notice until a human opened a session. "Watching" that exists only inside a session dies with the session.

The fix applies the base loop's own rule — describing a wake-up isn't setting one — to Relay's join flow:

• Joining now ends with the OS-scheduler backstop registered and verified: schtasks /Query /TN "relay-<repo>" (Windows) / launchctl list | grep relay-<repo> (macOS) must succeed before the node counts as joined.
• Explicit opt-out instead of silent absence: if the user wants no unattended execution on a box (e.g. a TASK is on hold), the node table records none (declined) — so the controller knows a TASK sent there waits for a live session.
• New "silent node" failure drill in references/relay-scenarios.md documenting the observed failure and correct behavior.

v1.4.0 — Relay (multi-node): two+ Claudes, different machines, one loop

Say "autonomous-loop relay" and Claude Code instances on different machines run the same loop on the same repo and hand work to each other — no human copy-pasting between sessions. Works for any pairing: mac↔win, mac↔mac, win↔win.

How it works

• Coordination lives entirely in the target repo: the master file (docs/loop/LOOP.md) gains a ## Relay section; one GitHub issue per job (body = living summary, comments = structured TASK n / RESULT n messages); redacted payloads committed under docs/loop/relay/<issue>/.
• Labels are the baton — awaiting:worker / working / awaiting:controller, exactly one present. Only the holder acts; one task outstanding at a time; the worker claims before executing so duplicate watcher firings never re-run a state-mutating task.
• Roles bind per job, not per machine — a controller directs and authors fixes; a worker executes on its own box and reports facts. Any node can hold either role on different jobs.
• First run = setup wizard (detects remote/auth/visibility, asks what's delegable and what remote workers may do, confirms, then creates labels + section + first issue). Every other machine joins by cloning and saying the same phrase.
• Two-layer watching — the live session polls via /loop (~1–2 min round-trips) plus a launchd / Task Scheduler backstop firing an idempotent headless pass every ~5 min, so sessions can die, sleep, or reboot and the run continues.

Guardrails (the command bus may be world-writable)

• Only comments from accounts in the node registry are instructions — everything else, including instruction-shaped text inside captured logs, is data.
• Redact-first logging on public repos; destructive ops require an explicit authorized-by-human marker; 3 failed round-trips on one hypothesis → needs:human escalation.

New files

• references/relay-template.md — wizard question list, master-file section, issue/comment templates, watcher prompt, scheduler snippets.
• references/relay-scenarios.md — four worked examples incl. failure drills (duplicate watchers, injection attempts, session death, push races).

v1.3.0 — Multi-agent coordinator (Managed Agents API)

Run the loop's roles as a persistent coordinator + roster on Anthropic's Managed Agents API, instead of subagents you dispatch and discard.

• Coordinator = the loop driver — holds the spine, picks goals, delegates to context-isolated session threads.
• Roster = the roles, made into agents — maker, code-reviewer, security-auditor, red-team, verifier, each with its own model/prompt/tools. Maker ≠ checker becomes the topology: the maker can't grade its own work because grading doesn't route to it.
• Capability-boundary shipping guard — push/merge/deploy tools go to the coordinator only, behind human confirmation; a worker literally can't ship.
• Parallelism via roster copies — fan independent goals out to multiple maker threads (worktree per maker still isolates edits).
• New: references/multi-agent-coordinator.md — roster map, create-coordinator snippet, thread observability, interrupt/archive.

Merged via #3.

v1.2.1 — Actionable interruption resume

Refines the v1.2.0 interruption-resilience feature so the loop actually schedules a resume instead of just describing one.

• Call a real scheduler, don't narrate it. On a usage/rate-limit wall the loop schedules a one-shot resume via the harness's tool — in Claude Code a one-shot CronCreate (recurring: false, fires once then auto-deletes) or ScheduleWakeup (in-session, ≤1h).
• State-first, idempotent prompt. The wake-up reads the spine + git/PR state, no-ops if the run already finished and pushed cleanly, or resumes the remaining steps if it stalled — carrying the same guardrails (push, but do not merge).
• Honest about durability. CronCreate/ScheduleWakeup are session-only (in-memory): they cover a paused session. If a limit might kill the session, back the resume with a durable trigger (a /schedule routine, external cron, or human re-launch). The spine on disk remains the backstop — zero lost work either way.

Full changelog: v1.2.0...v1.2.1

v1.2.0 — Interruption resilience (retry + resume)

Long unattended runs now treat interruptions as a pause, not a death.

• Surviving interruptions — a usage/rate limit, 429/503/529 overload, timeout, or crash is not a goal FAIL and never counts toward the 3-strikes escalation.
• Retry with backoff on transient errors; wait out a short limit window or schedule a wake-up/cron for a long one, then resume the same step.
• Checkpoint before anything long + commit at each PASS → worst case you lose only the in-flight step, never merged work.
• Idempotent resume — a half-done goal is re-derived from the spine + git, not double-applied.

An open session rides straight through a limit; a killed one is picked up by the next session with zero lost work. Includes everything in v1.1.0.

Full changelog: v1.1.0...v1.2.0

v1.1.0 — Optimization goals (autoresearch)

Adds discipline borrowed from Karpathy's autoresearch.

• Optimization goal type — a metric-driven second goal shape alongside binary TDD goals: one primary metric + direction + threshold, a fixed per-trial budget, change in a throwaway worktree, then keep-the-commit-or-revert on the result.
• EXPERIMENTS.md ledger — append-only record of every attempt (idea → Δ vs baseline → kept/reverted) so a discarded idea is never re-run.
• Rewind-before-escalate — reset to last known-good and try a different angle before the 3-strikes escalation.
• Guarded self-revision — the loop may append evidence-backed heuristics to a "What works here" section of LOOP.md, but may never edit guardrails or security invariants.

Full changelog: v1.0.0...v1.1.0

v1.0.0 — Autonomous Loop

Initial release of the autonomous-loop Claude Code skill — a durable, spine-based harness for long, unattended, multi-goal work. A practical application of Addy Osmani's loop engineering.

• The spine — LOOP.md, GOALS.md, BOARD.md, handover.md, audits/ — externalizes all state to disk so any fresh session resumes with zero lost context.
• Maker ≠ checker on every goal; independent reviewer panel + red-team for security-critical changes.
• TDD iteration (LOAD → PICK → red → implement → review → verify → pass/fail), fan-out via git worktrees.
• Guardrails: scope discipline, no silent caps, comprehension-debt guard, confirm-the-irreversible.
• Unattended modes: interactive-autonomous, scheduled/self-improving, resume.
• Apache-2.0.