Wie ein OSS-Tool in 9 Tagen reift: session-orchestrator im Maschinenraum

TL;DR

session-orchestrator ist ein MIT-lizenziertes Open-Source-Tool, das ad-hoc-KI-Sessions in einen wiederholbaren Loop mit Prüf-Gates verwandelt: /plan über /session und /go bis /close und /evolve. Ich nutze es jeden Tag an meinen eigenen Projekten, und genau diese Eigennutzung treibt seine Reifung. In einem Zeitfenster von 9 Tagen haben 18 Sessions das Tool deutlich weitergebracht: stark gewachsene Testabdeckung, vier unterstützte Runtimes, ein Bündel an Hardening-Patterns. Beim web3 hub vienna Meetup am 10.06.2026 habe ich es vor vollem Saal live gezeigt. Dieser Artikel erklärt, wie der Loop funktioniert und warum tägliche Eigennutzung die schnellste Reifungskraft für ein Werkzeug ist.

Das Problem: KI-Agenten ohne Verfahren driften

Wer mit einem KI-Coding-Agenten an einem echten Projekt arbeitet, kennt das Muster: Die ersten paar Aufgaben gehen rasend schnell, dann beginnt der Agent zu driften. Er erfindet Funktionen, die es nicht gibt. Er übernimmt Patterns, die vor drei Sessions abgelöst wurden. Er macht denselben Fehler wie letzte Woche, weil er sich an nichts erinnert. Mehr über die Mechanik dieses Driftens und wie ein gutes Harness ihn auffängt, habe ich in Harness Design: Wie man KI-Coding-Agenten produktiv hält beschrieben.

Die naheliegende Reaktion ist, schneller zu prompten. Die wirksame Reaktion ist ein Verfahren. Genau das ist session-orchestrator: kein Ersatz für den Coding-Agenten, sondern eine Schicht darüber, die jede Session in fünf typisierte Wellen mit Prüf-Gates zwischen ihnen zerlegt. Das Tool ist ein Claude-Code-Plugin, MIT-lizenziert und öffentlich unter github.com/Kanevry/session-orchestrator. Es ist kein Anthropic-Produkt, sondern ein Community-Plugin für Solo-Entwickler und kleine Teams.

Es geht hier um ein Tool, das ich selbst täglich an meinen eigenen Repositories einsetze, und das jeder kostenlos installieren und nachlesen kann. Jede Zeile ist Klartext-Markdown plus eine dünne Node-Laufzeit. Wenn etwas schiefläuft, kann man jede Datei lesen und sehen, was passiert ist.

Der Lifecycle: /plan, /session, /go, /close, /evolve

Das Kernverfahren ist eine Abfolge von fünf Slash-Commands. Sie bilden den Loop, der eine ad-hoc-Session in einen wiederholbaren Ablauf verwandelt:

/plan feature     # optional: erst klären, WAS gebaut wird (PRD, Anforderungen)
/session deep     # Recherche + Q&A, dann Wellen-Plan
/go               # 5 typisierte Wellen mit Prüf-Gates dazwischen
/close            # verifiziert jede Aufgabe, committet sauber, mirror auf GitHub
/evolve analyze   # extrahiert Muster aus der Session-Historie als Lernschleife

Jeder Befehl hat eine klar umrissene Aufgabe:

• /plan. Läuft vor einer Session, wenn das WAS noch unklar ist. Erzeugt ein PRD oder eine Retrospektive. Optional: Wer schon klare Issues hat, springt direkt zu /session.
• /session. Analysiert den Git-Stand, offene Issues, letzte Commits, SSOT-Frische und das Gedächtnis vorheriger Sessions. Das Ergebnis ist eine strukturierte Übersicht mit einer Empfehlung, kein Wust an Rohdaten. Danach einigt man sich über einen Picker auf den Scope.
• /go. Führt aus. Die Arbeit zerfällt in fünf Wellen: Discovery (nur lesend), Impl-Core, Impl-Polish, Quality, Finalize. Agenten arbeiten innerhalb einer Welle parallel. Zwischen den Wellen prüft ein Reviewer-Agent das Ergebnis auf acht Dimensionen, von Implementierungs-Korrektheit über Testabdeckung bis zu OWASP-Sicherheit. Nur Befunde ab einem Konfidenz-Schwellwert erreichen mich.
• /close. Verifiziert jede geplante Aufgabe. Die Quality-Gates laufen voll. Unfertige Arbeit wird automatisch zu Carryover-Issues, damit nichts durchrutscht. Dateien werden einzeln gestaged, nicht über git add ., damit parallele Sessions sich nicht gegenseitig überschreiben.
• /evolve. Läuft bewusst, nicht automatisch. Er analysiert die Session-Historie über mehrere Läufe, hebt Muster heraus, die erst über Zeit sichtbar werden, und speist sie als Lern-Einträge zurück.

Die Prompts sind der offensichtliche Teil. Das Verfahren drumherum macht den Unterschied zwischen einem beeindruckenden ersten Tag und einem produktiven hundertsten.

