vibecode-pro-max-kit: Spec-getriebene Agenten-Pipeline mit RIPER-5 und /goal

Das Problem: Agenten verlieren nach jedem Reset den Faden

Die Beschreibung des Projekts beginnt mit einem Satz, der die Zielgruppe definiert: Your AI forgets. This remembers. Gemeint ist damit ein konkretes Verhalten von Coding-Agenten. Ein Agent arbeitet an einer mehrstufigen Aufgabe, die Sitzung endet oder der Kontext wird zurückgesetzt, und beim nächsten Start fehlt die Information, welche Phase abgeschlossen war. Das Kit setzt dagegen auf Fortschrittsnotizen, die laut README nach jeder Phase auf die Platte geschrieben werden. Ein Lauf soll damit einen Speicher-Reset überleben und an der Stelle weiterlaufen, an der er aufgehört hat. Adressiert sind ausdrücklich Vibecoder, Product Owner, CEOs und real builders, also Personen, die ein Ergebnis wollen und nicht die Zwischenschritte eines Agenten moderieren möchten. Der Anspruch ist entsprechend hoch gesteckt: Autopilot ohne menschliches Gate. Ob das in der Praxis trägt, hängt davon ab, wie gut die SPEC-Phase den Auftrag einfängt, denn dort liegt laut README die günstigste Stelle, ein Missverständnis zu bemerken.

RIPER-5: sieben Phasen und der Versuch, den Sprung in den Code zu verhindern

Der Kern des Kits ist ein Workflow mit sieben gated Phasen: Research, Spec, Innovate, Plan, Validate, Execute und Update-Process. Die Reihenfolge ist nicht dekorativ. Sie soll verhindern, dass der Agent direkt nach der ersten Anfrage Code schreibt. Zwischen den Phasen liegen Gates, und die SPEC-Phase ist als Klartext-Freigabe gedacht: Nutzergeschichten in einfacher Sprache, bevor irgendein Design entsteht. Jede spätere Phase misst laut README gegen diese SPEC zurück. Das ist eine bewusste Umkehrung der üblichen Reihenfolge bei Coding-Agenten, die mit dem Code beginnen und die Absicht später rekonstruieren. Der Preis dafür ist Sichtbarkeit: Wer sieben Phasen durchläuft, sieht mehr Zwischenstände als jemand, der einen Prompt abschickt und einen Diff zurückbekommt. Für schnelle Experimente ist das der falsche Aufbau, weshalb das Kit mit Quick Fix und Fast Mode zwei leichtere Spuren anbietet, die die Zeremonie für kleine Änderungen überspringen sollen.

Der /goal-Token und die selbstheilenden Schleifen

Zwei Mechanismen tragen den Autopilot-Anspruch. Der erste ist /goal, im README als run-until-done token bezeichnet. Ein kopierbarer Block hält den Agenten von Phase zu Phase am Laufen, ohne dass er anhält, und kann den Lauf in einer neuen Sitzung wieder aufnehmen. Der zweite sind die PVL- und EVL-Schleifen: Plan-check-fix und test-check-fix, jeweils mit bis zu zehn Zyklen. Der Agent sucht Lücken, behebt sie und prüft erneut. Dazu kommt vc-autoresearch, eine wiederverwendbare Schleife aus find-gaps, fix und repeat, die sich laut README auf Pläne, Tests, Spezifikationen, Dokumentation oder Evaluierungen richten lässt. Vor jedem Design-Schritt stehen Feasibility-Probes mit den Verdikten VIABLE oder NOT-VIABLE. Das ist ein interessanter Bruch mit dem üblichen Muster: Der Agent entscheidet nicht erst nach dem Bauen, ob der Ansatz trägt, sondern vorher. Die Obergrenze von zehn Zyklen pro Schleife ist eine reale Einschränkung, kein Detail. Wer erwartet, dass eine Schleife beliebig lange nach Fehlern sucht, wird hier gestoppt.

Kostensteuerung: teures Modell für Code, günstiges für den Rest

