vibe-coding-prompt-template: ein Prompt-Workflow, der vor dem Code ansetzt

Welches Problem die Vorlagen adressieren

Die README formuliert die Ausgangslage in einem Satz: Der Assistent kann Code schreiben, aber die Entscheidung, was überhaupt gebaut werden soll, fällt ihm niemand ab. Genau dort setzt das Repository an. Es liefert keine Bibliothek und keine Laufzeitkomponente, sondern eine Abfolge von Prompts, die eine Produktidee schrittweise in ein Research-Dokument, ein PRD und ein Tech Design überführt. Die Zielgruppe sind laut README ausdrücklich auch Anfänger, das Topic beginner-friendly steht in den Repository-Metadaten neben ai-agents und prompt-engineering. Wer bereits ein klares Bild von Umfang und Stack hat, ist nicht die primäre Zielgruppe. Der Workflow richtet sich an Leute, die mit einem AI-Editor arbeiten und verhindern wollen, dass der Agent ohne Kontext losbaut und nach zwei Stunden Code produziert, der am eigentlichen Bedarf vorbeigeht.

Fünf Schritte, zwei Phasen: der dokumentierte Ablauf

Die README trennt Phase 1 (Denken) von Phase 2 (Ausführen). Phase 1 läuft in einem Chat-Tool wie Claude.ai, ChatGPT oder Gemini, ein Repository ist dafür nicht nötig. Schritt 1 ist Deep Research: part1-deepresearch.md wird komplett kopiert und in den Chat eingefügt, das Modell stellt Rückfragen, das Ergebnis wird als research-[YourAppName].md gespeichert. Schritt 2 ist das PRD aus part2-prd-mvp.md, wahlweise im selben Chat oder in einem neuen, in den dann zuerst das gespeicherte Research-Dokument eingefügt wird. Schritt 3 ist das Tech Design, das laut Tabelle die Oberfläche, den Stack und das Deployment festlegt. Phase 2 beginnt mit Schritt 4: Erzeugen von AGENTS.md und agent_docs/, entweder über npx vibeworkflow oder durch Einfügen der Vorlagen. Schritt 5 ist das eigentliche Bauen im AI-Editor, beschrieben als kleine, jeweils verifizierte Durchgänge. Der Ablauf ist also linear und dateibasiert: Jeder Schritt hinterlässt ein Artefakt, das der nächste Schritt als Eingabe konsumiert.

Der Einstiegspunkt ist ein Satz im Agenten

Der dokumentierte Startbefehl lautet, den Agenten im Projektordner zu öffnen und ihn anzuweisen, npx vibeworkflow auszuführen und den Anweisungen zu folgen. Das CLI wird über npm als Paket vibeworkflow verteilt, die README nennt npx vibeworkflow als Aufruf und verweist auf die Version 0.3.0 für die Slash-Befehle /vibe-change, /vibe-debug und /vibe-verify. Laut README inspiziert der Workflow zuerst, was im Ordner bereits existiert, und leitet daraus eine von drei Routen ab: etwas Neues starten, ein bestehendes Projekt fortsetzen oder etwas ist kaputt. Zusätzlich gibt es drei Plantiefen (Quick, Guided, Deep), die den Umfang der Rückfragen an die Projektgröße anpassen sollen. Das ist der architektonisch interessanteste Teil: Der Ablauf ist nicht statisch, sondern verzweigt abhängig vom Zustand des Verzeichnisses. Für Claude Code verweist die README separat auf .claude/README.md mit eingebauten Skills. Ein Beispielprojekt liegt unter examples/reading-list/README.md.

Was der Workflow nicht prüft

Die Grenze liegt im Wort Prompt. Alle Artefakte entstehen als Text, der von einem Sprachmodell erzeugt wurde, und die README beschreibt an keiner Stelle eine Validierung dieser Artefakte gegen die Realität. Ein PRD, das eine Anforderung erfindet, wird nicht auffallen, weil der nächste Schritt nur den Text weiterverarbeitet. Die README empfiehlt sogar ausdrücklich, bei aktivierter Websuche auf zitierte Aussagen mit Zugriffsdatum zu bestehen, was implizit einräumt, dass die Recherche ohne diese Vorgabe dünn bleiben kann. Ebenso ungeklärt bleibt, was passiert, wenn die Antworten auf die Rückfragen widersprüchlich sind. Der Workflow ist damit das falsche Werkzeug für Aufgaben, bei denen die Anforderung bereits feststeht und nur umgesetzt werden muss, etwa bei einem klar spezifizierten Bugfix oder einer Änderung an einer bestehenden Schnittstelle. Dort erzeugt der Ablauf Dokumentation, die niemand liest, und kostet die Zeit, die er einsparen soll.