Der Grund für die Wellen-Struktur ist nicht Ästhetik. Discovery zuerst, damit die Implementierungs-Agenten mit geteiltem Kontext starten. Impl-Core vor Impl-Polish, damit die Architektur-Entscheidungen vor den Integrationen landen. Und die Quality-Welle macht einen Vereinfachungs-Durchgang über den KI-generierten Code, bevor Tests geschrieben werden, sonst zementieren die Tests genau die Muster, die man eigentlich aufräumen wollte.

Der Zustand überlebt dabei auch Abstürze. Eine Zustandsdatei hält den Wellen-Fortschritt, den Missionsstand und Abweichungen fest. Wird eine Session unterbrochen, bietet der nächste /session-Aufruf an, ab der letzten abgeschlossenen Welle weiterzumachen, statt von vorn zu beginnen. Und die Hooks erzwingen, statt nur zu warnen: Ein Pre-Bash-Guard blockt destruktive Shell-Befehle wie ein hartes Reset oder einen Force-Push nach festen Regeln, in der Haupt-Session ebenso wie in den parallelen Sub-Agenten-Wellen.

Was 18 Sessions in 9 Tagen daraus gemacht haben

Hier wird es interessant. Über ein Zeitfenster von 9 Tagen liefen 18 Sessions am Tool selbst, mit dem Tool selbst. Es orchestriert seine eigene Weiterentwicklung. Das Ergebnis dieser Phase, gerundet und zeitlos formuliert, weil exakte Zahlen täglich driften:

Die Testabdeckung wuchs um über zweitausend Tests in diesem Fenster, ohne ein einziges Breaking Change und ohne CI-Regression. Heute liegt die Suite bei knapp zehntausend Tests und läuft auf jedem Commit. Die Menge allein beweist nichts: Es kommt darauf an, dass es deterministische Gates sind, die echte Regressionen abfangen, kein assert-true-Theater, das nur grün leuchtet. Das ist kein Selbstzweck: Bei einem Tool, das andere Repositories absichern soll, ist die eigene Testabdeckung das erste Glaubwürdigkeits-Argument.

Vier Bündel an Reifung stachen heraus:

• Memory und Personas. Ein agent-schreibbares Gedächtnis, über das Agenten am Session-Ende Lern-Vorschläge einreichen, die ich freigebe oder verwerfe. Dazu pro Repository eine verhaltensbezogene Identität, die festhält, wie ich arbeite und worauf der Agent achten soll. So beginnt Session 19 nicht bei Null, sondern mit dem Wissen aus Session 1 bis 18.
• Hardening-Patterns. Vier mechanische Härtungen: ein prozessübergreifendes Schreib-Lock auf der Zustandsdatei, damit parallele Sessions sich nicht zerschießen. Ein Hook, der das Lesen von Issue-Templates erzwingt, bevor ein Issue angelegt wird. Eine Prüfung gegen von der KI halluzinierte Paketnamen. Und eine begrenzte Auto-Fix-Schleife, die nach einem fehlgeschlagenen Quality-Gate mit Diagnose-Bündel nachbessert.
• Persona-Panel. Eine Skill, die mehrere Personas parallel über eine Datei oder einen Output urteilen lässt, etwa Domänen-Experten, Käufer-Personas oder Compliance-Prüfer. Drei Abstimmungs-Modi, von Mehrheitsvotum bis Hart-Gate-Schwelle. Genau dieses Panel nutze ich übrigens auch, um Blog-Entwürfe wie diesen gegen verschiedene Leser-Brillen prüfen zu lassen.
• harness-audit. Eine Skill, die das eigene Repository gegen Anthropics Best-Practices für große Codebasen prüft und einen Rubrik-Score ausgibt: geschichtete Instruktionsdateien, Code-Intelligence-Verdrahtung, lean gehaltene Root-Dateien. Man kann das Tool also auf sich selbst und auf fremde Repositories anwenden.

Heute deckt das Tool vier Runtimes ab: Claude Code, Codex CLI, Cursor und Pi. Hinzu kommen Hooks, die Scope erzwingen, destruktive Befehle blocken und Telemetrie erfassen. Den genauen Umfang an Skills und Commands liste ich hier bewusst nicht auf, weil er ohnehin täglich driftet und eine solche Zahlen-Parade nichts über die Substanz aussagt.

Warum tägliche Eigennutzung die schnellste Reifung ist

Der entscheidende Faktor ist nicht die Anzahl der Sessions, sondern dass es echte Sessions an echten Projekten sind. Ich baue mit dem Tool meine eigenen Sachen, und jedes Mal, wenn etwas reibt, wird die Reibung zum nächsten Feature.

Ein Beispiel aus der Praxis: An einem Tag fiel auf, dass acht CI-Pipelines still rot waren, während die lokalen Tests grün meldeten. Lokal grün ist eben kein Beleg für CI grün. Die Konsequenz war keine Notiz im Backlog, sondern eine harte Regel: Beim Session-Start ist der CI-Status die Wahrheitsquelle, nicht der lokale Testlauf. Heute rendert das Tool beim Start ein Warn-Banner, wenn CI auf dem aktuellen Stand rot ist. So entsteht Reifung: ein Fehler, der einmal weh tat, wird zum Gate, das ihn nie wieder durchlässt.

