vibecode-pro-max-kit: Spezifikationen, Gedächtnis und Multi-Agent-Workflow für KI-Coding

Beim KI-Coding verliert man selten wegen eines spektakulären Modellfehlers die Kontrolle. Häufig sind es drei kleinere Brüche: Der Kontext wird abgeschnitten, Pläne liegen nur im Chatverlauf, und Entscheidungen hinterlassen keine Spur. Bei jeder Anforderungsänderung müssen Sie das ganze Projekt erneut erklären.

vibecode-pro-max-kit adressiert genau dieses Workflow-Problem. Es soll einen AI coding agent näher an ein spec-driven engineering team bringen: erst Spezifikation, dann Planung, dann Ausführung, mit auditierbaren Aufzeichnungen in jedem Schritt. Es ist kein Chat-Framework und ersetzt kein CI/CD. Die Aufgabe ist enger: Entscheidungen im KI-Coding nachvollziehbar machen.

---

Welches Problem löst es?

Kontextverlust: Lange Gespräche werden durch compaction abgeschnitten. Designentscheidungen, Randbedingungen und Debugging-Spuren verschwinden. Bei der nächsten Änderung müssen Sie entweder neu erklären oder die KI raten lassen.

Pläne und Entscheidungen hinterlassen keine Spur: Ein Markdown-Export aus dem Chat ist keine strukturierte Dokumentation. Im Review sieht das Team nicht, warum eine Lösung gewählt wurde oder welche Optionen verworfen wurden.

Multi-Agent-Handoffs sind teuer: Eine Aufgabe kann auf mehrere agents verteilt werden, aber die Übergabe basiert oft auf lockerer natürlicher Sprache. Wer welchen Schritt verantwortet, welches Ausgabeformat gilt und wo die Akzeptanzkriterien stehen, muss weiterhin ein Mensch kontrollieren.

Zusammen führen diese Punkte dazu, dass sich KI-Coding jedes Mal wie ein Neustart anfühlt. vibecode-pro-max-kit packt sie in ein Harness: spec vorne, plan in der Mitte, checkpoints in der execution und Gedächtnis um den Prozess herum.

---

Installation und Sicherheitsprüfung

Installationsbefehl

Das README verwendet eine Remote-Shell-Installation:

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

Nach der Installation führen Sie in Claude Code vc-setup aus; Codex-Nutzer folgen dem README und verwenden /vc-setup. Dadurch wird process/ erstellt und die Projektkonfiguration initialisiert.

Welche Dateien geschrieben werden

Das aktuelle README beschreibt die Installation als non-destructive: Bestehende .claude/skills/, .claude/agents/, process/ oder settings.json werden nicht gelöscht; nur kit-owned files werden geschrieben oder aktualisiert. Trotzdem landen diese Verzeichnisse und Dateien im Projekt:

Pfad	Inhalt
.claude/agents	Agent-Definitionen für Claude Code; das aktuelle README nennt 15
.claude/skills	Skill-Definitionen für Claude Code; das aktuelle README nennt 33
.claude/hooks	Lifecycle hooks; das aktuelle README nennt 10
.codex/agents	Mirrored agents für Codex
.agents/skills	Symlink auf .claude/skills für Codex discovery
CLAUDE.md	Claude-Code-Orchestrator und routing rules
AGENTS.md	Toolübergreifendes agent- und skill registry
process/	Verzeichnis für Plan-Lifecycle und Projektgedächtnis

Das README sagt außerdem: Bestehende Konfiguration wird nach .vibecode-backup/ gesichert, ein vorhandenes CLAUDE.md wird als CLAUDE.md.pre-vibecode abgelegt, und ein vorhandenes process/ wird nicht direkt vom Installer migriert. Das übernehmen vc-setup / vc-update interaktiv.

Checkliste für die Sicherheitsprüfung

Führen Sie curl | bash nicht direkt in einem Produktions-Repository aus. Auch wenn das README die Installation non-destructive nennt, muss das Remote-Shell-Skript geprüft werden. Es schreibt in sensible Pfade wie .claude/, .codex/, CLAUDE.md und AGENTS.md.

Für den ersten Test ist dieser Ablauf stabiler:

1. ein nicht produktives Projekt forken oder kopieren
2. den Installer in diesem Fork ausführen
3. die geschriebenen Dateien mit git diff prüfen
4. erst migrieren, wenn die Konfigurationsänderungen erwartbar aussehen

Ob das Backup-Verhalten zu Ihrem Repository passt, müssen Sie selbst prüfen. Projekte mit eigenen vc--präfixierten skills oder agents sollten den README-Hinweis besonders ernst nehmen und das Ergebnis kontrollieren.

