PRP-Methode:Briefe Claude, damit es das Richtige baut

Ein Product Requirement Prompt – ein PRP – ist ein kurzes Dokument, das du schreibst, bevor du Claude bittest, ein Feature zu bauen. Die PRP-Methode: vier Abschnitte, etwa dreihundert Wörter, zwanzig Minuten Schreibzeit – und sie macht aus zwei Tagen Debugging ein bis drei Stunden saubere Umsetzung. Es ist die wirkungsvollste Gewohnheit beim KI-gestützten Bauen, und fast niemand nutzt sie am Anfang.

„Claude, bau mir einen Signup-Flow“ fühlt sich nach Fortschritt an. Ist es nicht. Dieser Beitrag gibt dir die Methode, die vier Abschnitte und einen echten PRP aus meinem eigenen Produkt – Wort für Wort –, damit du die Struktur noch heute Abend kopieren kannst.

Was ist die PRP-Methode?

KI ersetzt nicht das Denken. KI ersetzt das Tippen. Das Tippen war nie der Engpass – der Entwurf dessen, was du tippst, war es. Wenn du Claude eine vage Anweisung gibst, füllt es jede Lücke mit Annahmen: welche Datenbanktabelle, wie deine App aufgebaut ist, was „fertig“ bedeutet. Manche dieser Annahmen werden falsch sein, und du bezahlst dafür mit Debugging-Stunden, die du dir an Abenden und Wochenenden nicht leisten kannst.

Ein PRP schließt die Lücken, bevor das Bauen beginnt. Er ist nicht optional. Der Unterschied zwischen „Claude, bau mir einen Signup-Flow“ und einem sauber strukturierten PRP ist der Unterschied zwischen zwei Tagen Debugging von Schrott und zwanzig Minuten sauberer Umsetzung.

Die vier Abschnitte eines PRP

Ziel. Was du baust, in einem Satz. „Baue einen Signup-Flow, der einen Nutzer anlegt, eine Firma anlegt, beide miteinander verknüpft und eine Willkommens-E-Mail verschickt.“

Kontext. Alles, was Claude wissen muss und nicht ableiten kann: dein Datenbankschema, dein Auth-Anbieter, dein E-Mail-Dienst, dein Frontend-Framework, die bestehenden Muster in deiner Codebasis, Links zur relevanten Dokumentation. Je mehr Kontext du lieferst, desto weniger halluziniert Claude und desto näher ist das Ergebnis an Produktionsqualität.

Umsetzungsplan (Implementation Blueprint). Eine Schritt-für-Schritt-Skizze dessen, was das Feature tun soll. Kein echter Code – das ist Claudes Job –, aber genug Struktur, dass Claude sich nicht verlaufen kann. Das zwingt dich, das Feature durchzudenken, bevor du es delegierst, und gibt Claude Schienen, auf denen es bauen kann.

Validierungsschleife (Validation Loop). Woran du erkennst, dass das Feature funktioniert: die Testfälle, die du durchläufst, die Randfälle, die behandelt werden müssen. Claude kann die Tests auch schreiben – aber du musst festlegen, was getestet wird, bevor Claude sie schreibt, sonst testet es die falschen Dinge.

Ein echter PRP, Wort für Wort

So sah einer für ein Feature aus, das ich in FIKR Space gebaut habe – eine einfache Seite für E-Mail-Benachrichtigungseinstellungen:

Ziel: Baue eine Seite für Benachrichtigungseinstellungen, auf der eingeloggte Nutzer wählen können, welche Arten von E-Mail-Benachrichtigungen sie erhalten: wöchentlicher Digest, Produkt-Updates, Sicherheitswarnungen. Speichere die Einstellungen im Nutzerdatensatz. Standardmäßig alles an.

Kontext:

• Stack: React, TypeScript, Supabase, Tailwind.
• Die bestehende Tabelle users hat die Spalten id, email, created_at. Es muss eine JSON-Spalte notification_preferences mit der Form { digest: bool, updates: bool, security: bool } hinzugefügt werden.
• Der Auth-Kontext liefert den aktuellen Nutzer bereits über den Hook useAuth() in /hooks/useAuth.ts.
• Die Seite liegt unter /settings/notifications. Das Routing ist bereits konfiguriert.
• Folge dem bestehenden Muster der Einstellungsseite unter /pages/settings/profile.tsx für Layout und Formular-Styling.

Umsetzungsplan:

1. Füge die JSON-Spalte notification_preferences per Supabase-Migration zur Tabelle users hinzu. Standardwert: alle drei auf true.
2. Erstelle die Seitenkomponente unter /pages/settings/notifications.tsx.
3. Lade beim Mounten die aktuellen Einstellungen des Nutzers aus Supabase.
4. Rendere drei Toggle-Schalter mit der bestehenden Komponente <Switch>.
5. Bei Änderung eines Schalters 500 ms debouncen, dann in Supabase speichern.
6. Zeige eine Toast-Benachrichtigung bei Erfolg oder Fehler des Speicherns.
7. Behandle den Ladezustand, während der erste Abruf läuft.

