You feed the feature spec in. A stack of reviewed PRs gets out. Free, MIT-licensed, a Claude Code plugin. I don’t code anymore.
For over month I’ve let a plugin build my features. Prior to that, for near a year I almost did not write a piece of code myself. Claude took it out of me, but now it’s time to share with you a system that made this happened.
TLDR
In this article I’m introducing a free, open-sourced claude plugin that takes care of the building part of my $1M jouney. It handles feature delivery for my clients in 9-5 job. It handles implementation for my products, and my website, and comic page too.
You can read here about:
What it does & why it’s so good
What is the cost of PR (numbers-heavy, skip if you don’t care)
What’s the exact workflow as a developer.
What being a developer means if no coding is required?
Since AI boom happeneed a few years ago, the job of a developer completely went turned upside down. We don’t code anymore, we don’t even write tasks nor pr descriptions. Yet, we were never needed more. Here is what I do still.
I am brainstorming specifications and curating it to the form of exact requirements.
I approve the plan after splitting spec into the tasks,
I do final review & and I merge PRs.
Everything in between is Claude, empowered by a plugin, doing things on its own: building, testing, reviewing, arguing with its own review, auto-fixing.
It’s called Executor, and today it’s yours.
/plugin marketplace add sebwilgosz/agent-plugins
/plugin install executor@engineer-of-wealth
/executor:init
# recommended: enable auto-updates.With this, Its blueprint is being dropped from my wall, and the next leverbot is taking it’s place. I include it here for fun.
Here is what it does, what it costs, and how it evolved over time.
The problem it solves
You know the loop.
You ask Claude Code for a feature. It writes 600 lines. You read them, find two bugs, ask for fixes, and it breaks a third thing. An hour later you’re the reviewer, the tester and the project manager of a very fast junior who never gets tired, and never remembers what you said an hour ago.
I described it pretty accurately on my second comic issue which I include here for reference:
But the the thing is, LLM is not a bottleneck but YOU ARE, because each of those steps goes through you head. Mentally exhausting you in no time.
Executor moves you to the two places where your head is actually needed: the plan and the merge.
How it works
You give an RFC, a feature note, a GitHub issue, then you brainstorm the final requirements. This is what happens next:
It spec. It writes the final specification, and sends it to the another process, so it can split it into parallel implementation chains.
It plans. The spec becomes a checklist of features, listing dependencies and dependants. You approve it, or you change it. Nothing is built before you say yes.
It lays the foundation. Shared pieces (schema, types, config) go in one PR first, so the rest don’t fight over them.
It builds in parallel. One builder agent per feature, each in its own git worktree, each writing the spec’s tests first, then the code in your repo’s own patterns.
It opens stacks of draft PRs. A script opens them, not a model.
It reviews every PR. A reviewer runs your build, then reads the diff across six dimensions: duplication, correctness against the spec, test coverage, security, best practices, and your repo’s conventions.
It argues with itself. Every Critical finding goes to a separate verifier whose only job is to disprove it.
It auto-fixes what survives. A fixer writes a failing test for the bug, fixes it, and goes through review again. Three rounds at most, then it stops and tells you.
Once ready, You and your team do final reviews, then merge.
And here is a short list of things it will never do:
edit a test to make it pass,
force-push,
touch a PR from a fork,
post anything to GitHub unless you ask.
And, for those who like the detailed flow diagrams:
The features you’ll use every day
Even if you never build a whole spec, two of these are worth the install.
/executor:reviewworks on any PR, from any folder.review acme/api#7finds your local checkout and reviews there. On your own PRs it fixes the confirmed bugs. On anyone else’s it only reports.Auto-review on every PR you open. It’s a plain shell hook: no model, no tokens until the review actually starts.
/executor:shiptakes a branch from “done, I think” to a draft PR: commits, pushes, opens it, and the review starts on its own. The Important part here is, that PR description will not produce wall-of-text, but will be kept concise, and include visualisation for the reviewer to easier grasp the change./executor:specdrafts the spec from your notes, the repo, its CHANGELOG and open issues, and saves it wherever your specs live: Notion, GitHub issues, Linear or Jira. The approved plan can come back as tickets./executor:statusshows where every PR in the stack stands. It runs without a model turn, so it’s free.Your CI can be the build. If your tests live in CI, the reviewer reads the CI result instead of running the suite locally.
Plans live outside your repo. No
PLAN.mdcommits, no agent clutter in your git history./executor:initaudits your repo first: what the build is, where the tests are, which conventions to follow. Optional git hooks add copy-on-writenode_modulesfor fast worktrees and a lint/typecheck after each commit.
It works for any stack Claude Code works for. A Rails monolith, a TypeScript monorepo, a Python service, a CLI in Go: the builder follows your repo’s patterns, not mine.
What it costs: the experiment
I don’t trust tools that only show their best day. I am still improving the project, so you may expect even better numbers in the README soon. Here is what got checked so far.
I measured every build by role (orchestrator, builders, reviewers, verifiers), weighting tokens the way they’re billed: output costs 5x input, cache reads 0.1x. It is to come up with the best quality/cost balance. You may just run everything you do on Opus, but... well, your wallet, your choice I guess.
Cost per PR - evolution log.
Version 0.10.0. About $1.87 per PR.
First measured part, the baseline, happened in version 0.10.0. 9 PRs for about $16.80. That’s $1.87 per PR.**
The surprise was where it went. 56% of the tokens were the main Opus thread, the orchestrator. Not the builders writing code. It was the manager watching them. It ran 57 test and build calls itself, each one dragging its whole long context along.
So I changed three things:
PR opening moved into a script. It was costing about 30k tokens per builder for 1-2k of actual writing.
The build moved to CI, so the reviewer reads a result instead of running a suite.
The orchestrator stopped doing the work and only routes it.
Version 0.12.0: $1.43 per PR.
The main thread went from 0.74M to 0.22M tokens per PR.
Test calls in the main thread fell from 34 to 4.
Honest caveat: that build was calmer. No Critical findings, so no fix rounds. One good run isn’t a trend, so I kept measuring.
Version 0.13.2: $2.42 per PR
In the newest version, I’ve switched orchestrator to sonnet, and the bill for the main thread dropped to $0,71 per PR. Now, the main cost is Opus for reviewer - and this is exactly where I want the money to go.
I found, that if you have specs and exact tasks chains defined, allowing Sonnet to code gives basically the same results in terms of quality, but half the cost for the same work - and it’s faster.
Then, I put heavy effort on the final reviews of the work, and only at the very end I verify myself.
Five things I learned that apply to your agents too
You don’t need Executor for these. They’re true for any setup that runs Claude Code for more than ten minutes.
1. Your context is a budget. A cache read costs the same on Opus and Sonnet: $0.20 per million tokens. So a long context costs you on every turn, whatever the model. A short context saves more than switching to a cheaper model.
My AI ate 6M tokens to draw a single comic page
This is Part 2 of the 3-part series about building my visual brand with AI.
2. If it’s deterministic, it’s a script. Opening a PR, checking CI, assigning a reviewer: none of it needs judgement. A model doing it burns tokens and occasionally improvises. A shell script does it the same way every time, for free.
3. Put the expensive model where judgement lives. Opus reviews. Sonnet builds, verifies and fixes. The reviewer is the one place where a missed bug costs more than the tokens.
4. The machine tests, the model reads. Let the build and the test suite say pass or fail. Let the model read the diff and say why.
5. Make every finding prove itself. Of 315 verifier runs, 248 findings were confirmed, 47 were real but the wrong severity, and 18 were simply wrong. Each verifier run costs about 34k tokens: it starts from roughly 6k of context, asks one question, and answers in five lines.
Without the verifier, those 18 would have been “fixes” to working code.
That last one is a pattern you can steal for any cheap agent: one question, a facts-only brief, a dedicated agent, a stop rule, and a fixed short answer.
Who it’s for
I wish to say, that Executor is for everyone, but NO. It is for people, who care about making AI a lever for building, with increased, not reduced quality. You want it if:
Solo devs who want a second pair of eyes on every PR without waiting for one.
Devs in a team who want every PR reviewed the same way, against the same six dimensions, before a human looks - because you price your teammates time too!
Anyone building their own plugins, because Executor is a working example of hooks, skills, sub-agents and scripts that cooperate. Read the source. It’s MIT.
Why it’s free
I’m staff software engineer, and most of my time nowadays is taken by reviewing AI-generated code. With this, I hope we all will be able to give reviewers already filtered out bugs and this will make all our lives better.
I also would rather you see how I build before you ever pay me for anything.
Executor is the tool I use every day to ship my own products. If it saves you an hour this week, you’ll know what the rest of my work is like.
From now on, you’ll see it in the form of a leverbot in my comics, here and there. I hope you like the visual design too!
Get good at it in five days
Installing it takes a minute. Getting good at it takes a few days.
So I wrote a free 5-day email course: Ship with agents, not against your context. One short lesson a day, one thing to try, under 15 minutes each:
Run your first review, and see why every finding gets its own verifier.
Your context is a budget: what loads every session, what loads on demand, and what to cut.
Specs in, PRs out: write a spec an agent can build from.
Build your own plugin, and the six things to watch for when you do.
Manage plugins like code: enable per repo, audit what’s loaded, retire what you stopped using.
Please, please comment what you think!
Install it, run /executor:review on your last PR, and tell me what it found!
And stay tuned, because this is the only first little piece I share on my $1M quest.