English | 简体中文 | 日本語 | 한국어 | Tiếng Việt | Português | Español | Deutsch | Français | हिंदी

Flowser *Entwickelt von Weltklasse-Ingenieuren, für Vibecoders bei*
*[flowser.ai](https://flowser.ai) — KI-Agenten mit Computern für GTM*
# vibecode-pro-max-kit

Flow like water

"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-Token
Ein 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?

Stars Forks License Contributors CI Version Agents Skills Hooks 7 Tools

Das einfachste, flexibelste und teamfreundlichste Coding-Kit für

Claude Code  Codex CLI  Cursor  Windsurf
Antigravity  OpenCode  GitHub Copilot

Funktioniert mit jedem Tech-Stack, jeder Sprache, jedem Projekt

Tech Stack Row 1
Tech Stack Row 2
Tech Stack Row 3

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.

--- ## ⚡ Loslegen — Ein Befehl, 30 Sekunden > **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.* ```bash curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash ``` Wenn er fertig ist, gibt er eine von zwei Meldungen aus — **lies das Ende der Ausgabe und tue genau das, was dort steht:**

🆕 Neues Projekt

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.

🔄 Vorhandenes Harness (Upgrade)

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.sh` fü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/` und `settings.json` werden niemals gelöscht. Nur kit-eigene Dateien werden geschrieben oder aktualisiert. - **Bestehende Konfiguration?** Wird in `.vibecode-backup/` gesichert; deine `settings.json` wird danach wiederhergestellt. - **Bestehende `CLAUDE.md`?** Wird als `CLAUDE.md.pre-vibecode` gesichert. - **Bestehender `process/`-Ordner?** Wird von der Installation nie angefasst — `vc-setup` / `vc-update` migrieren 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 Installation `ls .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](#-auf-einen-blick) · [Das Problem](#-das-problem) · [Die Lösung](#️-die-lösung) - [Die Vibe-Coding-Revolution](#die-vibe-coding-revolution) · [Für wen ist das gedacht?](#für-wen-ist-das-gedacht) · [Vergleich](#vergleich) · [Was macht das besonders?](#-was-macht-das-besonders) - [Wie es funktioniert: Der Koordinator](#-wie-es-funktioniert--der-koordinator) · [Der RIPER-5 Lebenszyklus](#-der-riper-5-lebenszyklus) · [Absichtsklärung](#-absichtsklärung) - [Die zwei Qualitätsschleifen (PVL + EVL)](#-die-zwei-qualitätsschleifen--pvl--evl) · [Strategievergleich + Modellpolitik](#-strategievergleich--modellpolitik) · [Autopilot-Modus](#-autopilot-modus--handfreies-riper-5) · [Machbarkeits-Prüfungen + Validatoren](#-machbarkeits-prüfungen--das-validator-sicherheitsnetz) - [Eingebaute Sicherheitssysteme](#-eingebaute-sicherheitssysteme) · [Vor-Implementierungs-Intelligenz](#-vor-implementierungs-intelligenz) · [Qualitätspipeline](#-qualitätspipeline--in-die-ausführung-eingebaut) - [Plan-Lebenszyklus](#-der-plan-lebenszyklus) · [Phasenprogramme](#-phasenprogramme--große-projekte-die-nicht-auseinanderfallen) · [Kontext-Gruppen](#-kontext-gruppen) · [Feature-Ordner](#-feature-ordner) · [Skill-Schichten](#-skill-schichten) · [Selbst verbesserndes Gedächtnis](#-selbst verbesserndes-projektgedächtnis) - [Was ist enthalten](#-was-ist-enthalten) · [Quick Fix + Fast Mode](#-quick-fix--fast-mode) · [Kit-Lebenszyklus](#-kit-lebenszyklus-installieren--einrichten--aktualisieren--veröffentlichen) · [Mitwirken](#mitwirken)
--- ## 🎁 Auf einen Blick

🤖

15

Agenten
Einer pro Phase + 6 Spezialisten

⚡

33

Skills
20 Workflow + 13 Helfer, per Keyword gefunden

🪝

10

Hooks
Sicherheitsleitplanken + automatisches Kontext-Laden

📜

22

Protokolle
Gemeinsame Regeln, die alle Agenten befolgen

🛡️

36

Validatoren
Automatisierte Prüfungen, die Fehler vor der Veröffentlichung abfangen

🔧

7

Tools
Claude Code · Codex · Cursor · Windsurf · Antigravity · OpenCode · Copilot

🌍

10

Sprachen
EN · 中文 · 日本語 · 한국어 · VI · PT · DE · FR · ES · हिन्दी

⚡

30s

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
--- ## 🔥 Das Problem 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.** --- ## 🛠️ Die Lösung 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

### Der vollständige RIPER-5 Ablauf — 7 Phasen, jeder Schritt kontrolliert ```mermaid %%{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. --- ## Die Vibe-Coding-Revolution

"Die heißeste neue Programmiersprache ist Englisch."

— Andrej Karpathy

**Vibe Coding hat verändert, wer Software bauen kann. Plan-first Entwicklung verändert, was sie ausliefern können.**

63%

der Vibe-Coding-Nutzer sind KEINE Entwickler

16,2 Mio.

Citizen Developer weltweit
(38% jährliches Wachstum)

4,7 Mrd. $

Vibe-Coding-Markt
wächst jährlich um 38%

25%

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. --- ## Für wen ist das gedacht?

"Es kommt nicht darauf an, wer es getippt hat. Sondern was geliefert wurde."

— Garry Tan, YC

🧑‍💼

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.
--- ## Vergleich | 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. --- ## ⚡ Was macht das besonders?

🔒

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.
--- ## 🧭 Wie es funktioniert — Der Koordinator 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.
```mermaid %%{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. --- ## 📊 Der RIPER-5-Lebenszyklus | 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. ```mermaid flowchart TD U["Sie: was ich wirklich möchte
(in eigenen Worten)"] --> S["📝 SPEC
erwartetes Verhalten + Abnahme-
kriterien — Sie genehmigen"] S --> I["💡 INNOVATE"] S --> P["📋 PLAN"] S --> V["✅ VALIDATE"] S --> E["⚡ EXECUTE"] I -.->|"Rückprüfung"| Q{"Ist das, was
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 ```
### 💻 Beispielsitzungen ``` # 🆕 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 ``` --- ## 🎯 Absichtsklärung 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. ```mermaid %%{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 zwei Qualitätsdurchläufe — PVL + EVL 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. ```mermaid %%{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 ```

📋 PVL — Plan-Validate-Fix

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.

🧪 EVL — Execute-Validate-Fix

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). ### 🔁 vc-autoresearch — Gemeinsame Durchlauf-Engine 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). ```mermaid %%{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). --- ## 👥 Strategievergleich + Modellrichtlinie 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 | ```mermaid %%{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. ### 🧮 Modellauswahlrichtlinie | 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. --- ## 🤖 Autopilot-Modus — Vollautomatisches RIPER-5 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 | ```mermaid %%{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 ``` ### Drei Spuren — Aufwand dem Risiko anpassen | 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). | ### 🌙 Vollautomatisch: Ein Satz, gebaut während Sie schlafen 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. ### Hard Stops werden immer angezeigt (auch im Autopilot) 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 --- ### 🎯 /goal — das Token für den autonomen Durchlauf **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`. --- ## 🔬 Machbarkeitsprüfungen + Das Validator-Sicherheitsnetz ### 🔬 Machbarkeitsprüfungen — Annahme testen, bevor darauf gebaut wird 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. ### 🛡️ 36 Validatoren — mechanische Korrektheit, keine Meinung 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 | --- ## 🛡️ Eingebaute Sicherheitssysteme 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.
--- ## 🔍 Intelligenz vor der Umsetzung Bevor eine einzige Codezeile geschrieben wird, können drei Spezialist-Skills Probleme aufdecken:

🎭

5-Personas-Debatte — vc-predict

Architekt, 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-scenario

Zerlegt 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-security

Sicherheitsprü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-debugger

Sammelt Nachweise → bildet 2–3 konkurrierende Hypothesen → testet jede → dokumentiert den Ausschlussweg. Rät nie — beweist.
--- ## ✅ Qualitätspipeline — in die Ausführung eingebaut **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**:
```mermaid %%{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 | --- ## 📋 Der Plan-Lebenszyklus Jedes nicht-triviale Feature folgt einem **Plan-Lebenszyklus** — ein schriftliches Konzept, das erstellt, geprüft, umgesetzt und anschließend als dauerhafte Projekthistorie archiviert wird.
```mermaid %%{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/ ``` ```mermaid %%{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-discovery` findet den richtigen Plan zum Fortsetzen; der `post-write-plan-check`-Hook prüft die Plan-Struktur bei jedem Schreiben. --- ## 🏗️ Phasenprogramme — Große Projekte, die nicht auseinanderfallen 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.
```mermaid %%{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 |
### 🔀 Das Programm passt sich beim Lernen selbst an 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. --- ### 🧠 Er verliert nie seinen Platz (überlebt einen Speicher-Reset) 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. --- ## 🧠 Kontextgruppen 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-setup` erstellt, indem Ihr tatsächlicher Code gescannt wird. Sie sind ein Muster, keine feste Liste. --- ## 📁 Feature-Ordner 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 | --- ## 🧱 Skill-Ebenen 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.
--- ## 🧠 Selbstverbesserndes Projektgedächtnis 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.
```mermaid %%{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 ``` ### Der Kernmechanismus: `process/context/` als portables, gemeinsames Gedächtnis `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-discovery` leitet jeden gespawnten Agenten zum richtigen `all-{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/skills` ist 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) ```
### Was es selbstverbessernd macht (nicht nur „lebendige Docs") 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.
### Vorschau: Erkenntnisse fließen vorwärts, nicht nur rückwärts 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).
### Validator-Suite verhindert Verfall 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.
### Kontextgruppen organisieren sich selbst 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. --- ## 🤖 Was drin ist
### 15 Agenten
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 |

### 33 Skills (automatisch erkannt)
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äfix `vc-` NICHT für Ihre eigenen Skills oder Agenten — dieser Namespace ist für kit-gelieferte Dateien reserviert, und der Stale-Removal-Wächter behandelt jeden `vc-*`-Pfad unter `.claude/skills/` und `.claude/agents/` als kit-eigentum. Verwenden Sie stattdessen `my-`, `team-` oder `proj-`.
### 🪝 10 Hooks | 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:** ```text 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 ``` --- ## ⚡ Quick Fix + Fast Mode 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.
--- ## 🔄 Kit-Lebenszyklus: Installieren · Einrichten · Aktualisieren · Veröffentlichen | 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 | ```mermaid %%{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-update` zeigt eine Vorschau des Diffs und wartet auf Ihre Bestätigung. Ihr `process/`-Verzeichnis und projektspezifische Inhalte werden **niemals** stillschweigend geändert. Die Installation erneut auszuführen ist sicher. --- ## 💡 Weitere Gründe, warum es einfach funktioniert 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. --- ## Mitwirken Wir freuen uns über Beiträge! Siehe [CONTRIBUTING.md](CONTRIBUTING.md) für Richtlinien.
**Schnelllinks:** - 🐛 [Fehler melden](https://github.com/withkynam/vibecode-pro-max-kit/issues/new?template=1.bug_report.yml) - 💡 [Feature anfragen](https://github.com/withkynam/vibecode-pro-max-kit/issues/new?template=2.feature_request.yml) - ⚡ [Skill einreichen](https://github.com/withkynam/vibecode-pro-max-kit/issues/new?template=3.skill_submission.yml) - 🌐 [Übersetzung hinzufügen](https://github.com/withkynam/vibecode-pro-max-kit/issues/new?template=5.translation.yml)
Contributors
### 🙏 Danksagung 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. --- ## ⭐ Star-Verlauf Star History Chart --- ## 📄 Lizenz MIT