Andreas Lottes released aSPARK, a Claude Code plugin that orchestrates an entire software team through a gated pipeline where every feature must clear a quality checkpoint before advancing. The project is open source under MIT and runs entirely as Markdown files in your repository.
A six-person AI team with one command
The plugin assigns distinct roles: Product Owner, Designer, Engineering Manager, Developer, Reviewer, QA Tester, and Release Manager. A single command, /spark, triggers the full sequence. Each role produces an artifact, and the pipeline halts until you approve a gate. You remain the decision maker at every stage.
The Product Owner challenges the idea and writes acceptance criteria. The Designer flags usability and accessibility concerns. The Engineering Manager decides architecture and breaks work into ordered tasks. The Developer builds task by task, constrained to the plan. The Reviewer audits the diff with a staff-engineer mindset. The QA Tester opens a real browser and verifies every acceptance criterion against the running app. The Release Manager handles changelog, tagging, and PR creation.
Requirements carry stable identifiers from the spec through to QA. The plan cites which acceptance criterion each task covers. The review traces each Must-have criterion to code. QA verifies it under the same identifier. Nothing silently drops out of the chain.
What lands in your repository
All artifacts live in a .spark/ directory. A constitution.md file captures project-wide principles, set once with /charter. Each feature gets its own subfolder containing spec.md, plan.md, review.md, qa.md, and release.md. The constitution can define project type (website, web app, API, CLI, library) and what it does with data (auth, payments, PII, database, multiple languages, accessibility). That triggers specific lenses: a public website gets SEO and Core Web Vitals checks in QA, an API gets error-envelope and versioning in review, a payments project gets security scrutiny through every phase.
Nine lenses ship today. Adding a new one means creating a file in the lenses/ directory. Without a constitution, no lens activates.
The gating mechanism
Five phases form the pipeline: Specify, Plan, Act, Review, and Keep. A phase cannot advance until the previous gate clears. If QA or review finds a blocking issue, the work returns to the Developer and the phase re-runs. After three failed rounds of the same phase, the loop stops and asks whether the spec or the plan is wrong rather than grinding forward.
The artifacts on disk serve as state. You can clear the context after a heavy phase and resume with /spark, picking up exactly where things stand.
Real numbers from real usage
Lottes ran the loop on 77 features across three machines, with 429 role-agent runs and 377 human gate decisions. Every figure is derivable from the committed reports in docs/reports/ using standard library Python.
One complete run on a todo filter bar feature took 47 minutes, covered 29 acceptance criteria, and consumed 42,307,448 tokens. At Opus 5 list prices, that comes to $35.52. The breakdown: 96.3% of those tokens were cache reads. Without prompt caching, the same loop would have cost $217.37. The per-role breakdown and what that number does not capture are documented in the cost analysis file.
Two complete examples exist today. Steamcore, an ESP32 arcade console, has 13 features each with a full spec-through-release trail. The aSPARK repository itself is built with aSPARK, so its own .spark/ folder demonstrates the workflow on a library-type project.
Installing and starting
The only requirements are Claude Code and Git. Browser testing needs a browser integration (Claude in Chrome, a Playwright MCP server, or Chrome DevTools MCP), unless the project has no browser surface and /charter declares a substitute QA method.
Installation takes two commands in an interactive Claude session: one to add the marketplace source, one to install the plugin. Then restart Claude Code and /plugin should list aspark as enabled. The same two commands work from a plain shell or CI.
Start with /charter on a new or existing project. On an empty repo it asks product questions and ends by suggesting /story-time with the first slice. On an existing codebase it reads the repo and writes down what it found for you to correct.
Companion tools
aspark-guard enforces gates in code, outside the model. It denies .spark/ writes that violate phase preconditions and records every write with its hash. aspark-graph builds a deterministic graph over artifacts and code, used by /sprint-plan, /peer-review, and /demo-day to scope work. Both are optional; the core loop runs without them and does not mention their absence.
The loop has not been run end-to-end on a real project outside the author's own work. Lottes notes that a field report from someone using it on their codebase would be worth more than a patch, especially when things go badly.