„Non-destructive“ heißt auch nicht „risikofrei“. Es senkt die Wahrscheinlichkeit, ein bestehendes Verzeichnis zu löschen, ersetzt aber keine Supply-Chain-Prüfung, keine Berechtigungsgrenzen und keinen Rollback-Plan. Für ein Teamprojekt bleibt der kleinste sichere Schritt: Skript lesen, in einer Kopie ausführen, Diff von einer zweiten Person prüfen lassen.

---

Kernidee: spec-driven workflow

Hintergrund zu Spec Kit

Die Kernidee hinter vibecode-pro-max-kit kommt aus spec-driven development Workflows wie Spec Kit. Der Ablauf ist einfach: erst die Spezifikation schreiben, dann daraus einen Plan machen, den Plan in Aufgaben aufteilen und schließlich implementieren.

Jede Phase erzeugt ein Markdown-Artefakt, das der nächsten Phase strukturierten Kontext liefert:

Phase	Eingabe	Ausgabe
Spec	Anforderungsbeschreibung	Spezifikationsdokument mit Grenzen, Constraints und Akzeptanzkriterien
Plan	Spezifikationsdokument	Implementierungsplan mit Schritten, Verantwortlichen und Abhängigkeiten
Tasks	Implementierungsplan	Konkrete, überprüfbare Aufgabenliste
Implement	Aufgabenliste	Codeänderungen + Prozessnotizen

Dieser Workflow ist nicht neu. vibecode-pro-max-kit installiert ihn jedoch ins Projekt: agents, skills und hooks sind um diesen Prozess herum organisiert.

Plan-Lifecycle

Das aktuelle README betont einen RIPER-5 plan-first workflow und beschreibt 7 gated phases:

Phase	Was passiert	Artefakt
Research	Hintergrund sammeln und Grenzen bestätigen	research artifact
Spec	User Stories und Anforderungsgrenzen schreiben	spec artifact
Innovate	Optionen vergleichen und Trade-offs festhalten	alternatives / decision notes
Plan	Schritte, Zuständigkeit und Validierung ausarbeiten	plan artifact
Validate	Plan und Risiken vor der Ausführung prüfen	validation notes
Execute	Aufgaben umsetzen und Prozess aufzeichnen	code changes + execution notes
Update-Process	Gedächtnis aktualisieren und alte Notizen bereinigen	process / context updates

Jede Phase benötigt eine explizite Freigabe, bevor es weitergeht. Genau dort liegt der Kontrollpunkt: Ein Mensch prüft die Richtung, bevor der agent fortfährt.

Agents und skills

Das README nennt aktuell 15 agents, 33 skills und 10 hooks. Das ist die am 23. Juni 2026 geprüfte README-Formulierung, kein dauerhaft fixer Wert.

Die Skill-Struktur folgt Codex Skills und Claude Code skills: Jeder skill hat eine SKILL.md für instructions und optional scripts/, references/ und assets/. Ein skill kann explizit aufgerufen werden oder implizit greifen, wenn die Aufgabe zu seiner Grenze passt.

Zwei weitere Konzepte sind wichtig:

• context groups: Kontextblöcke nach Thema oder Feature, damit der agent nicht jedes Mal das gesamte Projekt laden muss
• feature folders: Feature-Verzeichnisse mit eigenem spec- und process-Material

---

Sicherheitsmechanismen im Detail

Das README nennt mehrere Sicherheits- und Workflow-Mechanismen, die genaueres Hinsehen verdienen:

Mechanismus	Aufgabe	Einsatzzeitpunkt
privacy guardrails	Verhindert, dass sensible Informationen in process files oder output gelangen	Vor agent output und process updates
gated phases	Stoppt den agent davor, direkt zu Code zu springen	Von Research bis Update-Process
check loops	Ermöglicht Selbstprüfung und Rückkehr zum Plan	Während execution und validation
deviation protocol	Hält Verhalten fest, das vom ursprünglichen Plan abweicht	Wenn sich der plan ändert oder execution driftet
high-risk evidence pack	Verlangt zusätzliche Belege für riskante Entscheidungen	Wenn ein Schwellenwert ausgelöst wird

Diese Mechanismen machen es schwieriger, dass die KI ohne Aufsicht riskante Entscheidungen trifft. Sie hängen aber davon ab, dass hooks und Konfiguration korrekt laufen. Wenn hooks deaktiviert sind, Berechtigungen zu breit sind oder das Team process/ nie liest, kann der Mechanismus trotzdem scheitern.

