Erste Schritte
Von null zum ersten Feature, das den kompletten SPARK-Loop durchlaufen hat. Alle Befehle stammen aus den Repositories der Produkte.
Claude Code
Der Agent, in dem aSPARK als Plugin läuft. claude muss im Terminal aufrufbar sein.
Git
Die Artefakte werden mit Ihrem Code versioniert — ohne Repository gibt es nichts zu versionieren.
Browser-Integration
Nur für /demo-day: Claude in Chrome, ein Playwright- oder ein Chrome-DevTools-MCP-Server. Ohne sie läuft alles andere trotzdem.
Der bequeme Weg führt über das eingebaute /plugin-Menü in einer interaktiven Claude-Code-Sitzung.
In einer interaktiven Sitzung
In Skripten und CI
Das /plugin-Menü gibt es nur in einer interaktiven Sitzung. Für Skripte, CI oder eine nicht-interaktive Shell tun die CLI-Entsprechungen genau dasselbe.
Lokal weiterentwickeln
Wer an aSPARK selbst arbeiten will, zeigt Claude Code auf einen lokalen Klon statt auf den Marketplace.
Jede Phase schreibt ihr Artefakt nach .spark/<feature>/ und prüft am Ende ihr Gate. Sie bleiben die entscheidende Instanz — der Loop hält an jedem Gate an.
Zuerst /charter. Auf einem leeren Repo stellt es eine Handvoll harter Produktfragen und bietet am Ende /story-time mit dem ersten Schnitt an; auf einem bestehenden liest es den Code und schreibt auf, was es gefunden hat — einmal, zum Korrigieren. Danach muss das Team nicht bei jedem Feature neu herleiten, was Ihr Projekt ist. Überspringen geht, aber /spark und /next-steps schicken Sie zuerst hierher.
Noch keine Idee? /next-steps sichtet den aktuellen Projektstand und schlägt das nächste Feature vor.
So sieht ein fertiger Durchlauf aus: steamcore · highscore-system — Spec, Plan, Review, QA und Release eines echten Features, zum Nachlesen.
Alles am Stück
/spark fährt denselben Loop in einem Rutsch, zeigt vor jedem Übergang das Artefakt und hält am Gate. Nach schweren Phasen weist es darauf hin, dass Sie /clear machen und mit /spark wieder einsteigen können — die Artefakte auf der Platte sind der Zustand.
Cores Gates sind Bitten an ein Modell. aspark-guard macht daraus Prüfungen außerhalb des Modells — aus demselben Marketplace, ein Befehl, dann neu starten.
Braucht Python 3.11+ und POSIX (macOS, Linux). In jedem Projekt ohne .spark/-Verzeichnis bleibt es still, und es scheitert bewusst offen — ein Guard, der im Zweifel blockiert, bringt Leute nur dazu, ihn abzuschalten.
Die Regeln gegen die eigene Historie prüfen
Spielt alle drei Gate-Regeln read-only über die Artefakte nach, die schon auf der Platte liegen. In einem Projekt, dessen Features saubergelaufen sind, gibt es nur eine Zählung aus — jede Zeile darüber hinaus ist dort ein Fehlalarm.
Liegt aspark-graph im Projekt, nutzen /sprint-plan, /peer-review und /demo-day es zur Eingrenzung. Fehlt es, ändert sich nichts — kein Fehler, keine Warnung.
Der Graph ist nicht vorwärtskompatibel über Versionen hinweg: nach einem Upgrade neu bauen. Mit uvx läuft immer die zuletzt veröffentlichte Version, ein getrennter Update-Schritt entfällt.
Eine Policy ist kein Paket, das man installiert — sie ist ein Repository, das man einhängt. Sie liegt als Submodul unter .spark/policy und gehört Ihrem Unternehmen.
Ehrlich zum Stand: Format, Schemas und Packs stehen — die maschinelle Durchsetzung (validate-CLI und /charter-Bindung) fehlt noch. Die Policy ist heute lesbar, vererbbar und auditierbar, wird aber noch nicht automatisch herangezogen.
Eine minimale policy.yaml
Wie es weitergeht
Die Produktseiten erklären, was hinter jedem Teil steckt — und die Roadmap, was noch kommt.