Das Kit enthält eine explizite Kostenlogik. Der Smart strategy picker wägt vor jeder Phase ab, ob ein einzelner Agent, mehrere Agenten oder ein koordiniertes Team zum Einsatz kommt, und wählt laut README die günstigste Variante, die passt. Die Kostenschätzungen sind Teil dieser Auswahl. Beim Modell gilt eine einfache Aufteilung: Das teure Modell schreibt nur Code, alles andere übernimmt das günstigere. Ob diese Aufteilung in der Realität aufgeht, lässt sich aus dem Material nicht belegen, denn das README nennt keine Zahlen. Festhalten lässt sich nur die Designentscheidung. Sie ist plausibel, weil Planung, Recherche und Dokumentation weniger vom stärksten Modell profitieren als das Schreiben von Code. Wer allerdings ein Projekt hat, in dem gerade die Planungsqualität über den Erfolg entscheidet, sollte die Aufteilung hinterfragen, bevor er sie übernimmt. Der Strategie-Picker ist eine Empfehlung des Kits, keine Messung des eigenen Projekts.

Installation und Lebenszyklus: ein curl-Befehl und vc-update

Die Installation erfolgt laut README über eine einzelne curl-Zeile, die das Kit in ein beliebiges Projekt legt. Der Installer erkennt nach eigener Angabe, ob es sich um eine neue oder eine wiederkehrende Installation handelt, und überschreibt keine bestehenden Dateien. Der vollständige Befehl ist im hier vorliegenden Auszug nicht enthalten, also lässt er sich nicht unverändert zitieren. Der Lebenszyklus besteht aus vier Einzelbefehlen: Install, Setup, Update und Publish. Für Updates ist vc-update zuständig. Die Release-Historie zeigt, dass dieser Pfad zuletzt mehrfach korrigiert wurde. In v3.2.3 führt vc-update eine adaptive Migration auch dann aus, wenn die installierte Version der Zielversion entspricht. In v3.2.4 wurde ein Datenverlust-Fehler behoben, indem Inhaltsverzeichnisse an vc-update delegiert werden. v3.2.5 ergänzt Hinweise zur Installation unter Windows. Dass ein Installer innerhalb weniger Tage zwei Korrekturen an genau dieser Stelle braucht, ist ein Signal: Vor dem ersten echten Lauf gehört ein Blick darauf, welche Dateien und Verzeichnisse der Installer anlegt und ob er sie im Zweifel wieder entfernt. Das Kit bringt außerdem 10 Hooks mit, die laut README als Sicherheitsnetz dienen. Ob sie in die eigene Umgebung passen, ist vor der Installation zu klären, nicht danach.

36 Validatoren und die Frage, was maschinell prüfbar ist

Das Kit enthält 36 Validatoren, die als mechanische Korrektheitsprüfungen beschrieben werden, ausdrücklich nicht als Meinungen. Sie sollen die eigene Struktur des Kits absichern und Drift erkennen, bevor etwas ausgeliefert wird. Das ist ein sinnvoller Schnitt: Strukturprüfungen lassen sich deterministisch formulieren, Stilfragen nicht. Die Grenze verläuft dort, wo ein Validator grün meldet, obwohl die Umsetzung fachlich falsch ist. Kein mechanischer Check erkennt, ob eine Funktion das tut, was der Nutzer gemeint hat. Genau deshalb bleibt die SPEC-Phase im Workflow unverzichtbar, und genau deshalb ist die Aussage, das Kit laufe ohne menschliches Gate, mit Vorsicht zu lesen. Die Validatoren prüfen die Form, die SPEC prüft die Absicht, und beide zusammen ersetzen keine Abnahme durch den Auftraggeber. Wer das Kit als Ersatz für fachliche Kontrolle einsetzt, verlagert das Risiko nur an eine Stelle, an der es später teurer wird.

Grenzen: wo das Kit im Weg steht

Der deutlichste Fall gegen das Kit ist die kleine Änderung in einem bestehenden Repository. Wer eine Zeile korrigiert, will keine sieben Phasen, keine Feasibility-Probe und keine SPEC-Freigabe. Das Kit reagiert darauf mit Quick Fix und Fast Mode, doch diese Spuren existieren, weil das Standardverfahren für solche Fälle zu schwer ist. Ein zweiter Punkt betrifft die Abhängigkeit von der Umgebung. Das Kit schreibt Dateien in das Projekt, installiert Hooks und führt bei Updates Migrationen aus. In Repositorys mit strikten Regeln zu erlaubten Dateien oder mit Prüfungen auf unerwartete Verzeichnisse kann das Reibung erzeugen. Drittens die Schleifenobergrenze: Zehn Zyklen pro PVL- oder EVL-Lauf sind eine harte Grenze, und wenn ein Fehler danach noch steht, endet der Lauf mit einem offenen Problem. Das README sagt nicht, was in diesem Fall passiert. Wer einen Agenten erwartet, der beliebig lange weitersucht, wird hier enttäuscht. Schließlich sei der Ton des Projekts erwähnt. Referenzen auf Anime-Figuren und die Formulierung spec breathing sind Teil der Selbstdarstellung. Das ist eine Stilfrage, aber sie erschwert es, die technischen Aussagen von der Vermarktung zu trennen.

