Vibe Build

Was macht Vibe Build?

Ein vollständiger Build-Workflow, den der Agent autonom ausführt. Der Benutzer trifft die Produktentscheidungen; du triffst die Prozessentscheidungen. Frage den Benutzer niemals, den Workflow zu erklären – befolge ihn. Frage den Benutzer nur nach dem, was gebaut werden soll, nach Präferenzen und nach Genehmigung an den Toren.

Die eine Regel

Produktentscheidungen = Benutzereingabe. Prozess = deine. Bevor du den Benutzer etwas fragst, prüfe, ob es eine Produktentscheidung ist. Wenn nicht, entscheide selbst und mach weiter.

Phase 0 — Bootstrap (nur neue Projekte)

1. Identifiziere den Stack. Wenn das Projekt völlig undefiniert ist, stelle genau eine Frage: „Was sollen wir bauen? (Ein Satz reicht).“ Führe kein Interview.
2. Recherchiere den Stack selbst: aktuelle Framework-Versionen, empfohlenes Setup und Standard-Projektstruktur, mithilfe von Websuche und Framework-Dokumentation (nutze die Dokumentations-Suchfunktion des Projekts oder Websuche). Fasse die Entscheidungen in maximal 5 Zeilen zusammen – füge dem Benutzer keine Recherche-Wände ein.
3. Schreibe AGENTS.md im Projektstammverzeichnis mit der Vorlage in references/agentsmd-template.md. Dies ist die Verfassung des Projekts: Jede spätere Phase liest sie vor strukturellen Entscheidungen, damit der Benutzer Konventionen nie neu erklären muss.
4. Installiere temporäre Skills, die das Projekt benötigt (maximal 5), gemäß references/temp-skills.md. Überspringe die Skill-Installation vollständig, wenn das Projekt einfach ist oder deine vorhandenen Skills ausreichen.
5. Melde den Bootstrap in ≤ 15 Zeilen, präsentiere deinen nummerierten Plan und warte auf Genehmigung, bevor du Projektcode schreibst.

Phase 1 — Planung

• Erstelle einen nummerierten, abgegrenzten Plan. Kleine Aufgaben, die du in einer Sitzung erledigen kannst, und explizit aufgeschobene Punkte für später.
• Hole ausdrückliche Genehmigung ein. Wenn der Benutzer den Plan bearbeitet, haben die Änderungen Vorrang.
• Hüte dich vor Vermischung: Beginne nicht mit dem Bauen, während der Plan noch offen ist.

Phase 2 — Bauen

• Befolge Testdisziplin, wenn sie zum Projekt passt: Tests für Logik, manuelle Prüfung für Wegwerf-Kleber. Erfinde keine schweren Test-Frameworks für einfache Builds; überspringe keine Tests für Logik, bei der ein Bug schaden würde.
• Halte Abhängigkeiten minimal. Jede Abhängigkeit ist eine Verbindlichkeit, die der Benutzer erbt – bevorzuge Stdlib/Zero-Dep, außer es gibt einen klaren Nutzen.
• Überprüfe vor jeder strukturellen Entscheidung die AGENTS.md. Committe in kleinen benannten Schritten, damit die Arbeit bisectierbar ist.

Phase 3 — Verifikation (bevor du „fertig“ sagst)

Führe das Projekt aus und beweise dann, dass es funktioniert:

• UI existiert → klicke es in einem echten Browser durch (Playwright oder das Browser-Tool deines Agenten), überprüfe Konsolenfehler, verifiziere die Hauptflüsse Ende-zu-Ende.
• Web-UI → überprüfe die Barrierefreiheit und Interaktionsqualität (Fokus-Zustände, Formulare, Dark Mode, Touch): verwende einen Designrichtlinien-Review-Skill, falls verfügbar, ansonsten Selbstprüfung.
• Authentifizierung, Geheimnisse, Zahlungen oder Benutzereingabe berührt → führe einen Sicherheits-Check durch: Eingabevalidierung, Umgang mit Geheimnissen (niemals Geheimnisse committen; Umgebungsvariablen-Substitution verwenden), Least-Privilege-Standardeinstellungen.
• Beweise vor Behauptungen: berichte, was ausgeführt wurde und was bestanden hat, oder gib Fehler zu und behebe sie zuerst.

Phase 4 — Auslieferung

• „Bereitstellen / live schalten / Vorschau-Link“ → über den dokumentierten Pfad des Projekts bereitstellen. Für Vercel-hostbare Projekte: git-push zum verknüpften Projekt, falls kein Login existiert auf vercel deploy --temporary zurückfallen und die URL zurückgeben.
• Pull-Requests: prägnanter Text – was sich geändert hat, warum, wie zu testen – keine Diff-Erzählung.
• Ein „fertig“-Commit bedeutet, dass Build + Tests auf den gerade gesammelten Beweisen bestehen.

Phase 5 — Temp-Skill-Pflege

Temporäre Skills (Phase 0 Schritt 4) sind projektbezogen. Am Projektende oder wenn sich ein Temp-Skill als allgemein nützlich erweist, empfehle, ihn in das gemeinsame Skills-Verzeichnis des Benutzers zu verschieben (oder zu löschen). Lasse niemals zu, dass Temp-Skills stillschweigend zu permanenten globalen Installationen mutieren.

Token-Sparsamkeit (alle Phasen)

Lies den kleinstmöglichen Dateibereich; lies nicht ganze Dateien erneut, die du bereits gesehen hast. Fasse eine abgeschlossene Phase einmal zusammen, anstatt jeden Schritt zu erzählen. Bevorzuge die Ausführung von Skripten und Tools gegenüber dem Einfügen ihrer Inhalte in den Chat. Lasse Skills lazy per Trigger laden – gib niemals den Körper eines Skills in die Konversation ein.

Referenzen

• references/agentsmd-template.md – während Phase 0 Schritt 3 lesen und ausfüllen.
• references/temp-skills.md – während Phase 0 Schritt 4 lesen, bevor du einen Temp-Skill installierst.