SupaConductor: putting a plan, four evaluators and a board behind Claude Code

What one command sets in motion

You type a slash command with a plain-English goal and the plugin takes it from there. The README's example is /orchestrator-supaconductor:go Add user authentication with Google OAuth, and it lists six things that follow: a detailed specification, an implementation plan with task dependencies, execution of each task in parallel where possible, checks by specialised evaluators, fixes for whatever those evaluators find, and a completion mark once everything passes.

The pitch is absence of supervision. No re-prompting, no manually reviewing each step, no deciding when to stop. Whether that holds is a different question, and the README's own limits, five fix cycles and three plan revisions, suggest the authors know it sometimes does not.

The Evaluate-Loop

Every unit of work runs through a cycle the README calls the Evaluate-Loop, with six documented stages. Plan breaks the goal into tasks and builds a dependency graph. Evaluate Plan checks for scope problems, overlap with other work in flight, and feasibility. Execute writes code, runs tests and tracks progress, in parallel where the graph allows.

Evaluate Execution hands the result to four checkers covering UI and UX, code quality, integrations, and business logic. Fix addresses failures and loops back to evaluation. Complete marks the track done when all checks pass.

Two bounds matter. The loop allows up to five fix cycles, and up to three plan revisions, and version 3.7.0 added a plan revision guard that stops runaway planning by tracking rejections and calling the work done with warnings after three.

What ships in the plugin

The README counts its contents in a table: 36 slash commands, 39 skills described as knowledge modules that activate when needed, 15 autonomous agents for planning, coding and evaluation, 4 evaluators, 5 members of a Board of Directors, and 4 lead engineers covering architecture, product, tech and QA.

The Board is the unusual piece. It is a set of virtual executives that deliberate on major decisions, and v3.7.0 changed how often they are used. Routine tracks now take a fast path: a single Opus call covering all five lenses in one pass, at roughly one tenth the cost of full multi-agent deliberation. The full board is reserved for high-stakes decisions, which the README lists as production deploys, security architecture, breaking API changes and data-loss migrations.

The plugin also bundles Superpowers v4.3.0 from obra/superpowers, under MIT, described as working out of the box with zero setup.

Installing it and running a first track

Three install paths are documented. The marketplace path is one command typed into Claude Code:

/install Ibrahim-3d/orchestrator-supaconductor

The clone path puts the repository where Claude Code looks for plugins:

git clone https://github.com/Ibrahim-3d/orchestrator-supaconductor.git ~/.claude/plugins/orchestrator-supaconductor

The third option is downloading a release archive and extracting it into that same directory. To verify the install, start a new Claude Code session and type /orchestrator-supaconductor:, which should list the commands. The README says seeing /orchestrator-supaconductor:go means you are set.

A first run has two commands after install. /orchestrator-supaconductor:setup walks through the project once, analysing an existing codebase, helping define product vision and tech stack, creating a conductor/ folder to track work and generating an opening sprint. Then a goal goes to /orchestrator-supaconductor:go, and /orchestrator-supaconductor:status shows which tracks are active and what step each is on.

What v3.7.0 fixed

The changelog for 3.7.0 reads like a list of failure modes found in use, which is informative about how the system behaves under load.

Execution state reconciliation now treats the checkboxes in plan.md as the source of truth when a session resumes, so a crash no longer causes completed tasks to be redone. Atomic file locks use fcntl OS-level locking on a dedicated mutex file, closing a race where two parallel workers could take the same lock. Bounded knowledge injection caps the brief loaded before planning at 500 tokens, keeping the top three relevant patterns and errors, so context stops growing as a project's knowledge base accumulates.

The Board fast path and the plan revision guard are the other two, both aimed at cost and at loops that never terminate.

Where this is the wrong choice

The cost is the first concern, and the fast path is the evidence. A full board deliberation was expensive enough that the authors built a single-call alternative at one tenth the price, which tells you what a long track with several high-stakes decisions costs in tokens.

Autonomy is the second. Up to five fix cycles and three plan revisions means a single command can do a lot of work before it stops, and the plan revision guard ends a stuck plan with warnings rather than with a correct plan. Anyone running this against a shared repository should know that the loop writes and tests code without asking.

There is also a maturity signal in the repository itself: README says version 3.7.0 and the last push was on 2026-04-08.

The licence question

This needs its own section because the repository contradicts itself. The README displays an MIT badge and links to a LICENSE file on a branch named main, while GitHub reports the licence as AGPL-3.0 and the file listing includes a LICENSES/ directory alongside LICENSE. The default branch in the data is master, so the badge may be pointing at a different tree than the one GitHub inspected.

The two licences are not interchangeable. AGPL-3.0 carries an obligation to make source available for modified versions offered over a network, while MIT does not, so which one governs changes what you may do with a fork. None of this is legal advice; the practical step is to ask the maintainer to reconcile the badge, the LICENSE file and the LICENSES/ directory before building anything on top.

Superpowers as the lighter path

The plugin bundles Superpowers v4.3.0, which is also a standalone project under MIT. That is the natural alternative, and the difference is scope. Superpowers supplies skills, the knowledge modules that activate when a task needs them. SupaConductor supplies the orchestration around them: the planning cycle, the dependency graph, the parallel workers, the evaluators and the board.

If what you want is better-informed single-agent work, the skills alone are a smaller system with no planning loop, no parallel execution and no evaluator passes, and no multi-agent token cost. Adopt the orchestration only if you want the work to continue without you watching it, since that is the only thing the extra machinery buys.

Editorial conclusion

SupaConductor suits a Claude Code user who wants a feature request carried from specification to evaluated result without standing over it, and who is comfortable with the token bill that 15 agents and a board can run up. It is the wrong fit if you want to review each step, or if your licence review cannot accept an AGPL-3.0 component with an ambiguous MIT badge. Before the first real track, run /orchestrator-supaconductor:setup on a disposable copy of the project and watch what the conductor/ folder records, because that folder is where the plan and the fix history land.

Frequently asked questions

Official sources

1. Ibrahim-3d/orchestrator-supaconductor on GitHub
2. Issues
3. License: AGPL-3.0
4. README