An agile AI product team for Claude Code.
You bring the idea. A Product Owner challenges it, an Engineering Manager plans it, the Developer builds it, a Reviewer audits the diff, a QA Tester clicks through your app in a real browser, and a Release Manager ships it — and nothing moves to the next phase until the previous gate is green.
One command. Six roles. Every gate is yours.
/spark takes a feature from idea to release and stops at every gate. What it produces sits as Markdown in .spark/ inside your repository — readable, versioned, no tool needed.
What an artifact looks like when nobody polished it for the website
An excerpt from a real QA report in steamcore — verbatim, cells uncut, including the row that did not pass. Follow the link and you will find these exact lines.
Nothing in this report rests on reading source and asserting it “should work” without a command backing it.
| Criterion | Steps | Expected | Observed | Verdict |
|---|---|---|---|---|
| AC-1.2 | Ran highscore_store_survives_reconstruction_over_the_same_backend |
fresh HighscoreStore over same backend bytes reads back identical table |
1 passed, 0 failed |
✅ pass |
| AC-2.5 | Ran initials_entry_replay_is_byte_identical_every_tick |
same input sequence twice → byte-identical letter/cursor sequence | 1 passed, 0 failed |
✅ pass |
| NFR-2 | Ran make lint sub-rule (b) over engine+test+bench file set |
zero dynamic allocation anywhere in the delivered code/tests | rule clean, make lint OK |
✅ pass |
| AC-1.5Should, hardware-gated | Checked myself: ls /dev/cu.usbmodem* (no match), system_profiler SPUSBDataType (no serial/ESP device) |
real power-cycle survival on physical board | no board attached this session | ⚠️ not capturable — never claimed as passed |
Table scrolls sideways
The last row is the point: with no board attached, the QA Tester records the criterion as not capturable — rather than as passed.
Read the full report on GitHub →Two real, complete examples you can read today
steamcore
ESP32 · C++ · 13 featuresAn arcade console built from scratch with aSPARK. Every feature with its spec → plan → review → QA → release trail under .spark/. No browser surface — so it also shows the declared substitute-QA path.
Read highscore-system →aSPARK itself
Markdown plugin · type libraryaSPARK is built with aSPARK. Its own .spark/ folder is the trail of a library-type project — including the features honestly shipped as partially proven.
Browse .spark/ →Core runs on its own. Everything else is optional.
Core has no dependency on any sibling. Two extensions hook into the loop today — guard enforces the gates in code, graph scopes review and QA. Absent, the loop behaves exactly as described: no error, no warning. insights and policy run standalone; ci and memory are planned.
aSPARK Core
ShippedProcess. The deterministic Specify → Plan → Act → Review → Keep workflow with quality gates and traceability IDs. Defines how software is built.
View product →aSPARK-guard
ShippedIntegrity. Deterministic gate enforcement outside the model, plus a hash ledger over every .spark/ write. Makes the gates hold — and keeps no override invisible.
View product →aSPARK-graph
ShippedKnowledge. A deterministic engineering knowledge graph connecting stories, tasks, code, tests and releases. Knows what has been built.
View product →Three ways onward.
A whole team, from the first feature on.
Two commands in a claude session, a restart, /spark. No service, no account, no database — Core runs inside your repository. Everything is open on GitHub.