Der erste Durchlauf: mit /charter anfangen, nicht mit dem Feature

aSPARK ist seit v0.11.0 an einer Stelle deutlich einfacher geworden: Es gibt jetzt einen klaren Startpunkt. Wer früher mit /spark oder /next-steps auf einem Projekt ohne Constitution begann, wurde von beiden auf das jeweils andere verwiesen. Heute führen beide zuerst zu /charter — und /charter weiß, was zu tun ist, egal ob das Repository leer ist oder seit zwei Jahren wächst.

Installation: zwei Befehle

In einer laufenden claude-Sitzung:

/plugin marketplace add a-lottes/aSPARK
/plugin install aspark@aspark

Danach Claude Code neu starten, denn Plugins werden erst nach einem Neustart aktiv. Ein /plugin zeigt anschließend aspark als installiert und aktiviert. Es gibt keinen Dienst, kein Konto und keine Datenbank — aSPARK ist Markdown, das in Ihrem Repository arbeitet.

Schritt 1: /charter, einmal pro Projekt

/charter schreibt die Constitution: die stehenden Regeln, die jede Phase jedes Features erbt. Das Ceremony verhält sich unterschiedlich, je nachdem was es vorfindet.

Auf einem leeren Repository stellt es eine kurze Reihe harter Produktfragen. Für wen ist das? Was tun diese Menschen heute ohne Ihr Produkt? Was ist die kleinste Version, die schon hilft? Woran merken Sie, dass es funktioniert? Welcher Stack, welche harten Einschränkungen? Am Ende steht ein Vorschlag für die Constitution und für den ersten Schnitt — beides zur Freigabe, nichts läuft ungefragt los.

Auf einem Projekt mit Code liest es stattdessen, was schon da ist: README, ein vorhandenes CLAUDE.md, bestehende Specs. Daraus entsteht ein begrenzter Projektüberblick — Zielgruppe, Stack, wie man es startet, Konventionen, bekannte Schwachstellen — den Sie einmal korrigieren. Danach müssen Product Owner und Engineering Manager das System nicht bei jedem Feature neu herleiten.

Drei Angaben lohnen besondere Aufmerksamkeit, weil sie den Rest des Loops prägen:

Projekttyp und Merkmale. Daraus ergeben sich die aktiven Lenses. Ein öffentlicher website bekommt SEO-Checks, eine api bekommt Fehler-Envelope und Versionierung, ein Projekt mit Zahlungsverkehr bekommt die Security-Lens durch alle Phasen. Wichtig: Ohne Constitution ist keine Lens aktiv. Die Constitution ist die einzige Stelle, an der eine Lens eingeschaltet wird.
Qualitätslatte. Was in §4 steht, muss keine Spec mehr wiederholen. Gibt es kein Testframework und soll auch keines entstehen, schreiben Sie das hin — dann baut niemand eines.
QA-Methode. Hat Ihr Projekt keine Oberfläche, die ein Browser bedienen kann, deklarieren Sie hier die Ersatzmethode. Sonst fragt jedes Feature erneut danach.

Schritt 2: das erste Feature

Entweder Phase für Phase oder am Stück:

/spark Eine Filterleiste über der Todo-Liste mit All, Active, Done …

/spark fährt Specify, Plan, Act, Review und Keep und hält an jedem Gate an. Sie sehen jeweils das Artefakt und entscheiden. Das ist kein Formalismus, sondern der Punkt der Übung: Die Agenten entwerfen, prüfen und empfehlen — freigegeben wird von Ihnen.

Was an den Gates wirklich zur Entscheidung steht:

Gate	Ihre Frage
Spec	Ist das das richtige Feature, und sind die Kriterien prüfbar?
Plan	Trägt der Ansatz? Hier ist Ablehnen noch billig, danach steht Code.
Review	Findings verstanden: jetzt beheben, oder bewusst annehmen?
QA	Wurde jedes Akzeptanzkriterium wirklich verifiziert?
Release	Geht das raus? Ohne Ihr ausdrückliches Ja passiert nichts.

Zwischendurch bietet /spark nach schweren Phasen an, /clear zu machen und wieder einzusteigen. Nehmen Sie das an. Die Artefakte auf der Platte sind der Zustand; ein frischer Kontext nimmt den Loop genau dort wieder auf, ohne alles mitzuschleppen, was die letzte Phase gelesen hat.

Schritt 3: optional erweitern

Core läuft allein vollständig. Zwei Erweiterungen greifen in den Loop ein, wenn Sie sie installieren:

/plugin install aspark-guard@aspark

aspark-guard verlegt die Gates aus dem Prompt in eine Prüfung außerhalb des Modells und führt ein Hash-Ledger über jeden Schreibvorgang unter .spark/. aspark-graph (pip install aspark-graph) grenzt Plan, Review und QA auf die Dateien ein, um die es geht. Fehlen beide, verhält sich der Loop exakt wie beschrieben — kein Fehler, keine Warnung.

Was Sie nach der ersten Stunde haben

Ein Feature, das durch fünf Gates gegangen ist, und einen Ordner .spark/, den Sie lesen, diffen und committen können: Spec mit Stories und Akzeptanzkriterien, Plan mit Tasks, Review mit Findings, QA-Bericht mit jedem geprüften Kriterium, Release-Notiz mit den Lehren.

Und eine Constitution, die Sie nie wieder erklären müssen.

Wie so ein Durchlauf in der Praxis aussieht, zeigt das Demo-Video auf der Startseite: 47 Minuten echte Session, auf 100 Sekunden geschnitten.