Multi-repo autonomous dev team loop

The fleet pattern: run agent loops across multiple repos in parallel, each isolated in its own git worktree, with a pluggable vendor layer spanning Claude Code, Codex, Cursor CLI, and OpenCode.

prompt
→ Claude
Register repos, run loops across them in parallel, each loop in its own git worktree; pluggable vendor layer (claude-code, codex, cursor-cli, opencode) — plan, review, fix, ship on a loop.
claude-code

Implementation note

When to use: you are past single-repo loops and want agent capacity across a portfolio — several services or projects receiving loop attention in parallel, the fleet pattern. How it works: register your repos with the runner, then launch loops across them in parallel, each loop isolated in its own git worktree so concurrent runs never trample each other's working state. A pluggable vendor layer means each loop can run on Claude Code, Codex, Cursor CLI, or OpenCode, and the loop shape covers plan, review, fix, and ship. Safety: worktree isolation is the core rail — parallel agents share nothing at the filesystem level, so one loop's mess cannot corrupt another's checkout. The risk that scales with the fleet is spend and review load: five parallel loops produce five streams of diffs needing human eyes. Start with one or two repos and per-loop caps before going wide.

Source: nexu-io/looper

More automation loops

Run workflows with dynamic sub-agents

/goalnew

Split a task into packets, run sub-agents in parallel, synthesize results, and verify completion.

prompt
→ Claude
/goal loop and verify until complete
automationlow risk

Run agent turns until goal met

/goalnew

Agent executes repeated turns toward a condition, with a lightweight evaluator checking progress after each turn until the goal is reached.

prompt
→ Claude
/goal <condition turns a prompt into a durable objective. Thanos immediately starts a turn toward the condition, and after each turn a fresh, tool-less side-channel evaluator (a one-shot completeSimple call, not a subagent — so no extra agent turn and no re-entrancy) reads the last turn's evidence and returns MET / NOT MET . NOT MET auto-continues another turn with the reason as guidance; MET clears the goal and records the achievement. Unparseable evaluator output is treated as NOT MET (fail-safe: it never declares a false "done
automationmedium risk

Run agent until goal met

/goalnew

Queue agent turns with goal context until your objective is achieved, treating the goal as untrusted data.

prompt
→ Claude
/goal <objective , after /goal resume , and after every agent turn that leaves the goal active , the extension queues Codex's goal continuation prompt as hidden model-visible context. The objective is XML-escaped and wrapped as untrusted user data so it does not become higher-priority instructions
automationlow risk