Abgrenzung zu Spec-Driven-Development-Werkzeugen

Die naheliegende Alternative ist ein Werkzeug wie GitHub Spec Kit, das ebenfalls mit Vorlagen für Spezifikation, Plan und Aufgaben arbeitet. Der Unterschied liegt im Angriffspunkt. Spec Kit ist um das Repository und die dort vorhandene Codebasis herum gebaut und erzeugt seine Artefakte im Projekt selbst, typischerweise über einen CLI-Befehl, der die Verzeichnisstruktur anlegt. vibe-coding-prompt-template beginnt dagegen außerhalb des Repositories: Die ersten drei Schritte laufen in einem Chat-Tool, ohne dass ein Projektordner existiert, und die Ergebnisse werden als Markdown-Dateien mit vom Nutzer gewählten Namen wie research-[YourAppName].md abgelegt. Der Übergang ins Repository erfolgt erst in Schritt 4 mit AGENTS.md und agent_docs/. Wer bereits Code hat und die Spezifikation daraus ableiten will, ist mit einem repository-zentrierten Ansatz besser bedient. Wer bei Null anfängt und zuerst die Frage klären muss, ob die Idee überhaupt trägt, findet hier den passenderen Einstieg.

Pflegeaufwand und Lizenz

Das Repository steht unter MIT, der entsprechende Badge und der LICENSE-Eintrag sind in der README sichtbar. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, den Lizenztext und den Urheberrechtshinweis beizubehalten. Das ist keine Rechtsberatung; wer die Vorlagen in ein eigenes Produkt einbettet, sollte die Bedingungen selbst prüfen. Zum Pflegeaufwand lässt sich aus den veröffentlichten Versionen etwas ableiten: v2.4.0 erschien im April 2026 als Audit und Hardening, v3.0.0 im Juli 2026 als Contracts Release, v3.1.0 im August 2026 als Agent-First Release. Zwischen den letzten beiden liegt rund ein Monat, und die Versionssprünge deuten auf inhaltliche Umbrüche statt kleiner Korrekturen hin. Wer die Vorlagen forkt und anpasst, muss bei jedem solchen Sprung mit Nacharbeit rechnen, weil sich die Struktur der Artefakte ändern kann. Die README selbst nennt keine Upgrade-Anleitung für angepasste Vorlagen, dieser Punkt bleibt offen.

Wann der Ablauf trägt und wann nicht

Der stärkste Teil ist die Reihenfolge. Deep Research vor PRD vor Tech Design erzwingt, dass die Frage nach Nachfrage und Wettbewerb vor der Stack-Entscheidung beantwortet wird, und das ist in vielen Projekten genau die Reihenfolge, die eingespart wird. Der schwächste Teil ist die Verifikation. Die README verspricht kleine, verifizierte Durchgänge und bietet mit /vibe-verify einen eigenen Befehl an, beschreibt aber nicht, woran ein Durchgang als verifiziert gilt. Genau hier sollte man vor dem Einsatz nachsehen, was der Befehl tatsächlich tut, statt sich auf die Formulierung zu verlassen. Praktisch heißt das: den Workflow in einem kleinen Projekt wie dem mitgelieferten examples/reading-list/README.md durchspielen, die erzeugten Dateien AGENTS.md und agent_docs/ gegen die eigene Erwartung halten und erst dann auf ein größeres Vorhaben anwenden.

Redaktionelles Fazit

Wer mit Claude Code, Cursor, Codex oder Gemini CLI arbeitet und vor dem ersten Commit eine belastbare Spezifikation braucht, findet hier einen strukturierten Ablauf: npx vibeworkflow im Projektordner, danach die Schritte Deep Research, PRD, Tech Design und Agent-Dateien in dieser Reihenfolge. Wer dagegen ein Gerüst für ein bereits klar umrissenes Feature sucht oder lieber direkt im Editor prompft, gewinnt durch die fünf Phasen wenig und sollte zuerst prüfen, ob die Vorlagen tatsächlich zu seinem Stack passen. Vor dem Einsatz ist zu klären, ob die in part1 bis part4 hinterlegten Fragen und der erzeugte agent_docs/-Baum zur eigenen Projektgröße passen, denn genau dort entscheidet sich, ob der Workflow trägt oder nur zusätzliche Dateien erzeugt.

Offizielle Quellen

1. KhazP/vibe-coding-prompt-template on GitHub
2. License: MIT
3. Project website
4. README
5. Releases