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.

Tokibot ist ein kleines E-Paper-Gerät, dessen Stimmung widerspiegelt, was deine Coding-Agenten gerade machen. Er verfolgt mehrere Sessions gleichzeitig, zeigt die, die dich am dringendsten braucht, und zählt, was arbeitet, wartet oder fertig ist. Bei Claude Code zeigt er zusätzlich das 5-Stunden- und 7-Tage-Budget.

Er läuft auf einem eigenen, schlanken Buildroot-Image mit schreibgeschütztem Dateisystem. Nur Metadaten verlassen deinen Computer, Prompts, Code und Antworten bleiben lokal. Ein optionales Relay lässt auch Cloud-Agenten das Gerät über jedes WLAN erreichen. Tokibot ist noch in Entwicklung.

BRASS-01 ist eine selbst gebaute Mini-Retro-Konsole auf einem ESP32-S3, mit eigener Game Engine (SteamCore) und eigenen Spielen. Die Grafik ist bewusst monochrom orange auf schwarz und läuft in einer niedrigen virtuellen Auflösung, die ganzzahlig auf das Display skaliert wird. Das Ziel ist keine Emulation alter Konsolen, sondern eine Plattform, die es 1983 in einer Steampunk-Zeitlinie hätte geben können. Das erste Spiel ist Galactic Invasion.

Jedes Feature ist mit aSPARK entstanden: 13 Features, jedes mit Spec, Plan, Review, QA und Release unter .spark/ — der vollständige, öffentlich lesbare Delivery-Pfad eines echten Projekts. Weil die Konsole keine Browser-Oberfläche hat, läuft die QA über eine in der Constitution festgelegte Ersatzmethode: Host-Unit-Tests, Framebuffer-Dumps und serielle Mitschnitte.

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