English | 简体中文 | 日本語 | 한국어 | Tiếng Việt | Português | Español | Deutsch | Français | हिंदी
Entwickelt von Weltklasse-Ingenieuren, für Vibecoders bei
flowser.ai — KI-Agenten mit Computern für GTM
"Totale Konzentration — Spec-Atmung, Zehnte Form: Der Vibe Flow bricht niemals ab."
— Tanjiro Kamado
Füge es in jedes Projekt ein. Dein KI-Agent bekommt einen vollständigen plan-first Entwicklungsprozess — 7 kontrollierte Phasen, selbstheilende Prüfschleifen und einen Autopiloten, der von Anfang bis Ende läuft, ohne seinen Platz zu verlieren.
| 📦 Installation mit einem Befehl Eine einzige curl-Zeile installiert es in jedes Projekt. Es erkennt neue und wiederkehrende Nutzer und überschreibt niemals deine Dateien. |
🌐 Funktioniert überall Jeder Tech-Stack, jede Sprache und jeder KI-Coding-Agent — Claude Code, Codex, Cursor, Windsurf, Copilot und mehr. |
| 🧭 RIPER-5 plan-first Workflow 7 kontrollierte Phasen (Research → Spec → Innovate → Plan → Validate → Execute → Update-Process) hindern den Agenten daran, direkt mit dem Coden zu beginnen. |
🚀 Autopilot-Modus (quick / fast / full) Starte einen handfreien Durchlauf ab jeder Phase mit einem einzigen Satz. Drei Spuren passen den Aufwand dem Risiko an. |
🎯 /goal — das Weiterlaufen-bis-fertig-TokenEin einziger kopierbarer Block hält den Agenten Phase für Phase am Laufen, ohne anzuhalten — und nimmt den Durchlauf in einer neuen Sitzung wieder auf. |
🔁 PVL + EVL selbstheilende Schleifen Plan-prüfen-beheben und Test-prüfen-beheben Schleifen finden Lücken, beheben sie und prüfen erneut — jeweils bis zu 10 Zyklen. |
| 🔍 vc-autoresearch Eine wiederverwendbare Schleife aus Lücken-finden → beheben → wiederholen, die du auf Pläne, Tests, Specs, Docs oder Evals ausrichten kannst. |
🧪 Machbarkeits-Prüfungen Test-vor-dem-Bauen Urteile (VIABLE / NOT-VIABLE), bevor der Agent sich auf einen Designansatz festlegt. |
| 🎛️ Smarter Strategiewähler Vor jeder Phase wägt er einen Agenten gegen viele oder ein koordiniertes Team ab — mit Kostenschätzungen — und wählt die günstigste passende Option. |
🧮 Smarter Modelleinsatz Das teure Modell schreibt nur Code; das günstigere erledigt alles andere. Niedrigere Kosten, gleiche Qualität. |
| 🤔 Absichtsklärung Bei einer vagen Anfrage stellt der Agent einige gezielte Fragen vorab, anstatt zu raten und das Falsche zu bauen. |
🛡️ 36 Validatoren Mechanische Korrektheitsprüfungen — keine Meinungen — bewachen die eigene Struktur des Kits und erkennen Abweichungen, bevor sie veröffentlicht werden. |
| 🏗️ Phasenprogramme Große Projekte werden in unabhängige Phasen mit Qualitäts-Gates dazwischen aufgeteilt, damit umfangreiche Arbeit nicht auseinanderfällt. |
🔀 Programme, die sich selbst umstrukturieren Während es lernt, fügt der Agent neue Phasen ein, ordnet Arbeit um und überspringt blockierte Schritte — der Plan passt sich spontan an. |
| 🧠 Verliert nie seinen Platz Fortschrittsnotizen werden nach jeder Phase auf die Festplatte geschrieben, sodass ein Durchlauf einen Speicher-Reset übersteht und genau dort weitermacht, wo er aufgehört hat. |
📚 Selbst verbesserndes Projektgedächtnis Es lernt deine Codebasis beim Setup kennen und hält nach jeder ausgelieferten Funktion seine gemeinsamen Notizen aktuell, sodass Docs nie veralten. |
| ⚡ Quick Fix + Fast Mode Leichte Spuren für kleine Änderungen überspringen den schweren Zeremoniell, sodass ein einzeiliger Fix ein einzeiliger Fix bleibt. |
🧱 Geschichtete, automatisch erkannte Skills Skills sind in klaren Schichten organisiert und werden automatisch gefunden — der Agent findet immer das richtige Werkzeug für den Schritt. |
| 🤖 15 Agenten · 33 Skills · 10 Hooks Ein vollständiges Team aus spezialisierten Agenten, wiederverwendbaren Skills und Sicherheits-Hooks, alle sofort miteinander verbunden. |
🔄 Vollständiger Kit-Lebenszyklus Installieren, einrichten, aktualisieren und veröffentlichen sind jeweils ein einziger Befehl — jedes Projekt sicher auf dem neuesten Kit halten. |
| 📝 SPEC — deine Freigabe in einfacher Sprache Vor jedem Design gibst du an, was gebaut werden soll — in einfachen User Stories — der günstigste Ort, um ein Missverständnis zu erkennen. |
🎯 Prüft immer deine Absicht Jede spätere Phase gleicht mit deiner SPEC ab: Bauen wir tatsächlich das, worum du gebeten hast? |
Das einfachste, flexibelste und teamfreundlichste Coding-Kit für
Funktioniert mit jedem Tech-Stack, jeder Sprache, jedem Projekt
Nicht nur zur Dekoration. Wenn du vc-setup ausführst, scannen Agenten deine Codebasis,
erkennen deinen Stack und erstellen projektspezifische Wissensgruppen, die jeder Skill liest, bevor er arbeitet.
Andere Harnesses binden Agenten an eine Sprache — rust-review-agent, python-linter — anderswo nutzlos.
Dieses passt sich jeder Kombination oben an und baut Wissen auf, während du auslieferst.
Voraussetzungen: Node.js ≥ 22, git, bash (macOS / Linux / WSL; auf Alpine:
apk add bash).
Es gibt nur einen Befehl, und er funktioniert für alle. Führe ihn im Projektordner aus. Er erkennt, ob du neu oder wiederkehrend bist, installiert sicher ohne deine Dateien zu überschreiben, und sagt dir dann genau, was du als Nächstes schreiben sollst.
curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bashWenn er fertig ist, gibt er eine von zwei Meldungen aus — lies das Ende der Ausgabe und tue genau das, was dort steht:
Der Installer erkennt kein Harness und gibt aus:
Next: Run: claude → Say: "Run vc-setup"
→ Öffne deinen Agenten und sage Run vc-setup
vc-setup erkennt deinen Tech-Stack, erstellt den process/-Ordner, scannt deine Codebasis und füllt deine echte Architektur, Konventionen und Testbefehle ein — ein Gespräch, keine Checkliste.
|
Der Installer erkennt eine vorherige Installation und gibt aus:
Next (upgrade detected): Run: claude → Say: "Run vc-update"
→ Öffne deinen Agenten und sage Run vc-update
vc-update holt die neueste Version und gibt dir bei gefundenen Plänen oder Ordnern im alten Format einen fertigen Prompt zum Einfügen, der den Umzug mit null Datenverlust abschließt. Dein process/-Ordner wird nie angefasst.
|
💡 Du musst nie den Befehl erraten.
install.shführt dich: neu →vc-setup, Upgrade →vc-update. Die Installation erneut auszuführen ist immer sicher — sie bricht nichts. Codex-Nutzer: Gib/vc-setup(oder/vc-update) ein, anstatt es im Chat zu schreiben.
📦 Was die Installation auf die Festplatte legt (nicht-destruktiv)
your-project/
├── .claude/
│ ├── agents/ # 🤖 15 Agenten-Definitionen (.md)
│ ├── skills/ # ⚡ 33 Skills (je ein Verzeichnis mit SKILL.md)
│ └── hooks/ # 🪝 10 Lifecycle-Hooks (.cjs / .mjs)
├── .codex/agents/ # 🔄 Gespiegelte Agenten für Codex
├── .agents/skills → # 🔗 Symlink zu .claude/skills (Codex-Erkennung)
├── CLAUDE.md # 📋 Orchestrator + Routing-Regeln
├── AGENTS.md # 📖 Agenten- und Skill-Registry (toolübergreifend)
└── process/
└── development-protocols/ # 📜 22 gemeinsame Workflow-Docs (durch Install befüllt)
# context/, Pläne, Features → durch vc-setup erstellt
- Nicht-destruktiv. Deine bestehenden
.claude/skills/,.claude/agents/,process/undsettings.jsonwerden niemals gelöscht. Nur kit-eigene Dateien werden geschrieben oder aktualisiert. - Bestehende Konfiguration? Wird in
.vibecode-backup/gesichert; deinesettings.jsonwird danach wiederhergestellt. - Bestehende
CLAUDE.md? Wird alsCLAUDE.md.pre-vibecodegesichert. - Bestehender
process/-Ordner? Wird von der Installation nie angefasst —vc-setup/vc-updatemigrieren ihn interaktiv und zeigen dir vorher den Diff.
Einmalige Erstinstallations-Einschränkung: Falls du eigene Skills/Agenten hast, deren Namen mit
vc-beginnen (dem reservierten Kit-Namespace), und du hast die Installation noch nie zuvor ausgeführt, könnte der Schritt zur Entfernung veralteter Dateien sie markieren. Führe nach der Installationls .claude/skills/ .claude/agents/aus, um es zu bestätigen. Verwende ein Nicht-vc--Präfix (my-,team-,proj-) für eigene Ergänzungen, um dies vollständig zu vermeiden.
🤖 Lieber das Setup vom Agenten aus steuern? (vollständiger Prompt)
Öffne Claude Code oder Codex mit deinem Projektordner als Arbeitsverzeichnis und füge dann Folgendes ein:
First, install the vibecode-pro-max-kit agent harness by running this command:
curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash
After install completes, run vc-setup and follow the full interactive flow:
1. DETECT — Read package.json (or go.mod, Cargo.toml, pyproject.toml, etc.), detect my
stack: framework, package manager, monorepo structure, test framework, database, auth.
Also check for any existing .claude/, process/, or context files.
2. SHOW ME WHAT YOU FOUND — Summarize detection and wait for me to confirm. If this is an
existing project, tell me what looks good vs what could be improved.
3. ASK ME ABOUT THE PROJECT — Have a real conversation. Ask follow-ups, probe anything
vague, keep going until you genuinely understand it. Summarize back and confirm.
4. SCAFFOLD — Create the process/ directory. If process/ already exists, show me the plan
and wait for approval. Never silently move or delete my files.
5. STUDY — Deep-scan and populate process/context/all-context.md with REAL content: repo
structure, stack + versions, patterns, import aliases, env vars, routes, schema, tests.
No placeholder text.
6. VALIDATE — Run all validation checks to confirm everything is wired correctly.
Rules: read and preserve good existing context; show me a summary before each major change
and wait for my OK; never create empty placeholder files; ask before reorganizing.
Inhaltsverzeichnis
- Auf einen Blick · Das Problem · Die Lösung
- Die Vibe-Coding-Revolution · Für wen ist das gedacht? · Vergleich · Was macht das besonders?
- Wie es funktioniert: Der Koordinator · Der RIPER-5 Lebenszyklus · Absichtsklärung
- Die zwei Qualitätsschleifen (PVL + EVL) · Strategievergleich + Modellpolitik · Autopilot-Modus · Machbarkeits-Prüfungen + Validatoren
- Eingebaute Sicherheitssysteme · Vor-Implementierungs-Intelligenz · Qualitätspipeline
- Plan-Lebenszyklus · Phasenprogramme · Kontext-Gruppen · Feature-Ordner · Skill-Schichten · [Selbst verbesserndes Gedächtnis](#-selbst verbesserndes-projektgedächtnis)
- Was ist enthalten · Quick Fix + Fast Mode · Kit-Lebenszyklus · Mitwirken
| Agenten Einer pro Phase + 6 Spezialisten |
Skills 20 Workflow + 13 Helfer, per Keyword gefunden |
Hooks Sicherheitsleitplanken + automatisches Kontext-Laden |
Protokolle Gemeinsame Regeln, die alle Agenten befolgen |
| Validatoren Automatisierte Prüfungen, die Fehler vor der Veröffentlichung abfangen |
Tools Claude Code · Codex · Cursor · Windsurf · Antigravity · OpenCode · Copilot |
Sprachen EN · 中文 · 日本語 · 한국어 · VI · PT · DE · FR · ES · हिन्दी |
Installation Ein Befehl, dann führt dein Agent den Rest durch |
| Autopilot 3 Spuren (quick / fast / full) — ab jeder Phase starten, läuft von Anfang bis Ende ohne Stopp |
/goal Blöcke Kurze kopierbare Texte, die handfreie Durchläufe nach einem Reset sitzungsübergreifend fortsetzen |
vc-autoresearch Lücken-finden → beheben → wiederholen Schleife (gemeinsames Werkzeug für Pläne, Tests und Evals) |
Machbarkeits-Prüfungen Test-vor-dem-Bauen Urteile (VIABLE / NOT-VIABLE) bevor ein Design festgelegt wird |
Du bittest Claude, „Webhook-Unterstützung hinzuzufügen." Es fängt sofort an, Code zu schreiben. Keine Fragen zu deiner Architektur. Kein Blick auf bestehende Muster. Kein Plan. Du bekommst 400 Zeilen, die nicht zu deiner Codebasis passen, und verbringst eine Stunde damit, sie zu korrigieren.
Aber das ist nur die Oberfläche. Die tieferen Probleme treffen härter:
|
Kontext stirbt nach jeder Sitzung Dein Agent vergisst alles, was er gelernt hat. Dieselben Fehler, dieselben Fragen, jedes Mal. Kein Gedächtnis, kein aufbauendes Wissen. |
Docs veralten sofort Du hast letzte Woche großartige Kontext-Docs geschrieben. Die sind schon wieder veraltet. Nichts aktualisiert sie automatisch, wenn sich die Codebasis weiterentwickelt. |
|
Große Aufgaben kollabieren auf halbem Weg Das Context-Fenster füllt sich, der Zustand geht verloren, der Agent beginnt zu halluzinieren. In Stunde 3 fängst du von vorne an. |
Keine Specs, kein Review, keine Zusammenarbeit Dein PM kann nicht prüfen, was der Agent gleich bauen wird. Es gibt keinen schriftlichen Plan zum Teilen, Besprechen oder Genehmigen, bevor Code geschrieben wird. |
|
Architekturentscheidungen werden halluziniert Der Agent erfindet Muster, anstatt zu recherchieren, wie andere Codebasen dasselbe Problem gelöst haben. |
Nichts verifiziert „fertig" Der Agent sagt „alle Tests bestehen" — hat sie aber nie eigenständig erneut ausgeführt. Du merkst es in der Produktion. |
Dein Agent hat Intelligenz, aber keinen Prozess, kein Gedächtnis und keine Möglichkeit, mit deinem Team zusammenzuarbeiten. Ob Entwickler, PM oder CEO, der gerade mit Vibe Coding anfängt — dieses Problem trifft jeden gleich, und die Lösung ist dieselbe: Gib deinem Agenten einen echten Entwicklungsprozess.
Dieses Kit installiert ein vollständiges Entwicklungssystem in dein Projekt — nicht nur eine CLAUDE.md, sondern 15 spezialisierte Agenten, 33 Skills, 10 Hooks und 22 Protokolle — mit einem phasengesperrten Workflow, der deinen Agenten dazu bringt, zu verstehen, bevor er baut, und zu beweisen, bevor er ausliefert.
| Plan-first Ansatz PMs und Entwickler prüfen denselben schriftlichen Plan, bevor eine Zeile Code geschrieben wird |
Selbst verbesserndes Wissen Aktualisiert sich jedes Mal, wenn eine Funktion ausgeliefert wird — Docs veralten nie |
| Handfreie Ausführung Übersteht Sitzungs-Resets — läuft stundenlang, nicht minutenlang |
Architektur-Recherche Studiert echte Codebasen, bevor Designentscheidungen getroffen werden |
| Zwei Qualitätsprüfungen Pläne werden vor dem Coden geprüft; Tests werden danach eigenständig erneut ausgeführt |
Smartes Wissens-Routing Lädt nur das Relevante — nicht jedes Mal die gesamte Wissensbasis |
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
R["RESEARCH\nread-only facts"]
S["SPEC\nrequirements doc"]
I["INNOVATE\n2-3 approaches"]
P["PLAN\ndetailed checklist"]
V["VALIDATE\nplan → contract\n(PVL loop)"]
E["EXECUTE\nimplement\n(EVL loop)"]
U["UPDATE PROCESS\ncapture + archive"]
R -->|"go"| S
S -->|"go"| I
I -->|"go"| P
P -->|"ENTER VALIDATE"| V
V -->|"Gate: PASS"| E
E -->|"gates green"| U
style R fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style S fill:#0277BD,stroke:#01579B,color:#FFFFFF
style I fill:#E65100,stroke:#BF360C,color:#FFFFFF
style P fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style V fill:#558B2F,stroke:#33691E,color:#FFFFFF
style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style U fill:#00695C,stroke:#004D40,color:#FFFFFF
Im interaktiven Modus wartet jede Phase auf dein „go", bevor sie weitermacht — du bleibst bei jedem Schritt eingebunden. Im Autopilot- oder /goal-Modus gibst du die Genehmigung einmal vorab, dann steuert das System sich selbst bis zum Ende. Es stoppt nur bei drei spezifischen harten Stopps, die unten aufgeführt sind. VALIDATE und der Post-EXECUTE Re-Test sind nicht optional — sie sind harte Gates, die schlechte Arbeit vom Ausliefern abhalten — und sie laufen in beiden Modi automatisch.
Vibe Coding hat verändert, wer Software bauen kann. Plan-first Entwicklung verändert, was sie ausliefern können.
| der Vibe-Coding-Nutzer sind KEINE Entwickler | Citizen Developer weltweit (38% jährliches Wachstum) |
| Vibe-Coding-Markt wächst jährlich um 38% |
der YC W25 Startups hatten Codebasen mit über 95% KI-generiertem Code |
Die meisten Tools helfen dir, ein Projekt zu starten. Dieses Kit hilft dir, es fertigzustellen — mit Plänen, die dein Team prüfen kann, Wissen, das nie veraltet, und Sicherheitsprüfungen, die Fehler abfangen, bevor sie ausgeliefert werden.
|
CEO / Gründer „Bau mir ein SaaS mit Auth, Billing und einer Landing Page" Der Agent recherchiert deinen Stack, schreibt einen Architekturplan zur Prüfung, implementiert mit Tests und dokumentiert jede Entscheidung für deinen technischen Mitgründer zur späteren Überprüfung. |
Product Manager „Erstelle ein Dashboard mit MRR, Churn und Wachstums-Metriken" Es generiert eine PRD-artige SPEC, holt deine Genehmigung vor dem Coden ein, implementiert nach Spec und archiviert den Plan als durchsuchbare Projekthistorie. |
|
Designer „Passe diesen Figma-Screenshot pixelgenau an" Der design-bewusste Agent analysiert deinen Mockup, implementiert Komponente für Komponente mit deinen Design-Tokens und startet visuelle Vergleichsprüfungen. |
Ingenieur „Refaktoriere das Auth-Modul für RBAC-Unterstützung ohne Ausfallzeit" Es recherchiert deinen aktuellen Auth-Code und wie andere Codebasen RBAC gelöst haben, schreibt einen Migrationsplan, der zeigt, welche Dateien betroffen sein könnten, und implementiert sicher mit Rollback-Hinweisen. |
| Feature | vibecode-pro-max-kit | Superpowers | GSD | gstack |
|---|---|---|---|---|
| Plan-first Lebenszyklus | Vollständiges RIPER-5 (research → spec → innovate → plan → validate → execute → update) | Verpflichtende Workflows | Context-Rot-Fix | Teilweise |
| Phasengesperrte Sicherheit | Agent-Tools sind pro Phase eingeschränkt (read-only Research, kein Schreiben in Innovate) | Skill-basierte Einschränkungen | Phasentrennung | Keine |
| Qualitätsprüfungsschleifen | Zwei — PVL (Plan prüfen) + EVL (Tests eigenständig erneut ausführen) | Pro Skill | Keine automatischen | Keine |
| Multi-Tool-Unterstützung | 7 Tools via AGENTS.md + SKILL.md offene Standards |
Claude Code Plugin | 14 Runtimes | 1 Tool |
| Automatisch verbesserndes Wissen | Thematisch gruppiertes Wissen, nach jeder Funktion aktualisiert | Plugin-Speicher | Festplatten-Zustand | Manuell |
| Teamzusammenarbeit | Gemeinsame Pläne, Specs und Review-Dateien | Solo | Solo | Solo |
| Skills-System | 33 automatisch erkannte, keyword-gematchte bei jedem Prompt | 86 kombinierbare Skills | Meta-Prompting | 23 Rollen-Tools |
| Große mehrphasige Projekte | Umbrella-Pläne + phasenweise innere Schleife mit Regressionsprüfungen | Einzelaufgabe | Einzelaufgabe | Einzelaufgabe |
| Handfreier Modus | Autopilot (3 Spuren) + dauerhaftes /goal-Einverständnis |
Manuell | Manuell | Manuell |
| Installation | 30s curl + automatisch gesteuertes Setup |
Plugin-Marktplatz | npx one-liner | git clone |
Zur Laufzeit-Breite: GSD unterstützt 14 Runtimes. Wir unterstützen 7 tiefgründig — mit vollständigen Agenten-Harnesses, Skill-Erkennung und Lifecycle-Hooks auf jeder Plattform. Breite vs. Tiefe: deine Wahl.
|
Phasengesperrte Tool-Einschränkungen Dein Agent kann während der Recherche buchstäblich keinen Code schreiben. RESEARCH ist read-only, INNOVATE hat kein Write, PLAN/VALIDATE schreiben nur in process/. Echte Fähigkeitsgrenzen, keine Vorschläge.
|
Der leitende Agent berührt nie Code Der Koordinator leitet weiter, überwacht und steuert Schleifen — er bearbeitet nie Quelldateien oder führt Tests selbst aus. Jede Bearbeitung und jeder Testlauf findet innerhalb eines dedizierten Unter-Agenten statt. Keine versteckte Arbeit. |
|
Automatische Skill-Erkennung Vor der Bearbeitung jeder Anfrage werden 33 Skills gescannt und Keywords abgeglichen. Sage „Webhook-Unterstützung hinzufügen" und vc-security + vc-scenario werden automatisch hinzugezogen.
|
Übersteht Sitzungs-Resets Pläne, Berichte, Wissens-Docs und Erkenntnisse liegen alle auf der Festplatte. Der Startup-Hook stellt Genehmigungsgates nach einem Sitzungs-Reset wieder her. Nichts geht verloren. |
|
Selbst-überwachende Schrittsperre Wenn der Agent dabei ist, einen erforderlichen Schritt zu überspringen, hält er sich selbst auf: „PHASE JUMPING PREVENTED." Eine eingebaute Schutzfunktion gegen Abkürzungen. |
Funktioniert mit 7 KI-Coding-Tools Zwei offene Standards — AGENTS.md und SKILL.md — bedeuten keine Adapter, keine Plugins. Starte in Claude Code, wechsle zu Cursor, weiter in Codex.
|
Deine Hauptsitzung ist ein Koordinator (auch Orchestrator genannt), kein Arbeiter. Er macht vier Dinge und nichts anderes:
Deine Anfrage
→ Schritt 0: Skill-Erkennung (33 Skills scannen, Keywords abgleichen, Kandidaten anhängen)
→ Absicht erkennen (Funktion / Bug / Frage / Refactoring / UI) + Unklarheit bewerten
→ Zum richtigen Agenten in einem frischen Context-Fenster weiterleiten
→ Überwachen: Schrittkonformität, Statuscodes, Schleifen steuern
|
Er delegiert, implementiert nie Research → vc-research-agent. Plan → vc-plan-agent. Code → vc-execute-agent. Der Koordinator übergibt den richtigen Kontext und wartet — er erledigt die eigentliche Arbeit nie selbst.
|
Keine versteckte Ausführung — niemals Sobald ein Plan mit einer vereinbarten Checkliste existiert, startet „ENTER EXECUTE MODE" immer vc-execute-agent. Selbst ein einzeiliger Fix läuft durch ihn. Tests laufen nur innerhalb eines dedizierten vc-tester. Das gilt unabhängig von der Änderungsgröße.
|
|
Klare Statuscodes, keine vagen Signale Jeder Unter-Agent endet mit einem von: DONE · DONE_WITH_CONCERNS · BLOCKED · NEEDS_CONTEXT. Der Koordinator ignoriert nie einen Blocker und wiederholt denselben blockierten Ansatz nie dreimal.
|
Er steuert die Behebungsschleifen Unter-Agenten laufen einmal, melden ein Ergebnis und stoppen. Nur der Koordinator startet sie neu. Er steuert sowohl die PVL (plan-prüfen-beheben) als auch die EVL (test-prüfen-beheben) Schleifen und besitzt das gesamte Tracking. |
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
REQ["User request"]
SD["Step 0: Skill Discovery\nscan 33 skills, match keywords"]
INT{"Detect intent\n+ score ambiguity"}
RES["vc-research-agent\n(feature / question)"]
PLN["vc-plan-agent\n(after INNOVATE)"]
VAL["vc-validate-agent\n(PVL loop)"]
EXE["vc-execute-agent\n(EXECUTE)"]
TST["vc-tester\n(EVL loop)"]
UPD["vc-update-process-agent\n(closeout)"]
MON["Monitor\nstatus codes · loop driving\nno inline execution ever"]
REQ --> SD --> INT
INT -->|"feature / research"| RES
INT -->|"plan phase"| PLN
INT -->|"validate phase"| VAL
INT -->|"execute phase"| EXE
EXE -.->|"EVL"| TST
INT -->|"update phase"| UPD
RES --> MON
PLN --> MON
VAL --> MON
TST --> MON
UPD --> MON
style REQ fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style SD fill:#0277BD,stroke:#01579B,color:#FFFFFF
style INT fill:#E65100,stroke:#BF360C,color:#FFFFFF
style RES fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style PLN fill:#558B2F,stroke:#33691E,color:#FFFFFF
style VAL fill:#558B2F,stroke:#33691E,color:#FFFFFF
style EXE fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style TST fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style UPD fill:#00695C,stroke:#004D40,color:#FFFFFF
style MON fill:#37474F,stroke:#263238,color:#FFFFFF
Warum das wichtig ist: Ein Agent, der sowohl entscheiden als auch heimlich bearbeiten kann, wird Wege finden, den Plan zu überspringen. Indem der Koordinator von den Arbeitern (Unter-Agenten) getrennt wird, ist der Prozess strukturell ehrlich — der einzige Weg, Code zu schreiben, ist, die erforderlichen Schritte zu durchlaufen.
| Phase | Was passiert | Agent | Sie sagen |
|---|---|---|---|
| 🔍 RESEARCH | Rein lesende Informationssammlung — Codebasis und Web. Verändert keine Dateien. | vc-research-agent |
(automatisch bei Feature-Anfragen) |
| 📝 SPEC | Anforderungsdokument zur Produktfindung — User Stories, Abnahmekriterien, außer Umfang — zur Prüfung durch Sie, bevor ein Entwurf beginnt. | vc-spec-agent |
go / ENTER SPEC MODE |
| 💡 INNOVATE | 2–3 Ansätze mit Vor- und Nachteilen erkunden. Entscheidungszusammenfassung (gewählt + abgelehnt + Begründung). | vc-innovate-agent |
go |
| 📋 PLAN | Detaillierte Spezifikation schreiben: Berührungspunkte, öffentliche Schnittstellen, welche Dateien angefasst werden dürfen, Nachweise, Übergabe-Zusammenfassung. | vc-plan-agent |
go |
| ✅ VALIDATE | Den Plan in eine vereinbarte Checkliste umwandeln (V1–V7-Prüfpunkte). Ergebnis: PASS / CONDITIONAL / BLOCKED. Führt den PVL-Durchlauf aus. | vc-validate-agent |
ENTER VALIDATE MODE |
| ⚡ EXECUTE | Den Plan genau umsetzen. Fortschrittsnotizen im Phasenbericht, Abweichungsprotokoll, Selbstprüfung. Danach führt der EVL-Durchlauf die Prüfpunkte erneut aus. | vc-execute-agent |
ENTER EXECUTE MODE |
| 🧠 UPDATE PROCESS | Erkenntnisse festhalten, Kontext aktualisieren, Plan archivieren, Abschlussbericht schreiben. | vc-update-process-agent |
(empfohlen nach nicht-trivialen Arbeiten) |
📝 Warum SPEC eine eigene Phase ist: Die meisten Systeme springen direkt von „verstehen" zu „entwerfen". Ein eigener Produktfindungs-SPEC-Schritt bedeutet, dass Sie (oder Ihr Product Manager) genehmigen, was gebaut wird — in einfachen User Stories und Abnahmekriterien — bevor der Agent über das Wie diskutiert. Es ist der günstigste Moment, um ein Missverständnis aufzudecken. (Im inneren Durchlauf eines Phasenprogramms wird SPEC übersprungen — der übergeordnete SPEC gilt für alle Phasen.)
Der SPEC ist der Maßstab. Er beschreibt das erwartete Verhalten in einfachen Worten, die Sie in einer Minute überfliegen können. Jede nachfolgende Phase — Innovate, Plan, Validate, Execute — prüft immer wieder gegen ihn und stellt dieselbe Frage: Bauen wir wirklich das, was Sie angefordert haben? Wenn die Arbeit abzudriften beginnt, ist der SPEC das, was es auffängt.
flowchart TD
U["Sie: was ich wirklich möchte<br>(in eigenen Worten)"] --> S["📝 SPEC<br>erwartetes Verhalten + Abnahme-<br>kriterien — Sie genehmigen"]
S --> I["💡 INNOVATE"]
S --> P["📋 PLAN"]
S --> V["✅ VALIDATE"]
S --> E["⚡ EXECUTE"]
I -.->|"Rückprüfung"| Q{"Ist das, was<br>Sie angefordert haben?"}
P -.->|"Rückprüfung"| Q
V -.->|"Rückprüfung"| Q
E -.->|"Rückprüfung"| Q
Q -->|yes| GO["weiter bauen"]
Q -->|no| S
# 🆕 Feature-Anfrage
You: "add webhook support to the API"
→ Skill discovery surfaces: vc-scenario, vc-security
→ research-agent gathers context (read-only, can't touch code)
→ "go" → spec-agent writes requirements doc → you approve
→ "go" → innovate-agent compares approaches → decision summary
→ "go" → plan-agent writes the plan, listing which files it will touch
→ "ENTER VALIDATE MODE" → validate-agent gates the plan (PVL loop) → Gate: PASS
→ "ENTER EXECUTE MODE" → execute-agent implements → tester re-runs gates (EVL) → reviewer → git-manager
→ Closeout packet: what changed, what's verified, recommended next step
# 🐛 Fehlerbehebung
You: "login redirect is broken"
→ Routes to vc-debugger → gathers evidence FIRST → 2-3 competing hypotheses
→ Systematically eliminates each → root cause with proof chain
→ execute-agent implements the fix → EVL re-test → quality pipeline
# ⏩ Fast mode
You: "ENTER FAST MODE - add rate limiting middleware"
→ Compressed RESEARCH + SPEC + INNOVATE + PLAN + VALIDATE in one pass
→ Mandatory safety pause after VALIDATE → you review → "ENTER EXECUTE MODE"
# 🤖 Autopilot (hands-free)
You: "autopilot full: build a notifications system"
→ ONE consolidated clarification round → provisional /goal block (standing consent)
→ Drives the full RIPER-5 sequence autonomously, pausing only on hard stops
# 🏗️ Großes Programm
You: "build a full testing platform"
→ Umbrella plan + phase plans in a feature folder
→ Each phase inner loop: research → innovate → plan → PVL → execute → EVL → update
→ Progress survives context compaction — durable reports on disk
Vor der Weiterleitung bewertet der Lead-Agent die Mehrdeutigkeit Ihrer Anfrage anhand von 4 binären Signalen (0–4) und wählt eine Stufe. Fragen stellt er nur, wenn sie tatsächlich etwas am weiteren Vorgehen ändern würden.
| Stufe | Wann | Verhalten |
|---|---|---|
| Stufe 0 — stille automatische Weiterleitung | Wertung 0–1, oder Sie sagten „go" / „just do it", oder Sie setzen einen Plan fort | Leitet sofort weiter, keine Fragen |
| Stufe 1 — kurze Zusammenfassung | Wertung 2 | Nennt sein Verständnis und die gewählte Route in einer Zeile, macht dann weiter |
| Stufe 2 — Fragen | Wertung 3+ | Stellt gezielte Mehrfachauswahl-Fragen vor der Weiterleitung |
🧠 Maximal zwei Runden. Ist nach Stufe 2 noch unklar, stellt er eine letzte direkte Frage und leitet dann standardmäßig zum Research-Agent mit dem engstmöglichen Umfang weiter. Klärungsrunden laufen nie endlos. Nach RESEARCH prüft er die Absicht erneut — zeigt die Recherche, dass die Anfrage anders war als angenommen, wird sie neu aufgegriffen; ist sie bestätigt, geht es ohne Nachfragen weiter.
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
REQ["Benutzeranfrage"]
SCORE{"Mehrdeutigkeitswert\n0–4 binäre Signale"}
AUTO["Auto-Überspringen-Bedingungen\n(go / continue / mid-phase\n/ trivial / explicit mode\n/ resuming plan / pure info)"]
T0["Stufe 0\nstille automatische Weiterleitung\n(Wert 0–1 ODER auto-skip)"]
T1["Stufe 1\nkurze Zusammenfassung\n(Wert 2)"]
T2["Stufe 2\ngezielte Fragen stellen\n(Wert 3+)"]
ROUTE["An passenden Agent weiterleiten\n(research / plan / execute / …)"]
STILL{"nach Stufe 2\nnoch unklar?"}
FINAL["Eine letzte direkte Frage\n(max. 2 Klärungsrunden)"]
NARROW["Standard: vc-research-agent\nengstmöglicher Umfang"]
REQ --> AUTO
AUTO -->|"auto-skip matches"| T0
AUTO -->|"no auto-skip"| SCORE
SCORE -->|"0–1"| T0
SCORE -->|"2"| T1
SCORE -->|"3+"| T2
T0 --> ROUTE
T1 --> ROUTE
T2 --> STILL
STILL -->|"resolved"| ROUTE
STILL -->|"still unclear"| FINAL --> NARROW
style REQ fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style AUTO fill:#0277BD,stroke:#01579B,color:#FFFFFF
style SCORE fill:#E65100,stroke:#BF360C,color:#FFFFFF
style T0 fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style T1 fill:#558B2F,stroke:#33691E,color:#FFFFFF
style T2 fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style ROUTE fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style STILL fill:#F57F17,stroke:#F9A825,color:#000000
style FINAL fill:#AD1457,stroke:#880E4F,color:#FFFFFF
style NARROW fill:#00695C,stroke:#004D40,color:#FFFFFF
Die meisten Systeme prüfen einmal — wenn überhaupt. Dieses System umschließt EXECUTE mit zwei unabhängigen Durchläufen — einen vor dem Schreiben von Code, einen danach.
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '15px', 'lineColor': '#8888AA'}} }%%
flowchart TD
PLAN["📋 PLAN geschrieben"]
PVL{"✅ PVL\nPlan prüfen\nV1–V7-Prüfpunkte"}
PASS["Gate: PASS"]
SUPP["📝 plan-agent ergänzt\n(behebt Lücken)"]
EXEC["⚡ EXECUTE\nPlan umsetzen"]
EVL{"🧪 EVL\ntester führt die\nvalidate-contract-Prüfungen erneut aus"}
FIX["⚡ execute-agent\nErgänzung (Prüfung beheben)"]
DONE["🧠 UPDATE PROCESS"]
PLAN --> PVL
PVL -->|"CONDITIONAL / BLOCKED"| SUPP
SUPP -->|"re-run from V1"| PVL
PVL -->|"PASS"| PASS
PASS -->|"ENTER EXECUTE"| EXEC
EXEC --> EVL
EVL -->|"gate fails"| FIX
FIX -->|"re-run"| EVL
EVL -->|"all gates green"| DONE
style PLAN fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style PVL fill:#558B2F,stroke:#33691E,color:#FFFFFF
style PASS fill:#00695C,stroke:#004D40,color:#FFFFFF
style SUPP fill:#E65100,stroke:#BF360C,color:#FFFFFF
style EXEC fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style EVL fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style FIX fill:#AD1457,stroke:#880E4F,color:#FFFFFF
style DONE fill:#00695C,stroke:#004D40,color:#FFFFFF
Vor EXECUTE führt vc-validate-agent den Plan durch V1–V7-Prüfpunkte — verteilt auf mehrere Agents, die Infrastruktur, Testabdeckung, grundlegende Änderungen, Sicherheit und Machbarkeit je Abschnitt prüfen. Ein CONDITIONAL oder BLOCKED im ersten Durchlauf ist nie das Ende — es führt zurück zu vc-plan-agent, um den Plan zu aktualisieren, dann erneut ab V1.
Verfolgt von vc-autoresearch (domain: plan) — ein Lücken-suchen-und-beheben-Durchlauf. 10-Runden-Limit. Plateau-Erkennung. Nur Gate: PASS (oder ein CONDITIONAL, das Sie ausdrücklich akzeptieren) schaltet EXECUTE frei.
|
Nachdem EXECUTE meldet, fertig zu sein — auch wenn es behauptet, alle Prüfpunkte sind grün — startet der Lead-Agent immer vc-tester, um die exakt vereinbarten Checklisten-Testbefehle unabhängig erneut auszuführen. Ein fehlgeschlagener Prüfpunkt führt zu einer gezielten vc-execute-agent-Korrektur, dann wird erneut getestet.
Verfolgt von vc-autoresearch (domain: tests). 10-Runden-Limit. Die eigene interne „iterate until green"-Schleife des execute-agents ersetzt diese unabhängige Bestätigung niemals.
|
💎 Die Ergebnisleiter: PASS → weiter · CONDITIONAL → behebbare Lücken; der Durchlauf startet (oder Sie akzeptieren sie protokolliert) · BLOCKED → ein tieferes Problem; zurück zu PLAN (im Autopilot-Betrieb: die Lücke kommt ins Backlog, der Durchlauf läuft weiter).
Sowohl PVL als auch EVL nutzen dieselbe Tracking-Schicht: vc-autoresearch — ein Lücken-suchen → beheben → wiederholen-Durchlauf. Der Lead-Agent steuert den Durchlauf — er besitzt den Rundenzähler, Berichte je Runde, das TSV-Protokoll sowie Plateau-/Limit-/Regressionsprüfungen. Worker-Agents sind Fire-and-Forget: Sie geben ein Ergebnis zurück und stoppen. Kein Agent startet sich selbst neu oder startet einen anderen Phasen-Agent.
Dieselbe Engine kann eigenständig laufen: „Diese Spezifikation härten", „alle Lint-Fehler beheben", „Testabdeckung verbessern", „diese Dokumentation verbessern" — jede wiederholte Lücken-suchen-und-beheben-Aufgabe in 6 Bereichen (spec · tests · ux · docs · plan · errors).
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
START["Durchlauf starten\n(orchestrator init results.tsv\nheader + baseline row)"]
FIND["Lücken suchen\n(validate-agent / tester\nreturns gap list)"]
RPT["Iterationsbericht schreiben\n{slug}-iteration-{NNN}_REPORT_{dd-mm-yy}.md"]
TSV["results.tsv-Zeile anhängen\n(cycle N, gap count)"]
FIX["Lücken beheben\n(plan-agent supplement\nOR execute-agent supplement)"]
CHK["Schutzprüfungen\nplateau? cap hit? regression?"]
RECHECK["Erneut prüfen\n(re-run validate / tester)"]
SUCC["ERFOLG\n2 aufeinanderfolgende Runden ohne Befund"]
HALT["HALT\nplateau / 10-cycle cap / regression"]
START --> FIND --> RPT --> TSV --> FIX --> CHK
CHK -->|"safe to continue"| RECHECK
RECHECK --> FIND
CHK -->|"plateau / cap / regression"| HALT
FIND -->|"no gaps found (×2)"| SUCC
style START fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style FIND fill:#E65100,stroke:#BF360C,color:#FFFFFF
style RPT fill:#558B2F,stroke:#33691E,color:#FFFFFF
style TSV fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style FIX fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style CHK fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style RECHECK fill:#0277BD,stroke:#01579B,color:#FFFFFF
style SUCC fill:#00695C,stroke:#004D40,color:#FFFFFF
style HALT fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
| Modus | Tut | Stoppt wenn |
|---|---|---|
vc-autoresearch (Kern) |
Lücken suchen → beheben → wiederholen | keine Lücken gefunden ODER Metrikziel erreicht |
vc-autoresearch:probe |
8 Personas befragen das Korpus bis zur Sättigung | keine neuen Einschränkungen für 3 Runden |
vc-autoresearch:reason |
gegnerische Debatte mit blinden Richtern | Richter konvergieren oder Iterationslimit erreicht |
vc-autoresearch:evals |
TSV-Ergebnisse analysieren — Trends, Plateaus, Empfehlungen | nur Analyse |
Stoppbedingungen: SUCCESS (2 aufeinanderfolgende Runden ohne Befund) · HALT_PLATEAU (3 Runden ohne Fortschritt) · HALT_CAP (hartes 10-Runden-Limit) · HALT_REGRESSION (eine bisher bestandene Prüfung schlägt fehl).
Bei jedem Phasenübergang ruft der Lead-Agent vc-agent-strategy-compare auf, um zu empfehlen, wie die nächste Phase ausgeführt werden soll — mit Kostenschätzungen.
| Strategie | Wann | Koordination |
|---|---|---|
| Sequenziell | Arbeit hängt vom vorherigen Ergebnis ab | Ein Agent nach dem anderen |
| Parallele Subagents | Unabhängige Dimensionen, Fire-and-Forget | Keine — Lead-Agent sammelt und kombiniert Ergebnisse |
| Workflow | Vorhersehbare Aufteilung der Arbeit über eine Liste | Skriptgesteuerte Schritte |
| Agent-Team | Agents müssen während des Durchlaufs miteinander kommunizieren (z. B. jeder bearbeitet eigene Dateien über 3+ Phasenpläne) | TeamCreate + gemeinsame Aufgabenliste + SendMessage |
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
SS["vc-agent-strategy-compare\n(every phase transition)"]
SC{"signal score\n0–7"}
SEQ["Sequenziell\nein Agent nach dem anderen\n(output feeds next)"]
PAR["Parallele Subagents\nfire-and-forget\n(independent dimensions)"]
WF["Workflow\nscripted steps\nacross a list"]
TEAM["Agent-Team\nTeamCreate + TaskCreate\n+ SendMessage\n(must coordinate mid-run)"]
MC{"welche Phase?"}
OPUS["🔴 opus\n(EXECUTE only)"]
SONNET["🔵 sonnet\n(every other phase)"]
SS --> SC
SC -->|"low / dependent"| SEQ
SC -->|"mid / independent"| PAR
SC -->|"predictable split"| WF
SC -->|"high / must coordinate\nor 3+ phase plans"| TEAM
SS --> MC
MC -->|"EXECUTE / fast-mode\nquick-fix (real code)"| OPUS
MC -->|"Research / Spec\nInnovate / Plan\nValidate / Update\nall reviewers"| SONNET
style SS fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style SC fill:#E65100,stroke:#BF360C,color:#FFFFFF
style SEQ fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style PAR fill:#558B2F,stroke:#33691E,color:#FFFFFF
style WF fill:#00695C,stroke:#004D40,color:#FFFFFF
style TEAM fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style MC fill:#0277BD,stroke:#01579B,color:#FFFFFF
style OPUS fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style SONNET fill:#37474F,stroke:#263238,color:#FFFFFF
⚠️ „Agent-Team" bedeutet die echte Maschinerie — namentlich benannte Teammitglieder, eine gemeinsame Aufgabenliste und agentenübergreifende Nachrichten — nicht schlichte parallele Agents, die als „Team" bezeichnet werden. Es ist verpflichtend (nicht optional) bei der Erstellung von 3+ Phasenplänen und bei Mehr-Datei-Bearbeitungen, bei denen jeder Agent in seinen eigenen Dateien bleiben muss. Nur ein echtes Team kann während des Durchlaufs kommunizieren.
| Phase | Modell | Warum |
|---|---|---|
| EXECUTE (+ fast-mode, quick-fix mit echtem Code) | 🔴 opus | Echte Quelltextbearbeitung, Builds, Migrationen |
| Research · Spec · Innovate · Plan · Validate · Update · alle Prüfer/Forscher | 🔵 sonnet | Planung und Analyse — günstiger, völlig ausreichend |
Wenn Arbeit auf mehrere Agents verteilt wird, verwendet nur der codierende Agent opus. Jeder Prüfer, Forscher, Validator und Planer verwendet sonnet. Der Lead-Agent nennt das Modell jedes Mal, wenn er einen Worker-Agent startet.
Sagen Sie autopilot [task] (oder run autopilot, autonomous mode, ENTER AUTOPILOT MODE) und der Agent führt die gesamte verbleibende RIPER-5-Sequenz mit einer Klärungsrunde vorab aus — danach keine weiteren Pausen, bis er fertig ist.
Überall auslösbar: Autopilot kann zu Beginn einer Sitzung oder an jedem Punkt während einer Sitzung starten. Beim Auslösen liest der Lead-Agent die auf der Festplatte gespeicherten Dateien, um festzustellen, in welcher RIPER-5-Phase Sie sich bereits befinden, und setzt dann dort fort und steuert den Rest selbstständig.
| Zustand auf der Festplatte | Einstiegsphase |
|---|---|
| Keine SPEC-Datei | Start bei RESEARCH |
| SPEC-Datei vorhanden | Weiter nach SPEC (INNOVATE) |
| Plan-Datei vorhanden | Weiter nach PLAN (VALIDATE) |
| Validate-contract mit PASS/CONDITIONAL | Weiter zu EXECUTE |
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
TRG["autopilot trigger phrase\n(anywhere in session)"]
DISK["Gespeicherte Dateien lesen\naktuelle Phase erkennen"]
CLR["EINE konsolidierte\nKlärungsrunde"]
GOAL["Vorläufigen /goal-Block ausgeben\n(≤4000 chars, copy-pasteable\nstanding EXECUTE consent)"]
ACT["AUTOPILOT_ACTIVATED\nAutomatischer Durchlauf beginnt"]
PHASES["Verbleibende Phasen steuern\nRESEARCH → … → UPDATE PROCESS\n(no user pauses)"]
HS1["🛑 Nicht rückgängig zu machende / externe Aktion\nnicht vorab genehmigt"]
HS2["⛔ Cascade BLOCKED\n(mehrere Phasen feststeckend)"]
HS3["💸 Kostenpflichtiger Live-Provider-Test\n(doppeltes Opt-in erforderlich)"]
DONE["Durchlauf abgeschlossen\nAutopilot deaktiviert"]
TRG --> DISK --> CLR --> GOAL --> ACT --> PHASES
PHASES -->|"hard stop 1"| HS1
PHASES -->|"hard stop 2"| HS2
PHASES -->|"hard stop 3"| HS3
PHASES -->|"all phases done"| DONE
style TRG fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style DISK fill:#0277BD,stroke:#01579B,color:#FFFFFF
style CLR fill:#E65100,stroke:#BF360C,color:#FFFFFF
style GOAL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style ACT fill:#558B2F,stroke:#33691E,color:#FFFFFF
style PHASES fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style HS1 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
style HS2 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
style HS3 fill:#B71C1C,stroke:#7F0000,color:#FFFFFF
style DONE fill:#00695C,stroke:#004D40,color:#FFFFFF
You: "autopilot full: add team invitations with email + role management"
→ Reads saved files → detects current phase → enters there
→ ONE consolidated clarification round (scope, hard stops, autonomy boundaries, first-phase strategy)
→ Provisional /goal block emitted (≤4000 chars, copy-pasteable, standing EXECUTE consent)
→ AUTOPILOT_ACTIVATED → drives remaining phases on its own
→ Stops ONLY for hard stops
| Spur | Auslöser | Ablauf |
|---|---|---|
| 🟢 quick | autopilot quick: [task] |
Scouten → Bearbeiten → gezielte Prüfung. Kein Plan, kein Vertrag, kein EVL. |
| 🟡 fast | autopilot fast: [task] |
Komprimiert R→S→I→P→V → EXECUTE + EVL. |
| 🔴 full | autopilot [task] / autopilot full: |
Vollständiges RIPER-5 (Standard). |
Sagen Sie autopilot full: [task] — oder fügen Sie einen /goal-Block ein — und Folgendes passiert alles mit null menschlichem Eingriff:
- Plan-prüfen-und-beheben-Schleife — findet Lücken im Plan, behebt sie und prüft erneut. Bis zu 10 Runden selbstständig.
- Bauen-testen-und-beheben-Schleife — schreibt Code, führt Tests aus, behebt Fehler, führt erneut aus. Bis zu 10 Runden selbstständig. Vertraut dem eigenen „alles grün" nie — ein separater Prüfer (vc-tester) führt jeden Test unabhängig erneut aus, um es zu bestätigen.
- Phasenübergang — bewegt sich von Recherche über Plan zu Code bis fertig, ohne auf Sie zu warten.
- Setzt nach einem Speicher-Reset fort — Pläne, Berichte und Fortschritt liegen als Dateien auf der Festplatte. Nach einer Komprimierung (wenn das Kurzzeitgedächtnis der KI geleert wird) liest die nächste Sitzung diese Dateien und macht genau dort weiter, wo sie aufgehört hat.
- Blockiertes Feature? Beiseitelegen und weitermachen — kann eine Phase nicht aufgelöst werden, schreibt der Agent eine Backlog-Notiz und macht mit dem nächsten Feature weiter. Sie können viele Features parallel betreiben, ohne dass ein Blocker alles stoppt.
- Agent-Teams für parallele Features — mehrere Agents können gleichzeitig separate Features bauen, jeder auf seine eigenen Dateien beschränkt, sodass sie nie kollidieren. Ein blockiertes Feature wird geparkt, nicht zu einem Hindernis für den Rest.
Dies sind die einzigen drei Momente, in denen er anhält und Sie fragt:
- 🛑 Alles, was nicht rückgängig gemacht werden kann oder die Außenwelt erreicht und nicht vorab genehmigt wurde (live gehen, echte Nachrichten senden, Geld abbuchen)
- ⛔ Mehrere Phasen in Folge kommen ohne Fortschritt nicht weiter — eine echte Sackgasse, die Ihre Aufmerksamkeit verdient
- 💸 Ein Test, der echtes Geld bei einem kostenpflichtigen externen Dienst ausgeben würde — er fragt vorher
Verpflichtend, keine Dekoration: Nachdem jede VALIDATE-Phase abgeschlossen ist, muss der Lead-Agent einen kopierfähigen /goal-Block ausgeben, bevor EXECUTE startet. Dies ist eine verpflichtende Übergabedatei — kein optionaler Kommentar.
Formatanforderungen:
| Blocktyp | Pflichtfelder | Hartes Limit |
|---|---|---|
| Post-VALIDATE-Block | SESSION GOAL · Charter+umbrella plan · Autonomy · Hard stop conditions · Next phase · Validate contract · Execute start | ≤ 4000 Zeichen |
| Vorläufiger (Autopilot-)Block | SESSION GOAL · ENTRY PHASE · REMAINING PHASES · CLARIFICATIONS LOCKED · EXECUTE CONSENT · DECISION POLICY · HARD STOPS · TEST GATES · START (+ optionales LANE) | ≤ 4000 Zeichen |
Der /goal-Befehl lehnt Blöcke ab, die länger als 4000 Zeichen sind. Kurz halten — die Pflichtfelder als Struktur nutzen, kein Prosaaufsatz.
Eigenständiger /goal-Modus: Fügen Sie einen /goal-Block in eine neue Sitzung ein, und der Durchlauf setzt bei der in START genannten Phase fort. Klärungen und Entscheidungsregeln sind bereits festgelegt — keine neue Klärungsrunde. Unter einem stehenden /goal entscheidet der Agent bei jedem reversiblen Schritt selbstständig, sendet BLOCKED-Punkte an ein Backlog und schreibt seine eigenen Berichte — aber die Delegation an Worker-Agents bleibt verpflichtend. Autopilot entfernt nur Genehmigungspausen, niemals die no-inline-execution-Regel.
Wird validiert durch validate-autopilot-goal-block.mjs.
Wenn SPEC, INNOVATE oder VALIDATE auf eine Kernannahme trifft, die durch reines Lesen nicht bestätigt werden kann, gibt es VC-FEASIBILITY-PROBE-NEEDED aus und stoppt. Der Lead-Agent startet vc-debugger, um einen echten Test durchzuführen und ein VERDICT zu schreiben:
| Ergebnis | Bedeutung |
|---|---|
| ✅ VIABLE | Annahme hält — Entwurf darf darauf aufbauen |
| ❌ NOT-VIABLE | Annahme ist falsch — dieser Ansatz ist verboten |
| ❓ INCONCLUSIVE | Konnte nicht bewiesen werden — wird als bekannte Lücke weitergeführt |
Jedes Ergebnis enthält eine dreiteilige Designnotiz: was das Ergebnis erlaubt · was es ausschließt · was noch unklar ist — wortgenau zurück in die pausierte Phase eingespielt. Prüfungen sind kostenmäßig klassifiziert (cheap-local / needs-container / needs-live-provider → doppeltes Opt-in / needs-browser / needs-cf), sodass eine kostenpflichtige oder eine gemeinsam genutzte Ressourcenprüfung nie stillschweigend ausgeführt wird.
Das Kit enthält 36 Validatorskripte, die aus „Hat der Agent die Regeln befolgt?" ein klares Bestanden/Nicht-bestanden-Ergebnis machen. Sie laufen nach jeder Phase, die Harness-Dateien berührt, und als verpflichtende Prüfpunkte in UPDATE PROCESS:
| Validator-Familie | Prüft |
|---|---|
vc-audit-vc |
Agent-Parität (Claude/Codex), Skill-Registry, Kit-Portabilität, Agent-Frontmatter |
vc-audit-context |
Kontext-Routing, Discovery-Frontmatter, Skill-Schlüsselwörter |
vc-audit-plans |
Plan-Inventar, Umbrella-Zustand, Phasenvollständigkeit, Phasenberichte, Backlog-Notizen |
| 14 VC-System-Verhaltensvalidatoren | Jeder besitzt ein Bestanden/Nicht-bestanden-Fixture-Paar — strategy-compare-Ausgabe, Abschluss, intent-clarify, Machbarkeitsergebnis, autoresearch-Protokoll und mehr |
Dies sind keine Richtlinien — es sind harte Regeln, die in jeden Agent eingebaut sind.
|
Fortschrittsnotizen, keine Pausen während der Ausführung Während der Codierung schreibt der Agent Fortschrittsnotizen in die Phasenberichtsdatei. Keine Pause mitten im Durchlauf, keine „Weiter oder zurück?"-Abfrage. Tritt ein Problem auf, das eine Planänderung erfordert, stoppt er und kehrt zu PLAN zurück. Andernfalls macht er weiter. |
Nie still abweichen Trifft die Codierung auf ein Problem, das eine Planänderung erfordert, stoppt der Agent sofort, erklärt es und kehrt zu PLAN zurück. Kein stilles Improvisieren. |
|
Datenschutz-Sicherheitshaken Der Agent ist gesperrt vom Lesen von .env-, Anmeldedaten-, SSH-Schlüssel- und .pem-Dateien ohne ausdrückliche Genehmigung.
|
Hochrisiko-Nachweispakete Bei Authentifizierung, Abrechnung, Schema-Migrationen oder Änderungen an öffentlichen APIs verlangt das System ein formelles 5-Datei-Nachweispaket, bevor die Arbeit als „erledigt" gilt — immer manuell, nie automatisch umgangen. |
|
Statuscodes-Disziplin Worker-Agents müssen mit DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT schließen. Blockierungen werden nie ignoriert; Korrektheitsprobleme werden zu Aktionspunkten.
|
Abschluss + Drift-Bewertung Nach der Codierung bewertet ein Abschlusspaket die Dringlichkeit: LOW (leichte Berührung) → MEDIUM (bedeutend) → HIGH (Harness-/Protokolldateien berührt), und empfiehlt den nächsten sicheren Schritt. |
Bevor eine einzige Codezeile geschrieben wird, können drei Spezialist-Skills Probleme aufdecken:
5-Personas-Debatte — vc-predictArchitekt, Sicherheit, Performance, UX und Advocatus Diaboli debattieren Ihren Plan. Liefert ein GO / CAUTION / STOP-Ergebnis, bevor Sie eine Zeile schreiben. |
12-Dimensionen-Randfälle — vc-scenarioZerlegt ein Feature über 12 Dimensionen (Benutzertypen, Eingabe-Extremwerte, Timing, Skalierung, Zustand, Umgebung, Fehler, Authentifizierung, Daten, Integrationen, Compliance, Geschäftslogik). Die Ausgabe dient gleichzeitig als Testspezifikation. |
STRIDE + OWASP-Prüfung — vc-securitySicherheitsprüfung mit zwei Methoden, einschließlich Abhängigkeitsprüfung, Geheimnis-Erkennung und einem Auto-Fix-Modus, der nach Schweregrad sortiert und Kritisches zuerst mit Regressionssicherung behebt. |
Nachweise zuerst, dann Debugging — vc-debuggerSammelt Nachweise → bildet 2–3 konkurrierende Hypothesen → testet jede → dokumentiert den Ausschlussweg. Rät nie — beweist. |
Tests zuerst, dann Code. Die vereinbarte Checkliste (geschrieben, bevor Code angefasst wird) definiert die genauen Tests, die bestehen müssen. Der execute-agent schreibt Code, bis diese Tests grün sind. Dann führt ein separater Prüfer — vc-tester — jeden Test selbstständig erneut aus, um es zu bestätigen. Das eigene „alles grün" des execute-agents wird nie für bare Münze genommen. Am Ende prüft der Reviewer, ob das gesamte Projekt noch zusammen funktioniert, nicht nur das neue Teil.
Der execute-agent schreibt nicht nur Code und ist fertig. Er durchläuft automatisch eine Qualitätspipeline:
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '16px', 'lineColor': '#8888AA'}} }%%
flowchart TD
E["⚡ Execute-Agent\nSetzt den Plan um"]
SR["🔎 Selbstprüfung\nZeile-für-Zeile-Prüfung\ngegen den Plan"]
T["🧪 Tester (EVL)\nDiff-sensitiv — führt die\nvertrag-Prüfpunkte erneut aus"]
CR["🔍 Code-Reviewer\nRandfall-Scout\n+ gegnerische Prüfung"]
CS["✨ Code-Vereinfacher\nKlarheits-Refactoring"]
GM["📦 Git-Manager\nLogische Commit-Aufteilung\naus touched_files"]
E --> SR --> T --> CR --> CS --> GM
style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style SR fill:#AD1457,stroke:#880E4F,color:#FFFFFF
style T fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style CR fill:#283593,stroke:#1A237E,color:#FFFFFF
style CS fill:#00695C,stroke:#004D40,color:#FFFFFF
style GM fill:#37474F,stroke:#263238,color:#FFFFFF
| Schritt | Was er tut |
|---|---|
| 🔎 Selbstprüfung | Prüft jeden Checklisten-Punkt gegen den Plan, protokolliert jede Abweichung |
| 🧪 Tester (EVL) | Führt die vereinbarten Checklisten-Tests unabhängig erneut aus; ordnet geänderte Dateien → Testdateien zu, eskaliert zur vollständigen Suite wenn >70 % zugeordnet |
| 🔍 Code-Reviewer | Sendet vor der Prüfung einen Randfall-Scout aus; prüft N+1-Abfragen, Auth-Pfade, Datenlecks |
| ✨ Vereinfacher | Bereinigt den Code nach der Prüfung für mehr Klarheit — keine Verhaltensänderungen |
| 📦 Git-Manager | Empfängt touched_files, teilt in logische konventionelle Commits auf, lehnt unbekannte Dateien ab |
Jedes nicht-triviale Feature folgt einem Plan-Lebenszyklus — ein schriftliches Konzept, das erstellt, geprüft, umgesetzt und anschließend als dauerhafte Projekthistorie archiviert wird.
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '16px', 'lineColor': '#8888AA'}} }%%
flowchart TD
A["🆕 Feature-Anfrage"]
B["📝 Plan erstellt\nin active/{slug}_{date}/"]
C{"👀 Nutzer prüft\nden Plan"}
D["✅ VALIDATE\n(PVL gates)"]
E["⚡ Execute + EVL"]
F["📦 Plan archiviert\nnach completed/"]
G["🧠 Erkenntnisse →\nall-context.md"]
H["🔄 Nächstes Feature\nstartet klüger"]
A --> B --> C
C -->|"✏️ Needs Changes"| B
C -->|"✅ Approved"| D --> E --> F --> G --> H
H -.->|"context compounds"| A
style A fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style B fill:#E65100,stroke:#BF360C,color:#FFFFFF
style C fill:#F57F17,stroke:#F9A825,color:#000000
style D fill:#558B2F,stroke:#33691E,color:#FFFFFF
style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style F fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style G fill:#00695C,stroke:#004D40,color:#FFFFFF
style H fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
💡 Wenn jemand in sechs Monaten fragt „Warum haben wir die Authentifizierung so gebaut?", findet sich die Antwort in
completed/. Nicht verloren in einem Chat-Thread.
Wo Pläne abgelegt werden — Task-Ordner-Konvention:
process/
├── general-plans/
│ ├── active/
│ │ └── webhooks_28-05-26/ # 📋 Task-Ordner: Plan + zugehörige Berichte/Referenzen
│ │ └── webhooks_PLAN_28-05-26.md
│ ├── completed/ # ✅ Archiviert (durchsuchbare Historie)
│ └── backlog/ # 📌 Zurückgestellte Arbeit
└── features/
└── billing/ # 🏷️ Feature-spezifisch (5+ Artefakte)
├── active/{slug}_{date}/
├── completed/
└── backlog/
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
PC["vc-plan-agent creates task folder\nprocess/general-plans/active/{slug}_{date}/\nOR features/{feature}/active/{slug}_{date}/"]
PLAN["{slug}_PLAN_{dd-mm-yy}.md\n— plan file\n— Validate Contract appended here"]
REF["{slug}_REF_{dd-mm-yy}.md\n— optional references"]
RPT["{slug}-iteration-{NNN}_REPORT_{dd-mm-yy}.md\n— per PVL/EVL cycle report"]
TSV["results.tsv\n— rolling loop log\n(header + baseline + cycle rows)"]
PP["PHASE PROGRAM extras"]
UMB["umbrella_PLAN_{dd-mm-yy}.md\n— Program Goal Charter\n— /goal block"]
PHN["phase-N_PLAN_{dd-mm-yy}.md\n— one file per phase"]
REG["phase-blast-radius-registry.md\n— per-phase file ownership"]
PC --> PLAN
PC --> REF
PC --> RPT
PC --> TSV
PC --> PP
PP --> UMB
PP --> PHN
PP --> REG
style PC fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style PLAN fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style REF fill:#558B2F,stroke:#33691E,color:#FFFFFF
style RPT fill:#E65100,stroke:#BF360C,color:#FFFFFF
style TSV fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style PP fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style UMB fill:#00695C,stroke:#004D40,color:#FFFFFF
style PHN fill:#00695C,stroke:#004D40,color:#FFFFFF
style REG fill:#37474F,stroke:#263238,color:#FFFFFF
Jeder Plan enthält: 📍 Berührungspunkte (erstellte/geänderte Dateien) · 📜 öffentliche Verträge · 💥 welche Dateien er anfassen darf (was brechen könnte, was zu testen ist) · ✅ Nachweise · 🔄 Übergabe-Handoff.
vc-plan-discoveryfindet den richtigen Plan zum Fortsetzen; derpost-write-plan-check-Hook prüft die Plan-Struktur bei jedem Schreiben.
Normale Features nutzen einen einzelnen Plan. Große Mehrphasen-Projekte verwenden ein Phasenprogramm — einen Übersichtsplan plus Einzelpläne pro Phase, die jeweils einen vollständigen 7-stufigen inneren Durchlauf mit eigenen Prüfpunkten und einem gespeicherten Bericht durchlaufen.
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
UP["🎯 Umbrella Plan\nProgram Goal Charter\n(north star · done · scope tiers)"]
P1["📋 Phase 1"]
P2["📋 Phase 2 ..."]
subgraph LOOP["🔁 Per-phase inner loop (skips SPEC)"]
direction TB
R["🔍 Research"]
I["💡 Innovate"]
PL["📋 Plan-supplement"]
PVL["✅ PVL"]
EX["⚡ Execute"]
EVL["🧪 EVL"]
UPD["🧠 Update"]
R --> I --> PL --> PVL --> EX --> EVL --> UPD
end
UP --> P1 --> LOOP
LOOP -.->|"learnings feed\nnext phase"| P2
style UP fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style P1 fill:#E65100,stroke:#BF360C,color:#FFFFFF
style P2 fill:#E65100,stroke:#BF360C,color:#FFFFFF
style R fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style I fill:#E65100,stroke:#BF360C,color:#FFFFFF
style PL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style PVL fill:#558B2F,stroke:#33691E,color:#FFFFFF
style EX fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style EVL fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style UPD fill:#00695C,stroke:#004D40,color:#FFFFFF
| Merkmal | Warum es wichtig ist | |
|---|---|---|
| 🔄 | Erneute Recherche in jeder Phase | Prüft auf Codedrift, liest aktuelle Berichte, aktualisiert Annahmen |
| ✅ | Prüfpunkte pro Phase | Eine Phase gilt erst als abgeschlossen, wenn Nachweise vorliegen. Ehrlicher Status: PLANNED → CODE DONE → TESTING → VERIFIED oder BLOCKED |
| 📄 | Gespeicherte Berichte | Jede Phase schreibt Ergebnisse auf die Festplatte — Fortschritt überlebt einen Speicher-Reset |
| 🧠 | Erkenntnisse fließen vorwärts | Entdeckungen aus Phase 1 aktualisieren den Plan für Phase 2, bevor die Programmierung beginnt |
| 🏗️ | Fundament vs. Erweiterung | Trennt klar „Architektur beweisen" von „alles umsetzen" |
| 🚧 | Ehrlicher Umgang mit Blockierungen | Feststeckende Phasen bleiben BLOCKED mit Nachweisen. Kein grüner Status auf Lüge |
Der zu Beginn erstellte Plan ist eine grobe Karte, kein fixer Vertrag. Während das Programm läuft, passt er sich an — so muss man nicht jeden Schritt im Voraus vorhersagen.
Es kann mitten im Lauf eine neue Phase einfügen.
Beim Arbeiten kann der Agent einen fehlenden Schritt entdecken — etwas, das vor der nächsten Phase erledigt sein muss. In diesem Fall fügt er direkt dort eine neue Phase ein, nummeriert die übrigen neu und macht weiter. Kein Mensch muss eingreifen. (Internes Signal: MID_PROGRAM_PLAN_CREATED — der neue Plan wird automatisch auf die Festplatte geschrieben und zur Registry hinzugefügt.)
Es kann Phasen umordnen.
Recherchen zeigen manchmal, dass die geplante Reihenfolge falsch ist — zum Beispiel wenn Phase 3 auf etwas angewiesen ist, das erst Phase 4 liefert. Der Agent ordnet die verbleibenden Phasen neu an und hält fest, warum. (Internes Signal: PHASE_RESTRUCTURE_NOTICE — als Prüfprotokoll im Phasenbericht gespeichert, nicht als Blockierung.)
Er aktualisiert den Plan jeder Phase kurz vor der Programmierung. Bevor eine Phase mit dem Programmieren beginnt, prüft eine kurze Recherche, was das Programm bisher gelernt hat. Anschließend wird die Checkliste dieser Phase mit neuen Erkenntnissen ergänzt. Dieser Schritt heißt plan-supplement. Pläne sind niemals eingefroren — sie nehmen aktuelle Erkenntnisse aus früheren Phasen auf.
Er überspringt Arbeit, die noch nicht beginnen kann. Wenn eine Phase von etwas abhängt, das noch nicht bereit ist — ein Dienst, der noch nicht gebaut wurde, eine Entscheidung, die noch nicht gefallen ist — markiert der Agent diese Phase als abhängigkeitsblockiert, legt sie beiseite und geht zur nächsten über. Das gesamte Programm kommt nicht zum Stillstand, weil eine Phase wartet.
Er weiß, wann er stoppen und fragen muss. Eine einzelne feststeckende Phase wird einfach im Backlog geparkt und das Programm läuft weiter. Wenn aber mehrere Phasen hintereinander gegen eine Wand stoßen ohne Fortschritt, wertet der Agent das als echte Sackgasse — einen Kaskadenstopp — und hält inne, um zu zeigen, was passiert ist. Eine feststeckende Phase ist normal. Mehrere hintereinander signalisieren, dass etwas strukturell nicht stimmt.
Er führt ein live-Anzeigetafel. Jedes Programm hat einen einseitigen Statusbereich im Übersichtsplan, der zeigt, welche Phase gerade aktuell ist, ob sie abgeschlossen ist und wo der Bericht liegt. Jeder — oder der Agent selbst nach einem Speicher-Reset — kann ihn lesen und genau wissen, wo die Dinge stehen. Außerdem führt er eine einfache Dateiregistrierung, damit zwei gleichzeitig arbeitende Phasen niemals dieselben Dateien bearbeiten.
Eine große Abschlussprüfung. Am Ende des gesamten Programms führt der Agent einen End-to-End-Test durch, der sicherstellt, dass das gesamte Projekt noch zusammenarbeitet — nicht nur jedes einzelne Teil für sich. Individuelle Phasenprüfpunkte beweisen, dass jedes Teil funktioniert; diese abschließende Prüfung beweist, dass die Teile als Ganzes funktionieren.
Lange Aufgaben werden korrekt abgeschlossen — selbst wenn der Speicher der KI zwischendurch zurückgesetzt wird. Plan, Fortschritt und Nachweise liegen in Dateien auf der Festplatte, nicht nur im Kopf des Agenten.
KI-Agenten haben ein begrenztes Arbeitsgedächtnis. Bei einer langen Aufgabe füllt sich dieses und wird komprimiert — Details können verschwimmen. Wenn eine neue Sitzung beginnt (oder der Speicher gelöscht wird), rät der Agent nicht, wo er aufgehört hat. Er liest die Dateien.
So funktioniert das genau:
1. Er schreibt nach jeder Phase einen kurzen Bericht. Wenn eine Phase endet, wird eine Berichtsdatei auf die Festplatte geschrieben. Der Fortschritt liegt in Ihrem Projektordner, nicht nur im Kopf des Agenten. Eine Speicherkomprimierung kann keine Datei löschen.
2. Er führt eine Checkliste der erledigten Schritte. Jeder Phasenplan enthält eine Phase Loop Progress-Liste — Kontrollkästchen für jeden Schritt (Recherche, Plan-Prüfung, Build, Test, Erkenntnisse festhalten). Nach einem Reset liest der Agent diese Kästchen und kennt den genauen nächsten Schritt. Er muss nicht aufgeholt werden.
3. Ein kurzer „Umschlag" zu Beginn jeder Phase. Jeder Worker-Agent (ein fokussierter Helfer, der eine Phase der Arbeit erledigt) beginnt mit dem Ausgeben eines Context Envelope — eine 10-Felder-Notiz: welches Feature, welche Phase, welcher Branch, welche Plandatei, welche Tests auszuführen sind. Das Lesen dauert Sekunden. Der Agent ist bereit, bevor er irgendetwas tut.
4. Er vertraut den Dateien mehr als seinem eigenen Gedächtnis. Bei der Wiederaufnahme prüft der Agent, was tatsächlich im Code und in der Git-Historie steht, verglichen mit dem, was der Plan sagt. Der tatsächliche Zustand gewinnt. Ein veralteter Plan kann den Agenten nicht dazu verleiten, Arbeit zu wiederholen oder Schritte zu überspringen.
5. Eine laufende Anzeigetafel und Berichte pro Runde.
Jede Korrekturrunde (die Plan-Prüfschleife und die Build-Test-Schleife) führt eine results.tsv-Anzeigetafeldatei — eine Zeile pro Runde, die nachverfolgt, wie viele Probleme noch übrig sind. Wenn eine Sitzung mitten in einer Schleife endet, liest die nächste Sitzung den Stand, setzt bei der richtigen Runde an und macht weiter. Keine Runden gehen verloren.
6. Er injiziert beim Fortsetzen eine Erinnerung. Wenn der Speicher komprimiert wird, lädt das System automatisch die aktuelle Statusnotiz in die neue Sitzung. Wenn eine Genehmigung ausstand — etwa ein Prüfpunkt, der ein „Ja" brauchte, bevor es weiterging — weist die Erinnerung darauf hin. Nichts wird stillschweigend übergangen.
💡 Kurz gesagt: Sie können einen Autopilot-Lauf starten, Ihren Laptop zuklappen und Stunden später zurückkehren. Der Agent wird genau dort sein, wo er sein sollte — oder setzt beim letzten gespeicherten Prüfpunkt an, mit Nachweisen auf der Festplatte.
Projektwissen ist in Kontextgruppen organisiert — stabile Wissensbereiche, jede mit einer all-{group}.md-Router-Datei, die den Agenten sagt, was wann zu lesen ist. Agenten folgen dem Router und laden nur das Relevante — nicht jedes Mal die gesamte Wissensbasis.
process/context/
├── all-context.md # 🧭 Root-Router — Architektur, Stack, Muster, Konventionen
├── tests/all-tests.md # 🧪 Test-Runner, Befehle, Debug-Verfahren
├── container/all-container.md # 🐳 Docker, Deployment, Infra-Verfahren
├── uxui/all-uxui.md # 🎨 Komponenten, Design-Token, Muster
├── infra/all-infra.md # 🖥️ Server-Infrastruktur, Deployment
└── {your-domain}/all-{domain}.md # 📚 Jede Domain mit 3+ dauerhaften Docs (automatisch hochgestuft)
| Funktionsweise | |
|---|---|
| 🧭 Router-Muster | Agenten lesen nur, was für ihre Aufgabe relevant ist |
| 📏 Automatische Hochstufung | Themen mit 3+ Docs (oder einer einzelnen Datei, die zu groß wird) erhalten eine eigene Gruppe |
| 🔄 Immer aktuell | Wird von vc-update-process-agent nach jedem nicht-trivialen Feature aktualisiert |
| 🧪 Prüfbar | vc-audit-context prüft Routing, Discovery-Frontmatter und Konsistenz |
| 📨 Context Envelope | Jeder innere-Schleifen-Agent gibt beim Start eine 10-Felder-Notiz aus (Feature → Phase → Sitzungsziel → Branch → Worktree → Kontextgruppe → Blast-Radius-Pakete → aktiver Plan → Test-Runner → Validate-Contract), damit ein frischer Worker-Agent genau weiß, wo er steht |
Das Kit liefert nur den Protokoll-Startwert — Ihre Kontextgruppen werden für Ihr Projekt von
vc-setuperstellt, indem Ihr tatsächlicher Code gescannt wird. Sie sind ein Muster, keine feste Liste.
Wenn sich für ein Thema 5 oder mehr Dateien ansammeln, erhält es einen eigenen Feature-Ordner — einen vollständigen Lebenszyklus-Container.
process/features/{feature}/
├── active/{slug}_{date}/ # 📋 Pläne in Bearbeitung (Berichte/Referenzen nebenan)
├── completed/ # ✅ Archivierte Pläne (durchsuchbare Entscheidungshistorie)
└── backlog/ # 📌 Zurückgestellte Arbeit (Agenten prüfen, bevor sie duplizieren)
| Was passiert | |
|---|---|
| 🆕 | Neue Arbeit beginnt in active/ → Berichte sammeln sich an → Plan wird in completed/ archiviert |
| 📌 | Zurückgestellte Arbeit kommt ins backlog/ — Agenten prüfen es, bevor sie doppelte Pläne erstellen |
| 📦 | Feature-Hochstufung erfolgt automatisch, wenn allgemeine Artefakte 5+ erreichen |
| 🔍 | Jedes Feature hat eine vollständige, in sich geschlossene Historie — Pläne, Entscheidungen, Berichte, Recherchen |
Die 33 Skills fallen in drei Ebenen. Jede SKILL.md deklariert ihre layer + trigger_keywords im Frontmatter, und ein generierter Katalog hält die Erkennung schnell.
|
Actor agents Besitzen eine Phase oder Rolle. Liegen in .claude/agents/ — das sind die 15 Agenten, keine Skills.
|
Contract skills (20) Jeder produziert eine bestimmte Datei oder vereinbarte Ausgabe — vc-generate-plan, vc-validate-findings, vc-autopilot, die Audits. Ergebnisse können überprüft werden.
|
Helper skills (13) Verbessern wie Agenten arbeiten, produzieren selbst keine Datei — vc-scout, vc-sequential-thinking, vc-problem-solving, vc-docs-seeker.
|
Jedes abgeschlossene Feature speist Erkenntnisse zurück in das Kontextsystem — das Wissen baut sich auf, es wird nicht zurückgesetzt.
Die meisten KI-unterstützten Codebasen haben die gegenteilige Eigenschaft: Jede neue Sitzung startet kalt. Der Agent liest dieselben Dateien erneut, entdeckt dieselben Muster neu und trifft dieselben Entscheidungen neu — weil die Erkenntnisse der letzten Sitzung nur in einem Chat-Fenster lebten. Die Antwort des Kits ist kein Prompt-Trick. Es ist ein dauerhaftes Kontextdateisystem (process/context/), das jeder Agent beim Sitzungsstart liest, jeder Validator schützt und jedes abgeschlossene Feature bereichert.
Sechs Monate und viele Speicher-Resets später weiß der Agent immer noch warum Ihre Authentifizierung so funktioniert — weil dieses Wissen auf der Festplatte liegt, geroutet und prüfbar ist, nicht in einer toten Sitzung gefangen.
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
FEAT["Feature ships\n(EXECUTE + EVL complete)"]
UP["UPDATE PROCESS phase\nvc-update-process-agent"]
CTX["process/context/ updated\nsmallest relevant file\n+ all-context.md router"]
AGENT["Next agent spawned\nreads context router\n→ routes to correct group file"]
BETTER["Better next feature\nno re-discovery, no stale patterns"]
FEAT --> UP --> CTX --> AGENT --> BETTER
BETTER -.->|"compounds each feature"| FEAT
style FEAT fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style UP fill:#00695C,stroke:#004D40,color:#FFFFFF
style CTX fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style AGENT fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style BETTER fill:#E65100,stroke:#BF360C,color:#FFFFFF
process/context/ enthält strukturiertes Wissen, das in Themengruppen organisiert ist — Architekturentscheidungen, Programmierstil-Konventionen, Deployment-Schritte, Testmuster, Infrastruktur-Fakten. Im Gegensatz zu einem Chat-Verlauf ist dieses Wissen:
- in jeden Worker-Agenten eingebaut —
vc-context-discoveryleitet jeden gespawnten Agenten zum richtigenall-{group}.md-Router für seine Aufgabe und dann zur kleinsten relevanten Tiefendatei. Ein Recherche-Agent, ein Plan-Agent und ein Programmier-Agent starten alle mit demselben gemeinsamen Verständnis - überlebt einen Speicher-Reset — es liegt auf der Festplatte, nicht in einem Kontextfenster; eine komprimierte Sitzung verliert nichts davon
- ist sowohl von Claude als auch von Codex lesbar —
.agents/skillsist ein Shortcut-Link zu.claude/skills/, sodass dasselbe Kontextsystem beide Agenten ohne Duplizierung bedient
Der Root-Router (all-context.md) verweist auf Gruppen-Router (all-{group}.md), die zur kleinsten relevanten Tiefendatei weiterleiten. Agenten folgen dem Router — sie kodieren Dateipfade nie fest. Das bedeutet, dass Umbenennungen und Gruppenaufteilungen nur Router-Änderungen erfordern, keine codebase-weite Suche.
process/context/
├── all-context.md ← Root-Router (Architektur, Stack, Muster)
├── tests/all-tests.md ← Test-Runner, Debugging, Befehle
├── container/all-container.md ← Docker, Deployment, Infra-Verfahren
├── uxui/all-uxui.md ← Komponenten, Design-Token, visuelle Konventionen
└── {domain}/all-{domain}.md ← Jede Domain mit 3+ dauerhaften Docs (automatisch hochgestuft)
Die Formulierung „lebendige Docs" bedeutet meist „Docs, die wir aktuell halten wollen, aber meistens vergessen." Dieses System erzwingt die Absicht mechanisch.
Die UPDATE PROCESS-Phase erfordert eine dateibezogene Kontextprüfung, bevor sie abgeschlossen werden kann. vc-update-process-agent kann eine Phase erst abschließen, wenn jede potenziell betroffene Kontextdatei mit einem konkreten Grund pro Datei geprüft wurde. „Keine Aktualisierungen nötig" ist erlaubt — aber es muss jede geprüfte Datei benennen und erklären warum. Vage Begründungen werden abgelehnt. Der Prüfpunkt ist binär: die Prüfung dokumentieren, oder die Phase schließt nicht.
Die vollständige Rückkopplungsschleife pro abgeschlossenem Feature:
| Schritt | Verantwortlicher | Was passiert |
|---|---|---|
| 1. Git-Diff-Analyse | vc-scout |
Ordnet geänderte Dateien betroffenen Kontextbereichen zu |
| 2. Datei-bezogene Prüfung | vc-update-process-agent |
Benennt jede Kontextdatei, gibt die Aktualisierung oder ein explizites „keine Änderung + Grund" an |
| 3. Aktualisierungen angewendet | parallele Worker-Agenten | Die Kontextdatei jedes Bereichs wird mit neuen Mustern, Entscheidungen, Erkenntnissen aktualisiert |
| 4. Routing verifiziert | validate-context-discovery.mjs |
Bestätigt, dass jedes Dokument indiziert und Router konsistent sind |
| 5. Erkennung bestätigt | validate-all-context.mjs |
Bestätigt, dass all-context.md und Gruppen-Router zu den aktuellen Dateien auf der Festplatte passen |
Ihr 100. Feature profitiert von allem, was in den ersten 99 gelernt wurde — nicht als Wunsch, sondern als mechanische Garantie.
Jeder Phasenbericht enthält einen ## Forward Preview-Abschnitt, der für den Agenten der nächsten Phase geschrieben wird. Er liefert die genauen Befehle, um grün zu bleiben, Abhängigkeitsänderungen und mitten in der Phase gefundene Dateiänderungen. Der Agent, der Phase 3 übernimmt, muss die Ausgabe von Phase 2 nicht neu lesen und raten, was wichtig ist. Er bekommt eine fokussierte Zusammenfassung.
Das unterscheidet sich von Kontextdokumenten: Kontextdokumente tragen dauerhaftes Wissen (Entscheidungen, die feature-übergreifend gültig bleiben); Forward Preview trägt vorübergehenden Übergabestatus (was die nächste Arbeitssitzung gerade jetzt wissen muss).
Dauerhaftes Wissen veraltet, wenn niemand es prüft. Das Kit liefert Validatoren, die als Teil jedes Phasenabschlusses laufen:
| Validator | Was er findet |
|---|---|
validate-context-discovery.mjs |
Docs, die von keinem Router indiziert werden; defekte Links; fehlende Frontmatter |
validate-all-context.mjs |
all-context.md nicht synchron mit den tatsächlichen Dateien auf der Festplatte |
validate-skill-keywords.mjs |
Skills ohne trigger_keywords- oder layer-Felder (unterbricht Routing Schritt 0) |
validate-protocol-discovery.mjs |
Protokolldateien in process/development-protocols/ ohne Discovery-Frontmatter |
Diese laufen wie automatisierte Prüfungen — ein veraltetes oder verwaistes Dokument schlägt fehl. Das System überwacht seine eigene Gesundheit.
Gruppen werden automatisch erstellt, wenn ein Thema 3+ Docs erreicht oder eine einzelne Datei über ~800 Zeilen geht. Agenten folgen Routern und kodieren Pfade nie fest — das Hinzufügen einer neuen Gruppe (z.B. process/context/billing/all-billing.md) erfordert daher nur eine Router-Aktualisierung, keine Änderungen an jedem Agenten, der Abrechnung erwähnt. Der Router ist die stabile Referenz; die Dateien dahinter können sich frei reorganisieren.
Das Kit startet Kontextgruppen aus Ihrer echten Codebasis (via
vc-setup). Die Gruppen sind keine feste Liste — sie sind ein Muster. Ihr Auth-Bereich, Ihr Infra-Bereich, Ihr Zahlungsbereich werden jeweils zu erstklassig routbarem Wissen, während das Projekt wächst.
Klicken, um die Agenten-Liste zu erweitern
Kern-Workflow-Agenten — einer pro RIPER-5-Phase (R → SPEC → I → P → V → E → UP):
| Agent | Modell | Rolle |
|---|---|---|
🔍 vc-research-agent |
sonnet | Codebase- und Web-Recherche, nur-lesend. Widerspruchsverfolgung eingebaut |
📝 vc-spec-agent |
sonnet | Product-Discovery-Anforderungsdokument vor INNOVATE. Produziert *_SPEC_*.md |
💡 vc-innovate-agent |
sonnet | 2-3 Ansätze vergleichen. Entscheidungszusammenfassung (gewählt + abgelehnt) vor PLAN |
📋 vc-plan-agent |
sonnet | Plan mit Anti-Abkürzungs-Wächtern schreiben. „Ich weiß schon wie" ist kein Plan |
✅ vc-validate-agent |
sonnet | Plan → vereinbarte Checkliste (V1–V7). Prüfpunkt: PASS/CONDITIONAL/BLOCKED |
⚡ vc-execute-agent |
opus | Gemäß Plan umsetzen. Fortschrittsnotizen zum Phasenbericht, Abweichungsprotokoll, Selbstprüfung |
⏩ vc-fast-mode-agent |
opus | Komprimiertes R→S→I→P→V mit einer erforderlichen Sicherheitspause vor EXECUTE |
🔧 vc-quick-fix-agent |
opus | QUICK FIX lane: eine kleine, risikoarme Änderung + eingeschränkte Prüfung, kein Plan/Validate |
🧠 vc-update-process-agent |
sonnet | 7-Phasen-Abschluss: archivieren, Kontext aktualisieren, veraltete Artefakte scannen, Erkenntnisse festhalten |
Spezialisten-Agenten — während EXECUTE oder eigenständig aufgerufen:
| Agent | Rolle |
|---|---|
🐛 vc-debugger |
Sammelt Nachweise, bevor er eine Hypothese bildet. Konkurrierende Hypothesen, Ausschlussketten, Machbarkeitssonden |
🧪 vc-tester |
Änderungsbewusst. Führt vereinbarte Checklisten-Tests erneut aus (EVL). Eskaliert automatisch bei Konfigurationsänderungen |
🔎 vc-code-reviewer |
Schickt einen Grenzfall-Scout VOR der Prüfung. N+1-Erkennung, Auth-Pfad-Prüfung |
✨ vc-code-simplifier |
Bereinigt Code für Übersichtlichkeit ohne Verhaltensänderung |
🎨 vc-ui-ux-designer |
Design-bewusstes Frontend. Kann mitten beim Bauen einen Recherche-Worker spawnen |
📦 vc-git-manager |
Teilt in logische Commits aus touched_files auf. Verweigert unbekannte Dateien |
Klicken, um die Skill-Liste zu erweitern (20 Contract + 13 Helper)
📜 Contract skills (20) — besitzen ein Artefakt: vc-generate-plan · vc-generate-context · vc-generate-spec · vc-generate-closeout · vc-generate-phase-program · vc-audit-context · vc-audit-plans · vc-audit-vc · vc-update · vc-publish · vc-feasibility-test · vc-risk-evidence-pack · vc-test-coverage-plan · vc-validate-findings · vc-autoresearch · vc-intent-clarify · vc-autopilot · vc-agent-strategy-compare · vc-plan-discovery · vc-context-discovery
🛠️ Helper skills (13) — verbessern die Arbeitsweise von Agenten: vc-review-situation · vc-sequential-thinking · vc-problem-solving · vc-scout · vc-debug · vc-docs-seeker · vc-frontend-design · vc-agent-browser · vc-web-testing · vc-setup · vc-predict · vc-scenario · vc-security
⚠️ Namensregel: Verwenden Sie das Präfixvc-NICHT für Ihre eigenen Skills oder Agenten — dieser Namespace ist für kit-gelieferte Dateien reserviert, und der Stale-Removal-Wächter behandelt jedenvc-*-Pfad unter.claude/skills/und.claude/agents/als kit-eigentum. Verwenden Sie stattdessenmy-,team-oderproj-.
| Hook | Was er tut |
|---|---|
🔐 privacy-block.cjs |
Blockiert das Lesen von .env, Anmeldedaten, SSH-Schlüsseln. Erfordert ausdrückliche Genehmigung |
🚫 scout-block.cjs |
Verhindert das Wandern in node_modules/, dist/. Gitignore-Syntax .ckignore |
🧠 session-init.cjs |
Erkennt Stack, injiziert Env, stellt Genehmigungstore nach Komprimierung wieder her |
💉 subagent-init.cjs |
Injiziert einen kompakten Kontextblock in jeden Subagenten |
✨ post-edit-simplify-reminder.cjs |
Nach 5+ Bearbeitungen wird zur Ausführung des Simplifiers aufgefordert (nicht-blockierend, gedrosselt) |
📛 descriptive-name.cjs |
Sprachbewusste Datei-Benennungskonventionen bei jedem Write |
📊 session-state.cjs |
Sitzungsmetriken + Token-Bewusstsein |
📋 post-write-plan-check.mjs |
Validiert Plan-Artefakt-Struktur bei jedem Write in eine *_PLAN_*.md |
🧹 post-commit-lint.mjs |
Prüft Conventional-Commits-Präfix bei jedem git commit |
🔍 stop-validator-sweep.cjs |
Führt Kern-Harness-Validatoren aus, wenn die Sitzung endet |
Wo alles liegt:
your-project/
├── .claude/{agents,skills,hooks}/ # 🤖 15 Agenten · ⚡ 33 Skills · 🪝 10 Hooks
├── .codex/agents/ # 🔄 Gespiegelt für Codex
├── .agents/skills -> .claude/skills # 🔗 Symlink für Codex-Erkennung
├── CLAUDE.md · AGENTS.md # 📋 Orchestrator-Konfiguration + plattformübergreifende Registry
└── process/
├── context/ # 🧠 Automatisch geroutete Wissensbereiche
├── general-plans/ # 📋 Übergreifende Pläne + Task-Ordner
├── features/ # 🏷️ Feature-spezifische Lebenszyklus-Ordner
└── development-protocols/ # 📜 22 gemeinsame Workflow-Dokumente
Zwei leichtere Optionen für Fälle, in denen der vollständige RIPER-5-Prozess mehr ist als die Aufgabe erfordert:
Quick Fix — "quick fix: …"Größer als ein triviales Einzeiler-Script, kleiner als „braucht einen Plan." Der Lead-Agent recherchiert nur-lesend → einzeilige Bestätigung → spawnt vc-quick-fix-agent für die Änderung + eine eingeschränkte Prüfung nur der geänderten Dateien. Kein Plan, keine vereinbarte Checkliste, kein EVL.
Wird sofort abgebrochen, wenn die Änderung Schema, Auth, API, Abrechnung oder Migrationsbereiche berührt — dann wird zur vollständigen RESEARCH weitergeleitet. |
Fast Mode — "ENTER FAST MODE - …"Komprimiert RESEARCH + SPEC + INNOVATE + PLAN + VALIDATE in einem Durchgang — aber **schreibt dennoch einen Plan, schreibt eine vereinbarte Checkliste und pausiert vor EXECUTE.** Im normalen Fast Mode gibt es eine Pause nach VALIDATE — Sie prüfen, dann sagen Sie „ENTER EXECUTE MODE." Verwenden Sie autopilot fast: [task], um diese Pause zu entfernen und ohne Unterbrechung bis zum Ende zu laufen.
|
| Befehl | Was er tut | Wann |
|---|---|---|
curl … install.sh | bash |
Synchronisiert Kit-Dateien ohne Ihre zu überschreiben; erkennt automatisch Neuinstallation vs. Upgrade und leitet Sie | Erste Installation + jedes Upgrade |
| Run vc-setup | Erkennt Stack, richtet process/ ein, scannt Codebasis tiefgehend, befüllt echten Kontext |
Nach einer Neuinstallation |
| Run vc-update | Berechnet ein präzises Diff, zeigt was sich ändern wird, wartet auf Ihre Bestätigung; migriert alte Pläne/Ordner ohne Datenverlust | Bei jedem Upgrade |
| Run vc-publish (Maintainer) | Veröffentlicht Harness-Änderungen zurück in das Kit-Repo | Beitrag zum Kit selbst |
%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '14px', 'lineColor': '#8888AA'}} }%%
flowchart TD
TRG["EXECUTE complete\nENTER UPDATE PROCESS MODE"]
AGT["spawn vc-update-process-agent"]
A["(a) Archive plan\nactive/ → completed/"]
B["(b) Update process/context/\nsmallest relevant file\n+ all-context.md router"]
C["(c) Tier-1 audits\n(change-type gated)"]
AVC["vc-audit-vc\nharness/agent edits"]
ACX["vc-audit-context\ncontext-doc edits"]
APL["vc-audit-plans\nplan/program edits"]
D["(d) Capture learnings\nto memory"]
E["(e) Write closeout packet\nvc-generate-closeout"]
F["(f) Conventional commit\nvc-git-manager"]
TRG --> AGT --> A --> B --> C
C --> AVC
C --> ACX
C --> APL
AVC --> D
ACX --> D
APL --> D
D --> E --> F
style TRG fill:#1565C0,stroke:#0D47A1,color:#FFFFFF
style AGT fill:#0277BD,stroke:#01579B,color:#FFFFFF
style A fill:#6A1B9A,stroke:#4A148C,color:#FFFFFF
style B fill:#00695C,stroke:#004D40,color:#FFFFFF
style C fill:#E65100,stroke:#BF360C,color:#FFFFFF
style AVC fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style ACX fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style APL fill:#2E7D32,stroke:#1B5E20,color:#FFFFFF
style D fill:#558B2F,stroke:#33691E,color:#FFFFFF
style E fill:#C62828,stroke:#B71C1C,color:#FFFFFF
style F fill:#37474F,stroke:#263238,color:#FFFFFF
💡
vc-updatezeigt eine Vorschau des Diffs und wartet auf Ihre Bestätigung. Ihrprocess/-Verzeichnis und projektspezifische Inhalte werden niemals stillschweigend geändert. Die Installation erneut auszuführen ist sicher.
Viele kleine, kluge Standardeinstellungen ergeben weniger Überwachungsaufwand und niedrigere Kosten.
-
Jede Rolle erhält nur die Werkzeuge, die sie braucht. Während der Planung kann der Agent buchstäblich keinen Code bearbeiten — diese Werkzeuge sind abgeschaltet. Das hindert den Agenten daran, vorzupreschen und Dinge zu ändern, bevor der Plan genehmigt ist. Das System lässt es schlicht nicht zu.
-
Das Premium-KI-Modell wird nur dort eingesetzt, wo es zählt. Das Schreiben von Code nutzt das Top-Modell. Planung, Recherche, Überprüfung und Prüfungen verwenden alle ein günstigeres, schnelleres Modell. Das Ergebnis: etwa 60–70 % niedrigere Kosten im Vergleich zum Einsatz des Top-Modells für alles — ohne Qualitätsverlust bei der wichtigen Arbeit.
-
Riskante Annahmen werden getestet, bevor darauf aufgebaut wird. Wenn der Agent nicht sicher ist, ob etwas funktioniert — ein bestimmtes API-Verhalten, ein Bibliotheks-Feature, eine Infrastrukturannahme — führt er zuerst ein kleines echtes Experiment durch. Das Ergebnis ist klar: funktioniert, funktioniert nicht, oder unklar. Dieses Urteil und eine klartextliche Notiz fließen direkt in den Plan ein. Der Agent verbringt keine Stunden damit, auf einer falschen Annahme aufzubauen.
-
Ordentliche, aussagekräftige Sicherungspunkte. Änderungen werden automatisch in sauberen, logischen Abschnitten mit klaren Nachrichten gespeichert. Die Historie ist leicht lesbar und lässt sich Stück für Stück rückgängig machen.
-
Hilfreiche automatische Erinnerungen. Kleine eingebaute Helfer mahnen zu Dingen wie dem Ausführen der richtigen Prüfungen auf geänderten Dateien, dem Einfachhalten von Code und dem Schreiben einer ordentlichen Commit-Nachricht. Die Qualität bleibt hoch, ohne dass Sie sie überwachen müssen.
-
Die selbstverbessernde Schleife kann eigenständig laufen. Dieselbe „Probleme finden, beheben, wiederholen"-Engine, die Plan-Prüfungen und Test-Korrekturen antreibt, funktioniert auch als eigenständiges Werkzeug für jeden unordentlichen Bereich — eine Spezifikation, die Docs, die Tests, eine Fehlerliste. Man braucht kein vollständiges Feature-Build, um es zu nutzen.
-
Eingebauter Nachweis, dass die Workflow-Regeln tatsächlich funktionieren. Das Kit wird mit einer eigenen Test-Suite geliefert: ein Satz von Prüfungen mit bekannt-guten und bekannt-schlechten Beispielen, die beweisen, dass sich die Workflow-Regeln korrekt verhalten. Das System prüft sich selbst. Man muss nicht darauf vertrauen, dass die Leitplanken aktiv sind — man kann die Prüfungen ausführen und sehen.
Wir freuen uns über Beiträge! Siehe CONTRIBUTING.md für Richtlinien.
Schnelllinks:
vibecode-pro-max-kit konzentriert sich auf das spezifikationsgesteuerte Entwicklungs-Framework und die selbstverbessernde Kontextorganisation, ohne Sie mit 80+ Skills zu überladen. Weniger Werkzeuge, mehr Struktur.
MIT