Alternative: Spec Kit und der Unterschied im Ablauf

Als Vergleichsmaßstab bietet sich GitHubs Spec Kit an, ebenfalls ein Werkzeug, das Coding-Agenten über Spezifikationen steuert. Der Unterschied liegt nicht im Ziel, sondern im Ablauf. Spec Kit konzentriert sich auf die Erstellung und Pflege der Spezifikation als Artefakt, das der Agent liest. vibecode-pro-max-kit legt darüber eine feste Phasenfolge, Gates zwischen den Phasen, Autopilot-Modi, selbstheilende Prüfschleifen und eine Kostenheuristik für die Modellwahl. Das ist mehr Struktur und mehr bewegliche Teile. Wer bereits eine Spezifikationspraxis hat und nur ein Format für den Agenten braucht, fährt mit dem schlankeren Werkzeug besser. Wer dagegen wiederholt erlebt, dass ein Agent mitten in einer mehrstufigen Aufgabe den Faden verliert, findet hier Mechanismen, die genau dieses Problem adressieren: Fortschrittsnotizen auf Platte, /goal als Wiederaufnahme-Token und Phasen mit definiertem Ende. Der zweite Unterschied betrifft die Breite. Das Kit nennt Claude Code und Codex sowie Cursor, Windsurf und Copilot als unterstützte Agenten. Ob die Qualität auf allen gleich ist, lässt sich aus dem Material nicht beurteilen. Wer auf einem der weniger verbreiteten Agenten arbeitet, sollte das vorher prüfen.

Lizenz, Wartung und was vor dem ersten Lauf zu klären ist

Das Kit steht unter MIT-Lizenz. Das ist die permissivste gängige Variante: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Lizenztext und der Urheberrechtshinweis erhalten bleiben. Für die meisten Teams bedeutet das keine Einschränkung. Wer das Kit in ein Produkt einbettet oder forkt, sollte den Hinweis trotzdem mitführen. Rechtliche Beratung ist das nicht, und die konkreten Pflichten ergeben sich aus dem LICENSE-Text im Repository. Zur Wartung: Der letzte Push liegt auf dem 21. Juni 2026, die drei jüngsten Releases fallen in den 19. bis 21. Juni 2026. Das ist ein aktives Projekt mit kurzen Release-Abständen. Die Kehrseite ist die Update-Frequenz. Wer das Kit in vielen Repositorys installiert, muss vc-update regelmäßig laufen lassen, sonst driften die Installationen auseinander. Die letzten drei Releases betreffen genau diesen Pfad: Migration bei Versionsgleichheit, Datenverlust im Installer, Windows-Hinweise. Das ist kein Zeichen von Unreife, sondern ein Hinweis darauf, wo die Fehler zuletzt saßen. Vor dem ersten Lauf in einem produktiven Repository gehört deshalb ein Testlauf in einer Kopie dazu, mit anschließender Prüfung, welche Dateien der Installer angelegt hat und ob vc-update sie sauber behandelt.

Redaktionelles Fazit

Wer einen einzelnen Agenten ohne Phasendisziplin laufen lässt und dabei regelmäßig Kontext verliert, für den ist das Kit einen Versuch wert, sofern das Projekt die RIPER-5-Zeremonie verträgt. Wer kleine Änderungen in einem bestehenden Repository macht oder keinen Zugriff auf die Dateien im Projektstamm kontrollieren will, sollte es nicht installieren. Vor dem Einsatz zu prüfen: die tatsächlich angelegten Dateien und Verzeichnisse nach dem curl-Befehl, das Verhalten von vc-update bei Versionsgleichheit und die Frage, ob die installierten Hooks in die eigene Toolchain passen.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. Releases
5. withkynam/vibecode-pro-max-kit on GitHub