orchestrator-supaconductor: one slash command and a loop with hard ceilings

One command, and six automatic steps behind it

The entry point is a slash command with a plain English request:

/orchestrator-supaconductor:go Add user authentication with Google OAuth

What follows is described as automatic, in six steps. It writes a detailed specification. It creates an implementation plan with task dependencies. It executes each task, in parallel when possible. It checks the work with specialised evaluators. It fixes any issues it finds. And it marks the work complete when everything passes.

The framing in the page contrasts this with prompting a coding agent directly, where you review manually, re-prompt, and fix what it missed. The claim is not that the agent becomes smarter, it is that the sequence around it becomes fixed.

That is the honest version of what an orchestration layer does. The intelligence is still the host agent's; what changes is that specification, planning, execution, evaluation and repair all happen without you re-issuing a prompt between stages.

The examples show the range of requests: adding a Stripe payment integration with webhooks, fixing a login bug where users get logged out after a refresh, building a dashboard with real-time analytics charts, and refactoring the database layer to use connection pooling.

Five fix cycles and three plan revisions, then it stops

The core mechanism is called the Evaluate-Loop, and the table gives six steps with their ceilings attached.

Plan breaks the goal into tasks with a dependency graph. Evaluate Plan checks for scope issues, overlap with other work, and feasibility. Execute writes code, runs tests and tracks progress, in parallel where possible. Evaluate Execution sends the result to specialised checkers covering UI/UX, code quality, integrations and business logic. Fix addresses failures and loops back to evaluation. Complete marks the track done when everything passes.

The ceilings are the part that makes this a design rather than a slogan. Fix runs up to five fix cycles. A plan may be revised up to three times. After that the loop stops.

That bound is what stops an unbounded self-repair loop, where each fix introduces a new failure that the next fix tries to solve. A system that gives up after five attempts and reports is more useful than one that keeps going, because a human can look at a stalled track and tell whether the problem is the code or the request.

The other stopping condition is stated as simply: the loop runs fully automated, and it stops when the work passes all quality checks or when it needs your input.

Four evaluators, five directors, four lead engineers

The component table is the clearest statement of scope, and the counts are specific.

Thirty-six commands are the slash commands you type to control everything. Thirty-nine skills are specialised knowledge modules that activate when needed rather than being invoked by hand. Fifteen agents are autonomous workers handling planning, coding and evaluation.

Then the three review roles. Four evaluators are quality checkers for UI/UX, code quality, integrations and business logic, which is one per category and matches the Evaluate Execution step exactly. Five members make up a Board of Directors described as virtual executives who deliberate on major decisions. Four Lead Engineers cover architecture, product, tech and QA.

Thirty-six commands and thirty-nine skills for fifteen agents is a lot of surface for a plugin, and the ratio is worth thinking about. The skills are the part that scales: knowledge modules that activate when needed do not have to be re-read in every session, which is what keeps the command count manageable.

The project also bundles Superpowers version 4.3.0 under the MIT licence, described as working out of the box with zero setup.

One host gets a plugin, the other five get a build step

Installation splits by host, and the two paths are not equivalent.

Claude Code is the native path, using the plugin marketplace commands:

/plugin marketplace add Ibrahim-3d/orchestrator-supaconductor
/plugin install orchestrator-supaconductor@ibrahim-plugins

Updates later go through the plugin CLI rather than a reinstall:

claude plugin marketplace update ibrahim-plugins
claude plugin update orchestrator-supaconductor@ibrahim-plugins

Every other host, meaning Codex and the ChatGPT desktop, Cursor, Google Antigravity, Windsurf and GitHub Copilot, goes through a clone and a generator script:

git clone https://github.com/Ibrahim-3d/orchestrator-supaconductor.git
cd orchestrator-supaconductor
python3 scripts/build-platform-adapters.py

That script writes packages under dist/platforms/, one directory per host, and published releases also attach ready-made ZIP packages so you do not have to run Python at all.

The structural consequence is that the canonical source is one repository and the adapters are build output. Anything you change in a generated directory will be overwritten by the next build, which is the right arrangement for a plugin that targets six hosts from one definition, and the reason the platform support document exists to spell out the capability differences.

