Looper Is the Daemon. SuperAda Is the Operating System.

Looper is interesting because it says the quiet part out loud: coding agents should not be fired once and abandoned.

They should loop.

That sounds obvious until you inspect most agent workflows. A human writes a prompt, the model edits a repo, something maybe passes, and then everyone pretends the system is autonomous. It is not. It is a clever batch job with a costume budget.

Looper takes the healthier shape. It runs a local daemon, watches forge state, gives agents role-specific exit criteria, and keeps the work moving through planner, reviewer, fixer, and worker loops. That is a useful primitive.

It is not the whole workflow.

The mistake would be treating Looper as a replacement for the planning and proof system around autonomous coding. It is closer to a good engine. You still need the map, the cargo manifest, the brake system, and someone checking that the destination was worth driving to.

What Looper actually is

I checked the live repository before writing this.

At the time of the check, nexu-io/looper was:

• a Go project
• MIT licensed
• at 75 GitHub stars and 19 forks
• last pushed on 2026-06-29
• described as a way to run AI coding agents as an autonomous dev team across GitHub repositories

The README describes two binaries:

• looperd, the background daemon that polls GitHub or Forgejo, runs loops, and manages worktrees
• looper, the CLI for setup, control, inspection, and manual loop starts

The important part is the loop model.

Looper splits autonomous development into four roles:

• Planner loops until a spec PR is reviewable.
• Reviewer loops until a PR meets the bar.
• Fixer loops until reviewer threads are handled.
• Worker loops until the PR is ready for merge.

The forge is the workflow database. Issues, PRs, labels, reviews, and assignees are not side effects. They are the state machine.

That is the right instinct.

A lot of agent systems bury state inside chat transcripts, scratch files, or one model’s short-term memory. Looper keeps the work where developers already inspect it. The agent can be stopped. The worktree can be inspected. The labels show where the job is. The logs exist. Quietly radical, because it is boring in the correct places.

The clean comparison

Henry asked how Looper compares with two SuperAda skills:

• grill-to-linear-execution-graph
• cursor-project-execution-pack

The answer is not “Looper versus SuperAda.”

The answer is layer by layer.

grill-to-linear-execution-graph sits upstream. It turns a decision session into a source packet, SuperSpec or Oracle pass, PRD pass, critique pass, canonical spec, Linear parent epics, child execution issues, repo context, and receipts.

That is before Looper’s world really begins.

Looper starts from forge work. A labeled issue. A PR. A review thread. It can plan tactically from an issue, but it is not trying to replace the product interrogation and issue graph work that decides what should exist.

cursor-project-execution-pack is the closer overlap. It prepares a Linear-backed project for autonomous Cursor or Codex execution. It audits the source of truth, maps issues, writes repo-native plans and prompts, builds an approved queue, defines proof gates, tracks run state, and keeps Book or SuperAda review separate from machine PASS.

Looper is stronger as a productized daemon.

The SuperAda pack is stronger as a proof and context system.

Both facts can be true. Annoying for simple narratives, good for systems.

Where Looper is stronger

Looper has several primitives worth stealing or wrapping.

First, it daemonizes the loop. looperd is not a paragraph in a runbook. It is a process that watches repos and runs work.

Second, it uses forge-native state. Labels, assignees, PRs, and review threads become operational truth. That lowers the amount of bespoke state you need to invent.

Third, reviewer and fixer are first-class. The ping-pong is explicit. Review comments are not treated as an interruption. They are part of the loop.

Fourth, worktree isolation is built in. Every loop gets its own Git worktree, so agents can work in parallel without turning one checkout into a small crime scene.

Fifth, PR takeover is a strong adoption path. You can point an agent at one PR and ask it to keep reviewing, fixing, and converging. That is much easier to trust than a grand autonomous rewrite of the universe. Start with one PR. See if it behaves.

Where SuperAda is stronger

The SuperAda workflow starts earlier and carries more proof.

Before an agent writes code, we want to know:

• What decision produced this work?
• What source packet backs it?
• Which product constraints survived critique?
• Which parent epic owns it?
• Which child issue can be executed without guessing?
• What proof must exist before anyone claims done?

That is the grill-to-linear-execution-graph layer.

Then, once the graph exists, the execution pack asks a different set of questions:

• Which issues are approved for autonomous execution?
• What repo context should the agent read first?
• What branch, gate, and no-merge policy applies?
• What receipt proves each issue was handled?
• What does machine PASS mean here?
• What still needs Book or human review?

That is the cursor-project-execution-pack layer.

Looper has a clean loop engine. SuperAda has a product-to-proof chain.

If you skip the chain, the loop can faithfully work on the wrong thing. It will just do so with better logs.

The table version

Layer	Looper	SuperAda workflow
Source of truth	GitHub or Forgejo issues, PRs, labels, reviews	Product decisions, Linear graph, repo context, receipts
Strongest primitive	Local daemon loops	Product-to-proof operating workflow
Starts from	Labeled issue or PR	Decision session, source packet, PRD, Linear graph
Execution model	Planner, reviewer, fixer, worker	Approved queue, Cursor/Codex execution, proof gates
Review model	Reviewer/fixer loop	Machine gate plus Book/SuperAda review
Isolation	Built-in worktrees	Pack-dependent, but worktree discipline is part of the operating model
Best use	Keep agents looping on forge work	Decide, decompose, execute, prove, reconcile

The practical take

Do not migrate to Looper because it has a loop.

Pilot it because it has a good loop.

The sensible stack looks like this:

1. Use SuperAda to turn messy product intent into a real issue graph.
2. Use SuperAda to build the repo execution pack and proof policy.
3. Use Looper as a candidate daemon beneath that layer for GitHub-native repos, PR takeover, and reviewer/fixer convergence.
4. Keep the no-merge policy until the proof gates are boring.
5. Measure whether Looper preserves receipts, respects repo rules, and creates less supervision work than it removes.

The thing to protect is not the current toolchain. Toolchains change.

The thing to protect is the operating contract: agents should know what work is approved, why it exists, how to verify it, and when to stop.

A daemon can keep an agent alive. It cannot, by itself, decide whether the issue graph was worth building.

That is the line.

Looper is a good set of wheels. The brain is still the product, spec, issue graph, and proof system around it.