In 4 Schritten vom Problem zum fertigen Bauplan.
Eine rohe Idee ist nicht baubar. Zwischen "ich will was" und dem ersten Commit liegen vier kleine Schritte. Wer sie überspringt, baut am Ende das Falsche. Hier sind sie, plus ein Bootstrap-Prompt, der das Setup in deinem Projekt selbst übernimmt.
Vom Problem zum Bauplan in vier Schritten.
Jeder Schritt nimmt das Ergebnis des vorigen und schärft es weiter. Am Ende steht keine Vision-Folie, sondern ein konkreter Bauplan — kleine Pakete, jedes ein bis zwei Tage Arbeit, die du oder dein Coding-Agent der Reihe nach abarbeiten kann.
Mit diesen sechs Fragen zum perfekten Pitch.
Du gibst einen Satz Idee rein. Raus kommt eine kurze Notiz: Problem, wer hat es, grobe Lösung, Ausbaustufe, was du weglässt, was nie reinkommt. Sechs Fragen, sechs Antworten, eine Seite. Ohne diese Seite startet jede weitere Sitzung damit, dass du erstmal klärst, was du eigentlich willst.
Es ist auch der Schritt, an dem du dir selbst auf die Schliche kommst. Manchmal merkst du erst beim Antworten, dass du das Problem noch gar nicht sauber benennen kannst. Besser jetzt als beim dritten Refactoring.
Die 6 Fragen
Eine pro Nachricht, mit Auswahl-Vorschlägen wo es passt. Letzte Option ist immer Freitext.
Was ist das konkrete Problem?
Beschreib eine Situation, kein Feature. Wer macht was, und was geht dabei schief?
Für wen ist das?
Wer erlebt das Problem? Vorschläge kommen aus den Akteuren, die in CONTEXT.md schon stehen.
Was ist deine grobe Idee?
2-3 Sätze, kein Wireframe. Stell dir vor, du erklärst es jemandem in 30 Sekunden am Whiteboard.
Wie ausgebaut soll Version 1 sein?
Klein und schnell — oder gleich richtig? Beides ist eine valide Antwort, je nach Risiko.
Was lassen wir bewusst weg?
Naheliegende Dinge, die jetzt nicht kommen, später aber vielleicht. Vorschläge aus dem Phasen-Plan, falls vorhanden.
Was kommt nie rein?
Etwas, das unter keinen Umständen Teil der Lösung sein darf. Compliance-Hard-Limits, abgelehnte Architektur-Wege, Geschäftsmodell-Rote-Linien. Darf leer bleiben.
Bring dich und Claude auf denselben Stand — bevor der erste Code geschrieben wird.
Hier wird dein Pitch gegrillt. Der Agent liest die Notiz, vergleicht sie mit dem, was schon im Projekt dokumentiert ist, und stellt unbequeme Fragen: Du sagst "Kunde" — meinst du den, der bezahlt, oder den, der das System bedient? Du sagst "stornieren" — kannst du auch nur einen Teil stornieren, oder immer ganz?
Worum es eigentlich geht: dass du und Claude wirklich dasselbe meinen, bevor irgendwer Code anfasst. Klingt banal, ist es nicht. Bug-Reports gegen Features, die der Code gar nicht abdeckt, sind fast immer ein Missverständnis von Begriffen — eines, das schon im Pitch drin saß und keiner gemerkt hat.
Im Gespräch entstehen nebenbei zwei Arten von Dokumenten — keine Hochglanz-Decks, sondern Werkzeuge fürs Bauen.
Das Wörterbuch deines Projekts — damit du dir nicht widersprichst
Gleiche Sache, gleiches Wort. Verhindert, dass aus "Kunde", "User" und "Lead" drei Begriffe für eine Person werden. Eine Tabelle mit Begriff, Definition, Beispiel. Wird live gefüllt, sobald ein Begriff geklärt ist. Du gewinnst dadurch: in jeder neuen Sitzung musst du nicht erklären, was was ist — der Agent liest's selbst nach.
Eine Architektur-Entscheidung mit Begründung — für dein zukünftiges Ich
Wenn du dich später fragst "warum hab ich das eigentlich so gebaut?", steht hier die Antwort. Sparsam einsetzen — nur wenn die Entscheidung schwer rückgängig ist, im Code nicht offensichtlich, und das Ergebnis eines echten Trade-offs. Erspart dir Stunden Archäologie in alten Commits.
Das PRD: das Herzstück, in dem festgehalten ist, was du baust und warum.
PRD ist die Abkürzung für Product Requirement Document — ein Stück Papier mit dem was und dem warum, ohne sich schon am wie festzubeißen. Das wie kommt im nächsten Schritt.
Bis hierher war alles ein Gespräch im Chat-Verlauf. Jetzt wird es ein Dokument, in dem jemand, der nicht dabei war, das Wesentliche in zehn Minuten findet — und das auch du selbst noch verstehst, wenn du in vier Wochen darauf zurückkommst. Kein neues Interview nötig: der Agent synthetisiert aus dem, was schon im Kontext liegt.
Sechs Sektionen, jede beantwortet eine Frage, die beim Bauen wirklich gestellt wird:
- Problem — Wofür baue ich das überhaupt? Aus User-Sicht, eine Situation, kein Feature.
- Lösung — Was ändert sich für den, der's nutzt? Auch aus User-Sicht.
- User Stories — Lange nummerierte Liste. "Als X möchte ich Y, damit Z." Deckt alle Aspekte ab.
- Module — Was wird gebaut oder geändert. Welche Schnittstellen, welche Schema-Änderungen. Keine Datei-Pfade — die veralten zu schnell.
- Tests — Welche Module Tests bekommen, was ein guter Test ist (externes Verhalten, nicht Implementierung).
- Was wir weglassen — Klar benannt. Trennt "vielleicht später" von "gar nicht".
Das PRD aufgeschnitten in kleine Aufgaben, die dein Agent Stück für Stück abarbeitet.
Letzter Schritt vor dem Code-Loop. Das PRD wird in nummerierte Pakete unter .scratch/ geschnitten — jedes ein bis zwei Tage Arbeit. Jedes Paket ist eine dünne Schicht von oben bis unten (Datenbank, Backend, UI, Tests), nicht eine fette Schicht auf einer Ebene. So ist nach jedem fertigen Paket etwas vorzeigbar, nicht nur ein Stapel halber Sachen.
Was du davon hast: Du oder dein Coding-Agent kann morgens an Paket #03 anfangen und am Abend gemerged haben. Keine Tagesplanung, keine Frage "was mach ich jetzt zuerst", kein Reverse-Engineering aus einem Vision-Doc. Der Agent pickt das nächste Paket und legt los.
Pro Paket steht im Dokument:
- • Was es ist — eine Funktion, die nach diesem Paket end-to-end läuft.
- • Wer es bauen kann — die KI alleine, oder braucht es einen Menschen für eine Architektur-Entscheidung oder ein Design-Review.
- • Was es vorher braucht — welches andere Paket muss schon fertig sein.
- • Wie groß es ist — als Daumenregel 1-2 Tage Arbeit pro Paket. Wenn größer: weiter teilen.
Weglassen heißt: später vielleicht. No-Go heißt: nie, auch nicht später — weil es gegen das Geschäftsmodell läuft, rechtlich kippelt, oder eine Entscheidung von früher umstößt, die du nicht umstoßen willst. Beide Listen kommen aus dem Pitch und werden im PRD wieder aufgegriffen.
Bei dir aufsetzen geht in einem Paste — der Prompt baut alles selbst.
Du musst nichts vorbereiten. Kein Git-Repo? Wird angelegt. Kein docs/? Wird angelegt. Keine Prompt-Templates? Werden angelegt. Du pastest, der Prompt prüft, was schon da ist, und legt nur das Fehlende drauf. Bestehende Dateien bleiben unangetastet.
Pastet ihr in einen Coding-Agenten — nicht in den Browser-Chat
Der Prompt schreibt echte Dateien in dein Projekt. Das geht nur dort, wo der Agent Datei-Zugriff hat. In claude.ai im Browser, ChatGPT-Web etc. läuft der Prompt ins Leere — kein File-System dahinter.
Funktioniert
- Claude Code (Terminal-CLI)
- Antigravity (Google's Agent-IDE auf Gemini-3)
- Cursor / Windsurf / Cline (VS-Code-basiert)
Funktioniert nicht
- claude.ai im Browser (kein File-Zugriff)
- Claude Desktop Chat-App (kein File-Zugriff)
- ChatGPT, Gemini-Web, Perplexity
Kopier ihn raus, paste ihn in deinen Agent, fertig.
Drei Phasen: Phase 1 prüft deine Umgebung und legt Ordner und Prompt-Templates an, Phase 2 zeigt dir einen Status-Report, Phase 3 fragt, ob du gleich mit deiner Idee in /pitch reingehen willst. Wenn nicht: einfach n drücken — der Vorgang steht trotzdem in deinem Projekt bereit.
Du bist mein Coding-Agent. Setze in DIESEM Projekt den Vorgang "vom Problem zum Bauplan" auf — vier kleine Schritte: pitch, grill-with-docs, to-prd, to-issues. Quelle: https://mfraunhofer.de/ressourcen/vom-problem-zum-bauplan/
Du arbeitest die drei Phasen strikt der Reihe nach ab. Vor jedem Check selber laufen lassen, nicht den User fragen. Nichts ueberschreiben ohne Rueckfrage. Keine destruktiven Git-Aktionen.
═══════════════════════════════════════
PHASE 1 — UMGEBUNGS- UND VORAUSSETZUNGS-CHECK
═══════════════════════════════════════
Pro Item eine Status-Linie melden: "✓ gefunden" oder "+ angelegt" oder "⚠️ Frage" oder "✗ blockiert". Default-Verhalten: anlegen wenn fehlt, transparent berichten. Bestehendes nicht ueberschreiben. Nur fragen wenn die Aktion irreversibel oder kontextabhaengig ist.
Die ERSTE Status-Linie (Pflicht, immer ganz oben — weglassen ist Bug) ist:
1.0 UMGEBUNG (= File-Schreib-Zugriff im aktuellen Verzeichnis)
Wenn du in Claude Code, Antigravity, Cursor oder Cline laeufst → "✓ 1.0 Umgebung: Schreibzugriff im aktuellen Verzeichnis bestaetigt."
Wenn du in einem reinen Browser-Chat (claude.ai, ChatGPT, Gemini-Web, Perplexity) laeufst → "✗ 1.0 Umgebung: Browser-Chat ohne File-Zugriff — abbrechen, Prompt in Claude Code / Antigravity / Cursor / Cline neu laufen lassen." Dann sofort stoppen, keine weiteren Phasen.
1.1 GIT-REPO
Check: `git rev-parse --is-inside-work-tree 2>/dev/null`
✓ → ok
✗ fehlt → FRAGEN: "Soll ich `git init` machen?" Nicht selber starten — koennte versehentlich im Home-Ordner laufen. User-OK abwarten, dann ausfuehren.
1.2 docs/ — anlegen wenn nicht da
1.3 docs/pitches/ — anlegen wenn nicht da
1.4 docs/prompts/ — anlegen wenn nicht da
1.5 .scratch/ — anlegen wenn nicht da
1.6 CONTEXT.md im Repo-Root
Check: existiert die Datei?
✗ fehlt → mit folgendem Inhalt anlegen:
# CONTEXT.md
Das Woerterbuch dieses Projekts. Gleiche Sache, gleiches Wort.
Wird gefuellt, sobald ein Begriff geklaert ist — nicht im Voraus.
## Begriffe
| Begriff | Definition | Beispiel |
|---------|------------|----------|
| _Beispiel-Eintrag_ | _Eine Zeile, fachlich, nicht technisch_ | _ein konkretes Vorkommen_ |
## Akteure
_Wer benutzt das System? Liste, sobald geklaert. Beispiel:_
_- Werkstatt-Mitarbeiter — sieht eingehende Buchungen, akzeptiert oder lehnt ab_
1.7 PROMPT-TEMPLATES anlegen unter docs/prompts/
Vier Dateien, jede mit dem unten gegebenen Inhalt. Nur anlegen wenn nicht da, nicht ueberschreiben.
────────────────────────────────────
INHALT docs/prompts/pitch.md:
────────────────────────────────────
# /pitch — Aus einer Idee einen strukturierten Pitch machen
Du fuehrst mich durch 6 kurze Fragen, eine nach der anderen. Bei jeder Frage: Empfehlung nennen, dann meine Antwort abwarten. Auswahl-Optionen wo es passt — letzte Option immer Freitext.
Vorab: lies CONTEXT.md falls vorhanden. Daraus kommen Vorschlaege fuer F2 (Akteure) und F5 (Out-of-Scope-Kandidaten). Lies docs/adr/ falls da. Daraus kommen No-Go-Kandidaten fuer F6.
Die 6 Fragen:
F1 — Problem: "Was ist das konkrete Problem? Beschreib eine Situation, kein Feature."
Wenn die Antwort zu abstrakt ist ("User sind verwirrt"), nachbohren: "Zeig mir eine konkrete Situation: wer macht was, und was geht dabei schief?"
F2 — Wer hat es: "Fuer wen ist das?"
Auswahl aus CONTEXT.md-Akteuren. Default falls leer: Endnutzer / Admin / Internes Team / Mehrere. Letzte Option Freitext.
F3 — Grobe Loesung: "Was ist deine grobe Idee — 2-3 Saetze, kein Wireframe."
Wenn die Antwort zu detailliert wird (User-Stories, DB-Schema): stoppen mit "Das ist schon PRD-Level, groeber bitte. Speichern wir fuer spaeter."
F4 — Ausbaustufe: "Wie ausgebaut soll Version 1 sein?"
Auswahl: Klein und schnell mit Schulden / Ausgebaut mit allen Edge-Cases / Noch offen.
F5 — Weglassen: "Was gehoert explizit NICHT dazu — naheliegende Dinge, die wir jetzt nicht bauen?"
Auswahl aus CONTEXT.md (Out-of-Scope, "Phase X"). Letzte Option Freitext.
F6 — No-Go: "Was ist ein absolutes No-Go — etwas, das unter keinen Umstaenden Teil der Loesung sein darf?"
Auswahl aus ADRs (abgelehnte Alternativen) plus Compliance-Hinweise. Darf leer bleiben.
Nach F6 sofort schreiben — kein Nachhaken mehr.
Speicherort: docs/pitches/pitch-YYYY-MM-DD-<slug>.md
Slug: 3-4 Woerter aus dem Problem, kebab-case, Umlaute zu ae/oe/ue.
Format:
# Pitch: <kurzer Titel aus F1>
Datum: <heute>
Status: Pitch (vor Grilling)
## Problem
<F1>
## Wer hat es
<F2>
## Grobe Loesung
<F3>
## Ausbaustufe
<F4>
## Weglassen (vielleicht spaeter)
<F5>
## No-Go (auch nicht spaeter)
<F6 — wenn beantwortet>
Am Ende sagen: "pitch.md liegt unter docs/pitches/<dateiname>. Naechster Schritt: /grill-with-docs gegen genau diese Datei."
────────────────────────────────────
INHALT docs/prompts/grill-with-docs.md:
────────────────────────────────────
# /grill-with-docs — Plan gegen Domaene schaerfen
Du grillst mich zu meinem aktuellen Plan oder zur pitch.md (falls als Argument uebergeben). Ziel: Sprache und Begriffe schaerfen. Nicht Features spezifizieren.
Vorgehen:
1. Lies CONTEXT.md falls vorhanden. Lies docs/adr/ falls vorhanden. Lies pitch.md falls als Argument uebergeben.
2. Stelle Fragen einzeln. Eine Frage pro Antwort. Empfehlung jeweils nennen.
3. Worauf du achtest:
- Begriff-Konflikte: "Du sagst 'Kunde'. CONTEXT.md definiert 'Kunde' als X — du meinst Y. Was davon stimmt?"
- Fuzzy-Woerter: "Du sagst 'Account'. Meinst du den User oder den Customer? Das sind zwei Sachen."
- Konkrete Szenarien als Lackmustest: "Was passiert, wenn ein User eine Buchung halb storniert?"
- Code-Cross-Check: wenn ich behaupte, wie etwas funktioniert, pruef es im Code.
4. Sobald ein Begriff geklaert ist: SOFORT in CONTEXT.md ergaenzen, nicht batchen.
Format pro Eintrag: Begriff, Definition (1 Satz, fachlich), Beispiel (1 konkretes).
5. ADR (Architektur-Entscheidung) NUR vorschlagen, wenn alle drei stimmen:
- Schwer reversibel (Schemata, externe Pakete, Abhaengigkeiten)
- Ohne Kontext ueberraschend (spaeterer Leser fragt "warum so?")
- Echtes Trade-off mit Alternativen
Wenn auch nur eines fehlt: kein ADR.
Format: docs/adr/NNNN-kurz-titel.md mit den Sektionen Kontext / Entscheidung / Konsequenzen / Alternativen.
6. Am Ende: kurze Zusammenfassung — was hat sich geaendert, was ist neu in CONTEXT.md, gibt es ein neues ADR. Dann: "Bereit fuer /to-prd?"
────────────────────────────────────
INHALT docs/prompts/to-prd.md:
────────────────────────────────────
# /to-prd — Konversation in PRD verwandeln
Du verwandelst den aktuellen Konversations-Kontext in ein strukturiertes Produkt-Dokument. KEIN Interview — synthetisiere, was schon da ist.
Vorgehen:
1. Lies CONTEXT.md, docs/adr/ und alle pitch.md unter docs/pitches/. Nutze die Begriffe aus CONTEXT.md durchgaengig.
2. Skizziere die Module, die gebaut oder geaendert werden muessen. Aktiv nach "tiefen Modulen" suchen — Module mit viel Funktionalitaet hinter einer einfachen, stabilen Schnittstelle. Diese sind isoliert testbar.
3. Bestaetige mit mir: passen die Module? Welche bekommen Tests?
4. Schreibe das PRD nach docs/prd-YYYY-MM-DD-<slug>.md mit folgenden Sektionen:
## Problem
Aus User-Sicht. Eine Situation, kein Feature.
## Loesung
Auch aus User-Sicht. Was aendert sich fuer den, der's nutzt.
## User Stories
Lange nummerierte Liste. Format: "Als <Akteur> moechte ich <Funktion>, damit <Nutzen>."
Sehr extensiv — alle Aspekte abdecken.
## Module
Welche Module gebaut oder geaendert werden, ihre Schnittstellen, Schema- und API-Aenderungen.
KEINE konkreten Datei-Pfade oder Code-Snippets — die werden zu schnell veraltet.
## Tests
Wie ein guter Test aussieht (externes Verhalten, nicht Implementierung). Welche Module Tests bekommen. Verweis auf aehnliche Tests im Code.
## Was wir weglassen
Klar benannt. Trennt "vielleicht spaeter" von "gar nicht".
## Sonstiges
Offene Fragen, Anhaenge, Quellen.
5. Ausgabe: Pfad zur PRD-Datei plus Hinweis "Naechster Schritt: /to-issues gegen dieses PRD."
────────────────────────────────────
INHALT docs/prompts/to-issues.md:
────────────────────────────────────
# /to-issues — PRD in Arbeitsliste schneiden
Du nimmst ein PRD oder einen Plan (als Argument oder aktueller Kontext) und schneidest daraus konkrete Arbeitspakete in .scratch/.
Vorgehen:
1. Wenn Argument: PRD/Plan-Datei lesen. Sonst: aktueller Kontext.
2. Codebase kurz scannen falls noch nicht passiert. Begriffe aus CONTEXT.md nutzen, ADRs respektieren.
3. Schneide in duenne Schichten von oben bis unten — jedes Paket geht durch alle Ebenen end-to-end (Datenbank, Backend, UI, Tests). Nicht eine fette Schicht auf einer Ebene. Lieber viele duenne als wenige dicke. Pro Paket: kann das die KI alleine bauen, oder braucht es einen Menschen fuer Architektur-Entscheidung oder Design-Review? KI-allein bevorzugen wo moeglich.
4. Schlag mir die Liste vor — nummeriert. Pro Paket:
- Titel
- Wer baut: KI-allein / mit Mensch
- Vorher noetig: welche anderen Pakete fertig sein muessen
- Abgedeckte User Stories aus PRD
- Ungefaehre Groesse: Default 1-2 Tage Arbeit pro Paket
5. Frag mich:
- Granularitaet ok? (zu grob, zu fein)
- Abhaengigkeiten richtig?
- Sollen welche zusammengelegt oder weiter geteilt werden?
- Sind die "wer baut"-Tags richtig?
6. Iteriere bis ich ok sage.
7. Schreib jedes Paket nach .scratch/<NN>-<slug>.md. Reihenfolge nach Abhaengigkeiten — Blocker zuerst.
Format pro Datei:
# <NN>: <Titel>
Wer baut: KI-allein / mit Mensch
Vorher noetig: <Liste oder "nichts">
## Was bauen
Kurz und end-to-end. Was nach diesem Paket funktioniert.
## Akzeptanzkriterien
- [ ] Kriterium 1
- [ ] Kriterium 2
## User Stories abgedeckt
- <Story-Nummer aus PRD>
────────────────────────────────────
ENDE der Prompt-Templates.
────────────────────────────────────
Nach Anlage einmal sagen:
"Die vier Prompt-Templates liegen unter docs/prompts/. Wie du sie als Slash-Commands deiner Agent-Umgebung registrierst, haengt vom Tool ab. Claude Code: nach ~/.claude/commands/<name>.md kopieren. Cursor und Cline: ueber die Custom-Commands-Konfig. Wenn dir das jetzt zu viel ist: ruf den Inhalt einfach per `cat docs/prompts/pitch.md` auf und paste ihn als Prompt."
═══════════════════════════════════════
PHASE 2 — STATUS-REPORT
═══════════════════════════════════════
Tabelle in drei Spalten am Ende von Phase 1: "War da | Angelegt | Offen fuer dich".
Beispiel:
War da: Angelegt: Offen fuer dich:
- Git-Repo - docs/ - docs/prompts/ als Slash-Commands
- README.md - docs/pitches/ registrieren (siehe Hinweis oben)
- docs/prompts/pitch.md
- docs/prompts/grill-with-docs.md
- docs/prompts/to-prd.md
- docs/prompts/to-issues.md
- .scratch/
- CONTEXT.md
═══════════════════════════════════════
PHASE 3 — DEMO-LAUF (optional)
═══════════════════════════════════════
Frag: "Willst du jetzt den /pitch-Schritt mit deiner Idee durchspielen? [j/n]"
Bei j: Idee in 1 Satz holen, dann die 6 Pitch-Fragen aus docs/prompts/pitch.md der Reihe nach durchgehen, am Ende docs/pitches/pitch-YYYY-MM-DD-<slug>.md schreiben.
Bei n: zeig in einer Zeile, wie's weiter geht ("Wenn du soweit bist: paste den Inhalt von docs/prompts/pitch.md als Prompt"), dann Stop.
═══════════════════════════════════════
KOMMUNIKATIONSSTIL
═══════════════════════════════════════
- Knapp. Status-Linien mit ✓ / + / ⚠️.
- Keine "Grossartig!"-Bestaetigungen, keine Marketing-Floskeln.
- Vor destruktiven Aktionen (Files ueberschreiben, loeschen, force-push): immer fragen.
- Keine Slash-Commands aufrufen, die nicht selbst angelegt wurden.
Sobald der Bauplan steht, läuft der Code-Loop.
Hinten: ein stur laufender Loop, der die Pakete abarbeitet.
Beide Teile sind unabhängig nutzbar — zusammen geben sie dir die ganze Strecke.