setup writes a conductor folder into your repository

There is one preparatory command per project, run once:

/orchestrator-supaconductor:setup

It is interactive rather than declarative, and it does four things: it analyses your existing codebase, or starts fresh for a new project; it helps you define the product vision and the tech stack; it creates a conductor/ folder in your project to track all work; and it generates an initial development sprint with ready-to-execute tracks.

The conductor/ folder is the part with consequences. The system keeps its plan, its tracks and its progress inside your repository, which means the state of the work is reviewable in a diff and survives a session ending. It also means a directory appears in your project that you did not write and that a reviewer will ask about.

That is a reasonable trade for a tool whose entire value is resumable long-running work. Without a file, resuming after a restart would require the agent to reconstruct its own plan from a conversation.

The vision and tech stack questions matter too, because the plan is generated from them. A generic scaffold produces generic tasks.

A bare :go resumes, and :status tells you where things stand

The command surface for day-to-day use is two commands.

Status reports the state of the work: all your active tracks, what step each one is on, and what is completed. It is the answer to the question you will ask most often, which is what happened while you were away.

Resuming needs no argument. If a session ends before a track completes, running the bare command picks up exactly where it left off. That is a small design detail with a large effect on trust: an orchestration tool that forgets where it was after a restart is a tool you have to babysit, which is the problem it was built to solve.

Between them, the pair supports the failure case that matters most in practice. An agent session will end, and the question will be whether the plan survives. Here it is stored in conductor/ and the bare command reads it back.

The one thing not visible in what is readable here is what happens when the loop reaches its fix ceiling or its plan revision limit: whether status reports a stalled track, and whether go starts a new track or refuses.

Parallelism is claimed in wall-clock terms

When tasks do not depend on each other, they run simultaneously, and the page puts a number on it: a feature with six tasks might only take as long as three, because independent tasks run in parallel.

The dependency graph from the Plan step is what makes that possible, and it is also what stops it becoming a race. Two tasks that both write the same file must be ordered, so the graph is not an optimisation detail, it is the correctness boundary of the whole system.

That places the weight on the Evaluate Plan step, which checks for scope issues, overlap with other work and feasibility. Overlap is the failure that matters here, because two independent-looking tasks that touch the same module will both pass their own checks and still conflict.

Two working modes are described, and the second one is cut off. The default is agentic, fully autonomous, making all its own decisions, aimed at experienced users who trust the system. The alternative is human-in-the-loop, which pauses at key points; the sentence describing where it pauses is not readable here.

An AGPL plugin that bundles an MIT skill pack

The licensing is layered, and the repository is arranged to reflect that.

The project itself is AGPL-3.0, and the bundled Superpowers pack version 4.3.0 is MIT. Alongside the main LICENSE file there is a LICENSES/ directory, which is the conventional way to keep a second licence visible rather than buried in a notice.

For a plugin that runs inside someone else's coding agent, AGPL is a heavier obligation than most tooling of this kind ships under, and anyone redistributing it into a product has to think about that. The bundled MIT component does not change the outer terms.

The release machinery is automated rather than manual: a release-please manifest and its configuration sit at the top level, which is how three releases landed on 27 September 2026, v3.7.0, v3.7.1 and v3.8.0, the last of them carrying the same timestamp as the push.

The plugin manifests for two hosts are also committed, .claude-plugin/ and .codex-plugin/ with a plugin.json, alongside agents/, commands/, skills/, hooks/, lib/ and scripts/.

One small sign of a hand-built repository: a top-level documentation file has documentaion misspelled in its name, which is the sort of thing that survives because nothing links to it by name.

Editorial conclusion

SupaConductor is for someone who already trusts an agent on their codebase and wants the review discipline written into the loop rather than supplied by hand. The loop's real contribution is its ceilings, five fix cycles and three plan revisions, because an unbounded self-repair loop is how an agent spends an afternoon undoing its own work. Two things to check before adopting it. The Claude Code install is a native plugin while every other host goes through a generated adapter build, so capability differences between hosts are the thing to read in the platform support document. And the licensing is layered, AGPL for this project with an MIT skill pack bundled inside.

Frequently asked questions

Official sources

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