Ein agiles KI-Produktteam für Claude Code.
Sie bringen die Idee. Ein Product Owner stellt sie in Frage, ein Engineering Manager plant sie, der Developer baut sie, ein Reviewer prüft den Diff, ein QA Tester klickt Ihre App im echten Browser durch, und ein Release Manager liefert aus — und nichts rückt in die nächste Phase, bevor das Gate davor grün ist.
Ein Befehl. Sechs Rollen. Jedes Gate gehört Ihnen.
/spark fährt ein Feature von der Idee bis zum Release und hält an jedem Gate an. Was dabei entsteht, liegt als Markdown in .spark/ in Ihrem Repository — lesbar, versioniert, ohne Werkzeug einsehbar.
So sieht ein Artefakt aus, wenn niemand es für die Webseite geschönt hat
Ein Auszug aus einem echten QA-Bericht in steamcore — wörtlich, ungekürzt in den Zellen, samt der Zeile, die nicht bestanden ist. Folgen Sie dem Link und Sie finden genau diese Zeilen wieder.
Nothing in this report rests on reading source and asserting it “should work” without a command backing it.
| Kriterium | Schritte | Erwartet | Beobachtet | Ergebnis |
|---|---|---|---|---|
| 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 |
Tabelle seitlich scrollbar
Die letzte Zeile ist der Punkt: Ohne angeschlossene Hardware verbucht der QA-Tester das Kriterium als not capturable — und eben nicht als bestanden.
Vollständigen Bericht auf GitHub lesen →Zwei echte, vollständige Beispiele zum Nachlesen
steamcore
ESP32 · C++ · 13 FeaturesEine Arcade-Konsole, von null mit aSPARK gebaut. Jedes Feature mit Spec → Plan → Review → QA → Release unter .spark/. Ohne Browser-Oberfläche — zeigt zugleich den deklarierten Ersatz-QA-Pfad.
highscore-system lesen →aSPARK selbst
Markdown-Plugin · Typ libraryaSPARK wird mit aSPARK gebaut. Der eigene .spark/-Ordner ist die Spur eines Library-Projekts — inklusive der Features, die ehrlich als teilweise bewiesen ausgeliefert wurden.
.spark/ ansehen →Core läuft allein. Alles andere ist optional.
Core hat keine Abhängigkeit auf ein Schwesterprodukt. Zwei Erweiterungen greifen heute in den Loop ein — guard setzt die Gates im Code durch, graph grenzt Review und QA ein. Fehlen sie, verhält sich der Loop exakt wie beschrieben: kein Fehler, keine Warnung. insights und policy laufen eigenständig, ci und memory sind geplant.
aSPARK Core
LiveProzess. Der deterministische Workflow Specify → Plan → Act → Review → Keep mit Quality-Gates und Traceability-IDs. Definiert, wie Software gebaut wird.
Produkt ansehen →aSPARK-guard
LiveIntegrität. Deterministische Gate-Durchsetzung außerhalb des Modells, dazu ein Hash-Ledger über jeden .spark/-Schreibvorgang. Sorgt dafür, dass die Gates halten — und dass keine Ausnahme unsichtbar bleibt.
Produkt ansehen →aSPARK-graph
LiveWissen. Ein deterministischer Engineering-Wissensgraph, der Stories, Tasks, Code, Tests und Releases verbindet. Weiß, was gebaut wurde.
Produkt ansehen →Drei Wege weiter.
Vom ersten Feature an ein ganzes Team.
Zwei Befehle in einer claude-Sitzung, Neustart, /spark. Kein Dienst, kein Konto, keine Datenbank — Core läuft in Ihrem Repository. Alles liegt offen auf GitHub.