Dasselbe Prinzip gilt für die Sicherheit. Ein Pre-Commit-Hook scannt gestagete Änderungen auf Secrets und auf private Pfade, bevor ein Commit überhaupt zustande kommt, weil genau diese Lücke vorher mehrfach durchgerutscht ist. Kein Hexenwerk, sondern die Lehre aus konkretem Schmerz, in Code gegossen.

Diese Arbeitsweise ist auch der Beleg, der zählt. Mein eigenes GitHub-Profil mit der täglichen Open-Source-Aktivität ist sichtbarer und ehrlicher als jede Folie. Wer wissen will, ob jemand wirklich täglich mit diesen Methoden baut, schaut sich den Commit-Graph an, nicht das LinkedIn-Profil.

Vom Repository auf die Bühne: web3 hub vienna

Am 10.06.2026 habe ich session-orchestrator beim web3 hub vienna Meetup live gezeigt, vor vollem Saal. Kein Slide-Deck als Hauptakt, sondern das laufende Tool: der Lifecycle von /plan über /session und /go bis /close und /evolve auf der Großleinwand, an einem echten Repository.

Der Teil, der im Raum am besten ankam, war die Installation. Zwei Slash-Commands im offenen Claude Code, am offenen README mitgelesen:

/plugin marketplace add Kanevry/session-orchestrator
/plugin install session-orchestrator@kanevry

Danach einmalig npm install im Plugin-Verzeichnis, Neustart, fertig. Keine Cloud, kein Account, keine versteckte Komponente. Das ist der Punkt, an dem die Skepsis im Raum kippt: Es ist kein Produkt mit Vertriebsweg, sondern ein Stück Software, das man in zwei Zeilen ausprobieren kann. Der BitGN-Hackathon-Sieg, über den ich in Erster Platz beim BitGN Hackathon in Wien geschrieben habe, kam an dem Abend nur als kurzer Beleg für den Sicherheits-Fokus vor.

Vorträge sind bei mir das Nebenprodukt, nicht das Produkt. Was ich auf der Bühne zeige, ist dasselbe, was ich am Vortag und am Tag danach im Repository mache. Diese Deckungsgleichheit ist der ganze Trick: kein Demo-Theater, sondern der echte Arbeitsstand.

Vom Werkzeug zur Methode

Ein Tool wie session-orchestrator ist mehr als seine Befehle. Es ist eine Methode, in Code gegossen: warum Ausführung in Wellen läuft, warum jede Welle an einem Verifikations-Gate endet, wie man eine autonome Schleife baut, die verlässlich fertig wird. Das gilt auch für die anderen Tools, die aus derselben Praxis entstanden sind, etwa der Weg von einem Open-Source-Experiment zu einem produktionsreifen Agenten, den ich in Von OpenClaw zu Hermes-Agent beschrieben habe.

Wer den 5-Wellen-Workflow nicht nur installieren, sondern verstehen und selbst aufbauen möchte, findet die Methode dahinter aufbereitet: Ich lehre sie Schritt für Schritt im Kurs Multi-Agent-Orchestrierung in der Praxis auf agenticbuilders.at, also wann Parallelität den Aufwand wert ist, wie man Sub-Agenten sauber brieft und wie aus echten Fehlern feste Gates werden. Und wer einen Blick in die rohen Daten werfen will: Unter Ressourcen liegen die "Zahlen aus dem Maschinenraum", erhoben aus genau diesem Tool. Das Plugin selbst bleibt kostenlos und MIT-lizenziert. Die Kurse sind zum Tiefergehen, keine Voraussetzung fürs Nutzen.

Wenn Sie diese Methode lieber direkt auf ein konkretes Projekt anwenden lassen wollen: Ich arbeite bewusst nur mit ein bis zwei Kunden gleichzeitig, damit die Substanz stimmt. Kontakt ist der direkte Weg.

Fazit

Was an session-orchestrator zählt, ist nicht die Funktionsliste, sondern die Reifungs-Mechanik dahinter:

1. Ein Verfahren schlägt schnellere Prompts. Der Lifecycle von /plan bis /evolve macht aus ad-hoc-Sessions einen wiederholbaren Loop mit Prüf-Gates.
2. Eigennutzung ist die schnellste Reifung. 18 Sessions in 9 Tagen, jede an echtem Code: Jede Reibung wurde zum nächsten Feature, jeder Fehler zum Gate.
3. Belege schlagen Behauptungen. Ein öffentliches MIT-Repository, ein täglicher Commit-Graph und eine Installation in zwei Zeilen sind ehrlicher als jede Folie.

KI ist auch hier ein Werkzeug: mächtig, aber nicht magisch. Was es produktiv macht, ist das System drumherum und die Disziplin, es jeden Tag selbst zu benutzen.