Superlite: A Faster Alternatie to Superpowers Developer iha2 released superlite, an open-source Claude Code plugin that plans a build, splits it into parallel tasks, routes each task to the cheapest capable agent, and reviews the result without the human approval gates used by the existing superpowers workflow. The author profiled superpowers and attributed its slowdown to 8–12 human gates per feature, strictly sequential execution (a 21-dispatch single-file queue on the first benchmark), a review after every task with re-review loops consuming about 12 minutes of a 34-minute build, repeated full test-suite runs, and Opus subagents writing code at roughly half Sonnet's speed. Superlite keeps superpowers' plugin layout, session-start hook and lifecycle skills but runs autonomously and returns a list of every decision it made. Field Notes https://contextfirst.blog/tag/field-notes/ Superlite: hand an agent a spec, come back to tested work Why I built superlite, an autonomous build workflow for Claude Code that doesn't ask permission every four minutes: how it works, how to use it, and the benchmarks. I had a dream. I would hand an agent a spec, close the laptop, make a sandwich, and come back to finished, tested, committed work. Here's what actually happened. I handed over the spec. I made the sandwich. I came back. The agent had written one paragraph and was asking, very politely, whether I approved section 1 of the design. I approved it. I sat down. I waited. Section 2. Approve? Yes. Section 3. Approve? Yes. The spec? Yes. The plan? Yes, obviously, it's the plan I just watched you write. And how would I like the plan executed? However is fastest, please, I beg you. Then it started building. One task. Then a review of that task. Then a fix for the review. Then a re-review of the fix. Then the next task. I watched a progress log scroll past like a train at a level crossing: no stopping it, no getting past it, and no idea how many carriages were left. I'd refresh the terminal. Still on task 3. I'd answer an email. Still on task 3. I'd start a second sandwich purely to have something to do with my hands. Task 4, under review. The sandwiches were very good. The software didn't exist yet. And the worst part wasn't the time. It was that I couldn't leave. Every time I walked away, I came back to a question that had been sitting there for twenty minutes, waiting for me to type "yes." I didn't want a collaborator that needed me every four minutes. I wanted a contractor. Here's the spec, here's the key, call me when it's done. So I built superlite https://github.com/iha2/superlite?ref=contextfirst.blog : 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. Then it leaves you a tidy list of every decision it made while you were busy with the sandwich. This post covers why it exists, how it works, and how to use it. The benchmarks are there to show I'm not just saying it's fast because I wrote it. Why I built it First, a disclaimer, because I like this project and don't want angry emails. I use superpowers https://github.com/obra/superpowers?ref=contextfirst.blog a lot. It's a careful, collaborative workflow that keeps a human close to every step, and it's genuinely excellent at that. Superlite borrows its bones shamelessly: the plugin layout, the session-start hook, the lifecycle skills. Credit where it's due, and then some. But when I already knew exactly what I wanted, most of the time went on the workflow waiting for itself. I profiled it, the way you'd check your bank statement after a suspicious weekend. The time went to five places: - 8–12 human gates per feature. One question per message, designs approved section by section, then separate reviews of the spec, the plan, and the method of executing the plan. It's very thorough. It's also how a four-hour meeting gets scheduled. - Strictly sequential execution. One implementer, then one reviewer, then the next task. On my first benchmark that was a single-file queue of 21 dispatches, like a bank with one teller and a very long lunch. - 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. In case it changed its mind. - Opus subagents on the critical path, writing code at about half Sonnet's speed. Brilliant, thoughtful, and in no hurry whatsoever. None of these are mistakes. Each one is a sensible safety net. Stacked together, they're perfect when you want to steer every step, and slightly maddening when you just want the thing built. So superlite https://github.com/iha2/superlite?ref=contextfirst.blog isn't a rival to superpowers. It's tuned for a different job: autonomous development, at speed. If you want to steer each step, use superpowers. If you want to hand over a spec and come back to working code, use superlite https://github.com/iha2/superlite?ref=contextfirst.blog . Just don't enable both in the same session. They share skill names, both inject context at startup, and they argue like siblings in the back seat. How it works The short version: one approval, a plan written for parallelism, agents matched to the work, and rules enforced by code because, as it turns out, agents read the rules and then do what they like. One batch of questions, one approval. Superlite sizes the request first. A typo just gets fixed, without a design document about the typo. A change to an existing flow gets a short design in chat. A new project gets one batch of up to four questions, then one design-and-plan document. You approve it once. After that it only stops for things that are destructive, outward-facing or security-sensitive. It won't push to main while you're getting lunch. It will do everything else. You choose who's in charge. With a human orchestrator, you see the whole plan with its predicted schedule and approve it before anything runs. With an AI orchestrator, you're not needed at all, which is either freeing or mildly insulting depending on your mood. Every choice it would normally ask about gets recorded as a ruling: what it decided, why, and what it costs if it got that wrong. When you come back, you know exactly which decisions to second-guess first. A plan written for the split. The plan is a task graph. Each task lists the files it owns, the exact interfaces it consumes and produces, and the tests it has to pass. Tasks that don't share files and don't depend on each other run at the same time. The graph decides how wide the build goes. On the current benchmark that peaked at 18 agents working at once, which is roughly the size of a small startup, minus the ping-pong table. Agents matched to the work. The org chart: - Opus coordinates. It plans and dispatches, and it is not allowed to touch the code. Management, basically. - Sonnet builds most of the tasks. - Haiku builds only small, fully specified "mechanical" tasks that aren't on the critical path. The intern gets the well-defined stuff. - Sonnet reviews the packages. - A fresh Opus final reviewer reads a review packet built from the run's logs and returns findings only. It's never allowed to fix anything. It just points. - Fix-only agents in three tiers take those findings, routed by how well the cause is understood. Gated by code, not by prompts. I learned this one the hard way. You can write "the coordinator never edits code" in a prompt in bold, in capitals, with feeling. The coordinator will read it, nod, and edit the code. So now hooks enforce it. One hook blocks the coordinator from editing project code. Another catches any raw pytest or npm test it runs and quietly turns it into a background run, so tests never block it. Another refuses to let anyone kill processes by name there's a story there, and it's in the deep dive . A plan has to pass lint --stable before work starts, and stable tasks are sent off the moment it passes. Every run is measured. Hooks record each agent's tokens, cost and time. That feeds the next run's predictions and a soft budget that taps you on the shoulder at 70% of the cap. How to use it You'll need Claude Code, git, Python 3.10 or newer for superlite's own tools; the project you build can be in any language , and bash Git Bash on Windows . The source is iha2/superlite https://github.com/iha2/superlite?ref=contextfirst.blog on GitHub. Install it from the marketplace: /plugin marketplace add iha2/superlite /plugin install superlite@superlite-dev Or clone iha2/superlite https://github.com/iha2/superlite?ref=contextfirst.blog and load a local checkout for one session: claude --plugin-dir