Superlite, a Claude Code plugin, runs build tasks in parallel

The author of the contextfirst.blog post built superlite after getting tired of agent workflows that stop to ask permission every few minutes. He describes handing an agent a spec, making a sandwich, and coming back to find it asking whether he approved section 1 of the design, then section 2, then the plan, then how to execute it. Once building began it ran one task, a review, a fix, a re-review, then the next task. He wanted a contractor, not a collaborator.

Superlite is a Claude Code plugin that plans a build, splits it into tasks that can run side by side, hands each one to the cheapest agent that can do it well, checks the seams between them and reviews the result. It then leaves a list of every decision it made while the user was away. The author says he uses the superpowers workflow a lot and that it is excellent for keeping a human close to every step. Superlite borrows its plugin layout, session-start hook and lifecycle skills. But when he already knew what he wanted, he profiled superpowers and found the time going to five places: 8 to 12 human gates per feature; strictly sequential execution (on his first benchmark, a single-file queue of 21 dispatches); a review after every task with re-review loops (about 12 minutes of a 34-minute build); the full test suite re-run by several skills; and Opus subagents on the critical path writing code at about half Sonnet's speed. He calls each a sensible safety net and says superlite is not a rival but is tuned for autonomous development at speed. His advice: do not enable both in the same session, because they share skill names and both inject context at startup.

How it works. Superlite sizes the request first: a typo is just fixed, a change to an existing flow gets a short design in chat, and a new project gets one batch of up to four questions and then one design-and-plan document that the user approves once. After that it stops only for things that are destructive, outward-facing or security-sensitive, and it never pushes or merges without the user. The user picks the orchestrator: with a human orchestrator, you see the whole plan with its predicted schedule and approve it before anything runs; with an AI orchestrator, you are not needed at all. Every choice it would normally ask about is recorded as a ruling, with what it decided, why, and what it costs if wrong.

The plan is a task graph. Each task lists the files it owns, the interfaces it consumes and produces, and the tests it must pass. Tasks that share no files and have no dependencies run at the same time, and the graph decides how wide the build goes; on the current benchmark it peaked at 18 agents working at once. Roles are split by model: Opus coordinates, planning and dispatching but not allowed to touch code; Sonnet builds most tasks and reviews the packages; Haiku builds only small, fully specified mechanical tasks that are not on the critical path; a fresh Opus final reviewer reads a review packet built from the run's logs and returns findings only; and fix-only agents in three tiers take those findings, routed by how well the cause is understood.

Rules are enforced by hooks rather than prompts, because the author found the coordinator would read an instruction not to edit code and edit it anyway. One hook blocks the coordinator from editing project code. Another turns any raw pytest or npm test run into a background run so tests never block it. Another refuses to let anyone kill processes by name. A plan must pass lint --stable before work starts, and stable tasks are sent off the moment it passes. Hooks also record each agent's tokens, cost and time, which feeds the next run's predictions and a soft budget that warns the user at 70% of the cap.

Setup needs Claude Code, git, Python 3.10 or newer for superlite's own tools (the project being built can be in any language), and bash (Git Bash on Windows). The source is iha2/superlite on GitHub. Install with /plugin marketplace add iha2/superlite and /plugin install superlite@superlite-dev, or clone the repo and run claude --plugin-dir with the local path for one session. A smoke test is to start a fresh session and send "Let's make a react todo list"; a working install starts brainstorming before it writes code. During a run, a .superlite/ folder in the project holds progress.md (rulings and log), test-summary.json (latest test result) and metrics.jsonl (time and cost per agent).

Benchmarks. All figures come from the author's headless harness, which builds the same project from the same spec on Opus and scores it with a hidden test suite the agents never see. The test project is a static site generator plus a spreadsheet engine (formula evaluator, HTTP API and browser UI) built as one project, scored by 177 hidden tests. The latest superlite run took 16.1 minutes. Against superpowers, the author reports the same 177 out of 177 hidden tests in about half the time, and he calls this one run of the current build against earlier runs on the same machine, "a strong hint rather than peer-reviewed science". The latest build also beat its own previous build, which averaged 26.9 minutes, by 40%.

