Open Source

aSPARK macht aus Claude Code ein Werkzeug mit Prozess: ein Produktteam aus Product Owner, Designer, Engineering Manager, Reviewer, QA-Tester und Release Manager. Jedes Feature läuft durch den SPARK-Loop und muss an jedem Gate bestehen, bevor es weitergeht.

Entscheidungen verschwinden nicht im Chatverlauf, sondern landen als Artefakte im Projekt — spec.md, plan.md, review.md, qa.md. Stabile IDs für User Stories, Akzeptanzkriterien und nicht-funktionale Anforderungen halten alle Phasen nachvollziehbar miteinander verbunden. Getestet wird nicht behauptet, sondern im echten Browser.

1. S Specify Idee schärfen, User Stories und Akzeptanzkriterien festlegen
2. P Plan Architekturentscheidung treffen, Aufgaben schneiden
3. A Act Das Inkrement strikt nach Plan bauen
4. R Review Code-Review und QA im echten Browser
5. K Keep Release, Dokumentation und Learnings festhalten

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

aspark-graph liest ein Repository — den Quellcode und den aSPARK-Delivery-Pfad unter .spark/ mit Specs, Plänen, Reviews und QA-Berichten — und baut daraus einen einzigen abfragbaren Graphen, bereitgestellt über CLI und MCP-Server. Damit lassen sich zwei Fragen ohne Grepping beantworten: Welcher Code implementiert diese User Story? Und welche Stories liegen im Blast Radius einer Änderung?

Der Graph ist deterministisch — tree-sitter plus deklarierte Artefakt-Verknüpfungen, kein LLM, kein Netzwerk. Zwei Builds eines unveränderten Repositories erzeugen byte-identische Ergebnisse. Und er ist bewusst wegwerfbar: ein jederzeit neu baubares Read Model, niemals die Quelle der Wahrheit.

pip install aspark-graph
claude mcp add aspark-graph -- uvx aspark-graph serve

aSPARK-policy macht aus Architekturrichtlinien, Secure-Coding-Standards, Namenskonventionen und Review-Checklisten eine maschinenlesbare Policy-Schicht. Markdown-Dateien erklären die Standards, eine policy.yaml aktiviert sie, und jeder aSPARK-Agent liest dieselbe Policy — ohne duplizierte Prompts, ohne angepasste Agenten.

Eine Policy wird nicht installiert, sondern eingebunden: Die Organisation pflegt ihre Standards im eigenen Repository, jedes Projekt hängt es als Git-Submodul unter .spark/policy ein. Stand heute: ein dokumentiertes Format, ein getestetes JSON Schema, ein installierbares Python-Paket und acht Katalog-Packs. Die Durchsetzung über CLI und Facilitator-Anbindung steht noch aus — das Projekt ist in früher Entwicklung.

Die meisten Eleventy-Starter behandeln Mehrsprachigkeit als Nachschlagetabelle für Button-Beschriftungen — das ist der einfache Teil. Schwierig wird es, wenn jemand die Sprache auf einer beliebigen Seite wechselt: auf einer Tag-Seite, auf Seite 4 des Blogs, in der Datenschutzerklärung. eleventy-rosetta beantwortet diese Frage überall, mit übersetzten Routen (/de/impressum/, /en/legal/ und /fr/mentions-legales/ sind dieselbe Seite), übersetzten Tags und einem Sprachwechsler, der sich lieber deaktiviert als auf einen 404 zu verlinken.

Deutsch, Englisch und Französisch ab Werk, eigenes CSS ohne Framework und zur Laufzeit keine externen Dienste: Die Volltextsuche über Pagefind entsteht beim Deploy, Bilder in AVIF und WebP beim Build. Das Paket hat zwei Hälften — das Plugin bleibt über npm aktualisierbar, eleventy-rosetta init legt Layouts, CSS, Demo-Inhalte und Konfiguration einmalig ins Projekt und hält sich danach heraus. Eine weitere Sprache braucht keine Registry, sondern ein neues Verzeichnis unter _data/i18n/. Entstanden ist das Theme aus dem Code dieser Website.

npx eleventy-rosetta init
npm install && npm start