Validierungsschleife:

• Einloggen. Zu /settings/notifications navigieren. Alle drei Schalter sollten als an angezeigt werden.
• Einen ausschalten. Die Seite neu laden. Der Schalter sollte weiterhin aus sein.
• Netzwerk trennen. Einen Schalter umlegen. Ein Fehler-Toast sollte erscheinen.
• Wieder verbinden. Erneut umlegen. Es sollte speichern und einen Erfolgs-Toast zeigen.

Das sind etwa dreihundert Wörter. Claude erzeugt die Umsetzung in unter zehn Minuten. Gesamtzeit von „Ich will dieses Feature“ bis „Es ist live in Produktion“: vielleicht neunzig Minuten, inklusive PRP schreiben, Code generieren, manuell testen und deployen.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Was ohne PRP passiert

Vergleiche das mit demselben Feature ohne einen. Du tippst „Bau mir eine Seite für Benachrichtigungseinstellungen“ in Claude. Es produziert etwas. Dieses Etwas weiß nicht, welche Datenbanktabelle es nutzen soll, also erfindet es eine. Es kennt deine bestehende Komponentenbibliothek nicht, also erzeugt es neue Komponenten, die anders aussehen als der Rest der App. Es kennt deine Speicherkonventionen nicht, also speichert es bei jedem Tastendruck. Du verbringst zwei Stunden damit, das meiste von dem, was es dir gegeben hat, umzuschreiben, damit es zu deiner Codebasis passt. Das Feature geht in einem halben Tag live statt in anderthalb Stunden – und der Code, mit dem du am Ende dastehst, ist zu fünfzig Prozent deiner und zu fünfzig Prozent Claudes zusammengeflickte Vermutungen.

Warum sich der PRP schwer anfühlt – und du ihn trotzdem schreibst

Die PRP-Methode fühlt sich am Anfang schwer an. Sie fühlt sich nach mehr Arbeit an, als einfach in Claude zu tippen und zu hoffen. Wenn du das erste Mal einen überspringst und Claude fünfzehnhundert Zeilen erzeugt, die du wegwerfen musst, wirst du es verstehen. Zwanzig Minuten Schreiben ersparen dir vier bis acht Stunden Aufräumen pro Feature, und über einen kompletten Build summiert sich das zum Unterschied zwischen einem Launch in acht Wochen und einem in zwanzig.

Tippen und Hoffen hat einen Namen und ein vorhersehbares Ende – ich habe separat über die Vibe-Coding-Falle geschrieben. Die Kurzfassung: Tempo ohne Struktur fühlt sich nach Fortschritt an, bis es plötzlich keiner mehr ist. Der PRP ist, wie du das Tempo behältst und den Zusammenbruch auslässt.

Und beachte, was der PRP dir unauffällig aufzwingt: Denken. Den Umsetzungsplan zu schreiben heißt, das Feature Schritt für Schritt durchzugehen, bevor Code existiert. Die Validierungsschleife zu schreiben heißt, zu entscheiden, was „funktioniert“ bedeutet, bevor du etwas siehst, das aussieht, als würde es funktionieren. Dieses Denken ist dein Job – es ist der Teil, den KI nicht kann, und der Teil, den das BUILD-Framework gezielt trainiert.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Häufig gestellte Fragen

Was ist ein Product Requirement Prompt (PRP)?

Ein PRP ist ein kurzes Dokument, das du schreibst, bevor du die KI bittest, ein Feature zu bauen. Er hat vier Abschnitte – Ziel, Kontext, Umsetzungsplan und Validierungsschleife – und seine Aufgabe ist es, die Annahmen zu beseitigen, die Claude sonst über deine Datenbank, deine Konventionen und darüber treffen würde, was „fertig“ bedeutet.

Wie lang sollte ein PRP sein?

Etwa dreihundert Wörter für ein mittelgroßes Feature, was ungefähr zwanzig Minuten Schreibzeit kostet. Damit bekommst du ein funktionierendes Feature in ein bis drei Stunden Bauzeit statt derselben Stunden plus zwei Tagen Debugging obendrauf.

Muss ich technisch sein, um einen PRP zu schreiben?

Nein. Der Umsetzungsplan ist Schritt-für-Schritt-Klartext, kein Code – „prüfe, ob die E-Mail bereits existiert, lege den Nutzer an, sende die Willkommens-E-Mail.“ Du beschreibst, was passieren soll und wie du es überprüfst; Claude übernimmt die Umsetzung. Dein Produkt tief zu kennen zählt weit mehr als Syntax zu kennen.

Wie viel Zeit spart die PRP-Methode tatsächlich?

Vier bis acht Stunden Aufräumen pro Feature. Über einen Build von acht Wochen mit einem großen Feature pro Woche summiert sich das dazu, dass du in acht statt in zwanzig Wochen live gehst – dieselben Tools, dieselbe KI, andere Disziplin.