From a problem to a finished build plan in 4 steps.
A raw idea isn't buildable. Between "I want this thing" and the first commit sit four small steps. Skip them and you ship the wrong thing. Here they are, plus a bootstrap prompt that handles the setup inside your own project.
From problem to build plan in four steps.
Each step takes the output of the previous one and sharpens it. What comes out at the end isn't a vision slide. It's a concrete build plan — small packages, each one to two days of work, that you or your coding agent can work through in order.
Six questions get you to a clean pitch.
You drop in one sentence of idea. What comes back is a short note: problem, who has it, rough solution, scope, what you're cutting, what never gets in. Six questions, six answers, one page. Without this page, every future session starts by re-litigating what you actually want.
It's also the step where you catch yourself. Sometimes you only notice while answering that you can't even name the problem cleanly. Better now than during the third refactor.
The 6 questions
One per message, with multiple-choice anchors where they help. Last option is always free text.
What's the concrete problem?
Describe a situation, not a feature. Who does what, and what goes wrong?
Who is this for?
Who runs into the problem? Suggestions come from the actors already listed in CONTEXT.md.
What's your rough idea?
2-3 sentences, no wireframe. Imagine you're explaining it to someone in 30 seconds at a whiteboard.
How built-out should version 1 be?
Small and fast — or fully built? Both are valid answers, depends on the risk.
What are we deliberately leaving out?
Obvious things that aren't coming now but maybe later. Suggestions pulled from the phase plan if you have one.
What never gets in?
Something that under no circumstances can be part of the solution. Compliance hard limits, rejected architecture paths, business-model red lines. Can be empty.
Get yourself and Claude on the same page — before a line of code gets written.
This is where your pitch gets grilled. The agent reads the note, compares it to what's already documented in the project, and asks the uncomfortable questions: you say "customer" — do you mean the one who pays, or the one who uses the system? You say "cancel" — can you cancel part of an order, or only the whole thing?
What this is really about: making sure you and Claude actually mean the same thing before anyone touches code. Sounds trivial. It isn't. Bug reports against features the code never actually covered are almost always a misunderstanding of terms — one that was already in the pitch and nobody caught it.
Two kinds of documents fall out of the conversation. Not glossy decks — tools for building.
Your project's dictionary — so you don't contradict yourself
Same thing, same word. Stops "customer", "user" and "lead" from becoming three names for one person. A table with term, definition, example. Filled in live as soon as a term gets clarified. The upside: every new session, you don't have to re-explain what's what — the agent just reads it.
An architecture decision with a reason — for your future self
When you ask yourself later "why did I build it this way?", the answer is here. Use it sparingly — only when the decision is hard to reverse, not obvious from the code, and the result of a real trade-off. Saves you hours of digging through old commits.
The PRD: the core document that says what you're building and why.
PRD stands for Product Requirement Document — a piece of paper with the what and the why, without locking down the how. The how comes in the next step.
Up to this point everything lived in a chat transcript. Now it becomes a document where someone who wasn't in the room finds the gist in ten minutes — and that even you still understand when you come back to it four weeks later. No new interview needed: the agent synthesizes from what's already in context.
Six sections, each one answers a question that actually comes up while building:
- Problem — Why am I building this at all? From the user's side, a situation, not a feature.
- Solution — What changes for the person using it? Also from the user's side.
- User Stories — Long numbered list. "As X, I want Y, so that Z." Covers every angle.
- Modules — What gets built or changed. Which interfaces, which schema changes. No file paths — they go stale too fast.
- Tests — Which modules get tests, what a good test looks like (external behavior, not implementation).
- What we're cutting — Named explicitly. Separates "maybe later" from "not at all".
The PRD sliced into small tasks your agent works through one by one.
Last step before the code loop. The PRD gets cut into numbered packages under .scratch/ — each one or two days of work. Every package is a thin slice top to bottom (database, backend, UI, tests), not a fat layer on one level. That way, after each finished package, you have something to show — not a pile of half-done parts.
What you get out of it: you or your coding agent can start on package #03 in the morning and have it merged by evening. No daily planning, no "what do I do first", no reverse-engineering from a vision doc. The agent picks the next package and gets going.
Each package's document has:
- • What it is — a feature that runs end-to-end after this package.
- • Who can build it — the AI alone, or does it need a human for an architecture call or a design review.
- • What it needs first — which other package has to be done.
- • How big it is — rule of thumb 1-2 days per package. If bigger: split further.
Cut means: maybe later. No-go means: never, not later either — because it cuts against the business model, sits on shaky legal ground, or overturns an earlier decision you don't want to overturn. Both lists come from the pitch and get picked up again in the PRD.
Setting this up in your project takes one paste — the prompt builds everything itself.
You don't have to prepare anything. No git repo? It'll be created. No docs/? Created. No prompt templates? Created. You paste, the prompt checks what's already there, and only adds what's missing. Existing files stay untouched.
Paste this into a coding agent — not into a browser chat
The prompt writes real files into your project. That only works where the agent has file access. In claude.ai in the browser, ChatGPT web, etc., the prompt runs into nothing — no file system behind it.
Works
- Claude Code (terminal CLI)
- Antigravity (Google's agent IDE on Gemini-3)
- Cursor / Windsurf / Cline (VS Code-based)
Doesn't work
- claude.ai in the browser (no file access)
- Claude Desktop chat app (no file access)
- ChatGPT, Gemini web, Perplexity
Copy it, paste it into your agent, done.
Three phases: phase 1 checks your environment and lays down folders and prompt templates, phase 2 gives you a status report, phase 3 asks if you want to jump straight into /pitch with your idea. If not: just hit n — the setup is in your project either way.
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.
Once the build plan is set, the code loop takes over.
Behind that: a stubborn loop that grinds through the packages.
Both parts work on their own — together they give you the whole stretch.