---

Passende Einsatzszenarien

Szenario	Eignung	Begründung
Langfristig gepflegtes Projekt	Gut geeignet	Gedächtnis landet in process/, Pläne sind auditierbar
Review durch mehrere Personen	Gut geeignet	Entscheidungen hinterlassen Spuren, Abweichungen sind nachvollziehbar
Komplexe Anforderung	Gut geeignet	Multi-Agent-Zusammenarbeit und phasenweise Verfeinerung helfen
Kontext geht leicht verloren	Gut geeignet	Spec-driven Struktur gibt der Unterhaltung Form
Einmalskript	Eher ungeeignet	Der Workflow-Overhead ist zu hoch
Kleiner Fix	Eher ungeeignet	Das Harness kostet mehr als die Änderung
Reifer Engineering-Prozess existiert bereits	Vorsichtig nutzen	Es kann mit bestehendem CI/CD- und Review-Flow kollidieren
Kein externes Harness erwünscht	Nicht geeignet	README, AGENTS.md, CLAUDE.md und process files verändern das Repository

Die Kernfrage lautet: Lohnt sich der Workflow-Overhead? Langfristige, komplexe und kollaborative Projekte können diesen Overhead gegen Auditierbarkeit und Koordination tauschen. Kurze, einfache Solo-Projekte zahlen ihn als reine Kosten.

---

Beziehung zu Spec Kit, Codex Skills und Claude Code

Spec Kit: definiert den Hintergrund und Prozessrahmen für SDD, also spec-driven development. Es ist eine Konzeptebene und nicht an einen konkreten agent gebunden.

Codex Skills: die Skill-Verzeichnisstruktur von OpenAI: SKILL.md + scripts/ + references/. Damit werden instructions, resources und scripts als wiederverwendbare Workflows verpackt.

Claude Code skills: ähnlich aufgebaut, mit SKILL.md plus unterstützenden Dateien. Ein skill ist eine wiederverwendbare Workflow-Einheit und kann explizit oder implizit genutzt werden.

vibecode-pro-max-kit: installiert diese Ideen in ein Projekt. Es ersetzt Spec Kit nicht, sondern macht einen spec-driven workflow als ausführbare agents, skills und hooks nutzbar, mit Projektkonfiguration für Claude Code und Codex.

Migrationskosten: Wenn das Projekt bereits .claude/agents, .claude/skills, CLAUDE.md oder AGENTS.md hat, prüfen Sie den Diff und stellen Sie sicher, dass Ihre eigene Konfiguration nicht verloren gegangen ist.

---

Workflow für den ersten Test

Dem README folgend sollte der erste Test außerhalb der Produktion stattfinden:

Schritt 1: Nicht produktives Projekt forken oder kopieren

Arbeiten Sie nicht direkt im Haupt-Repository. Nutzen Sie einen Fork oder eine lokale Testkopie.

Schritt 2: Installationsbefehl ausführen

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

Schritt 3: vc-setup ausführen

Führen Sie vc-setup in Claude Code aus; in Codex folgen Sie dem README und verwenden /vc-setup. Dadurch wird process/ erstellt und die Konfiguration initialisiert.

Schritt 4: Geschriebene Dateien prüfen

git status
git diff .claude/ .codex/ .agents/ CLAUDE.md AGENTS.md process/

Prüfen Sie, ob die geschriebenen Dateien den Erwartungen entsprechen.

Schritt 5: Ersten spec-driven workflow ausprobieren

Geben Sie dem agent eine einfache Anfrage, etwa „Logging-Helper hinzufügen“. Beobachten Sie den Ablauf Research → Spec → Innovate → Plan → Validate → Execute → Update-Process und prüfen Sie, ob jedes Freigabe-Gate ausgelöst wird.

Schritt 6: Ergebnis validieren

Suchen Sie nach Artefakten unter process/, nachvollziehbaren Änderungen in CLAUDE.md / AGENTS.md und keinen Fehlern aus hooks oder agents. Erst dann sollten Sie überlegen, das Setup in ein echtes Projekt zu übernehmen.

---

Nächste Schritte und weiterführende Beiträge

Verwandte veröffentlichte Beiträge:

• OpenClaw Multi-Agent-Routing in der Praxis
• Vollständiger Claude Code Workflow-Leitfaden
• Speichermechanismen von AI agents

Geplante Folgethemen in dieser Serie:

• Eine Troubleshooting-Checkliste für Multi-Agent-Zusammenarbeit
• Eine praktische Fallstudie zu spec-driven projects