How it got there. On a smaller task, sitegen alone (nine modules, 89 hidden tests), superpowers dispatched 21 agents one after another while superlite dispatched 10, up to five at once; the author says most of that speed came from getting rid of the queue. Across three runs of an earlier superlite build on the full 177-test project against superpowers, he reports it was faster on average and much more predictable, and mentions a 47-minute worst case. That earlier build finished building at about 13 minutes, then spent 10 to 18 more minutes on reviews, fixes and the coordinator running tests in the foreground. The fixes were: the coordinator lost the ability to edit code, every test run moved to the background, fixes went to tiered fix-only agents, and stable tasks started building while the rest of the plan was still being fixed. That is the build that ran in 16.1 minutes.

His takeaway: a slow agent workflow is usually slow because work waits in a line and something keeps asking permission, not because the model thinks deeply. Split work along interface boundaries, let independent tasks run at once, move mechanical steps into scripts, and enforce the rules that matter with code. A follow-up post covers the philosophy and decisions behind superlite in more depth.

Key facts

• Superlite is a Claude Code plugin (github.com/iha2/superlite) that plans a task graph, runs independent tasks in parallel, and asks for one approval before building.
• The author reports a 16.1-minute build of a static site generator plus spreadsheet engine that passed all 177 hidden tests, in about half the time of superpowers.
• Opus coordinates but cannot edit code, Sonnet builds and reviews most tasks, and Haiku takes only small mechanical tasks; hooks enforce these rules.
• The latest build beat superlite's own previous build (average 26.9 minutes) by 40% and peaked at 18 agents working at once.
• The author calls the comparison one run against earlier runs on the same machine, a strong hint rather than peer-reviewed science.

Why it matters

The post argues that agent workflows are often slow because work waits in a queue and the tool keeps asking for permission, not because the model is slow. The author's profile of superpowers on his own tasks found 8 to 12 human gates per feature, sequential execution, and about 12 minutes of review in a 34-minute build. Superlite is his answer: plan for parallelism, match the cheapest capable agent to each task, and enforce rules with hooks. The takeaway is a set of design ideas: split work along interface boundaries, run independent tasks at once, and put the rules that matter in code.

Who it affects

Claude Code users who already know what they want built and would rather hand over a spec and come back to tested work. The author says that if you want to steer each step, superpowers is the better fit. Anyone running both should keep them in separate sessions, since they share skill names and both inject context at startup.

How to use it

You need Claude Code, git, Python 3.10 or newer for superlite's own tools, and bash (Git Bash on Windows). Install with /plugin marketplace add iha2/superlite and then /plugin install superlite@superlite-dev, or clone the repo and start Claude Code with --plugin-dir pointing at the checkout for one session. Test it by sending "Let's make a react todo list" in a fresh session; a working install starts brainstorming before writing code. Then describe what you want in a paragraph or spec file, choose a human or AI orchestrator, and let it run. Progress, test results and per-agent time and cost land in the project's .superlite/ folder.

How solid is it

All numbers come from the author's own headless harness, which scores builds with a hidden test suite the agents never see. The author himself calls the superpowers comparison one run of the current build against earlier runs on the same machine, a strong hint rather than peer-reviewed science. The post gives the superlite figures (16.1 minutes, 177 of 177 tests, 26.9-minute previous average) but only the phrase "about half the time" for superpowers. No independent verification or third-party reproduction of the benchmarks is mentioned.

Risks and caveats

The benchmark is a single project type run on Opus, so it says little about other workloads. The speed gains rest partly on running many agents at once, and hooks record tokens and cost, but the post gives no cost or token figures for the benchmark runs. The author says superlite stops only for destructive, outward-facing or security-sensitive actions and never pushes or merges without the user; with an AI orchestrator the user is not involved at all, so the recorded rulings are the place to check decisions afterward. The author also reports that prompts alone failed to stop the coordinator editing code, which is why hooks enforce the rules.

“I didn't want a collaborator that needed me every four minutes. I wanted a contractor.”

— the post's author, contextfirst.blog