Was macht LaunchPad — Idee → validierter Plan → baufertiger Kontext?
Dieser Skill reproduziert die LaunchPadAI-Agenten-Pipeline ohne deren Backend. Du spielst nacheinander jeden spezialisierten Agenten, schreibst jedes Ergebnis auf die Platte und fütterst frühere Ausgaben in spätere. Der Wert der Pipeline kommt von drei Dingen – behalte alle drei bei, auch wenn du abkürzt:
- Spezialisten-Framing. Jeder Schritt hat eine eigene Rolle mit eigener Voreingenommenheit (der Annahmen-Herausforderer ist ein Skeptiker; der Chancen-Mapper schaut sich Substitutionsalternativen an). Jeden Schritt getrennt, in seiner Rolle, zu schreiben, liefert schärfere Arbeit als ein einziger vermischter „Analysiere diese Idee“-Durchlauf.
- Evidenzbasierung. Forschungsschritte nutzen Websuche und zitieren URLs. Erfundene Wettbewerber, Marktzahlen oder Finanzierungsrunden zerstören den Wert des gesamten Plans, weil jede nachgelagerte Phase sie erbt. Falls die Suche nicht verfügbar ist oder nichts Nützliches liefert, sag das und kennzeichne Zahlen als Schätzungen.
- Kontextkontinuität. Jede Phase liest die Abschlussdokumente der vorherigen Phasen. Das PRD muss die in der Validierung gefundenen Personas und Risiken widerspiegeln; die Architektur muss den MVP-Umfang des PRD umsetzen, nicht eine generische App.
Phasen
| # | Phase | Schritte (→ = hängt ab von) | Abschlussdokument(e) | Referenz |
|---|---|---|---|---|
| 0 | Discovery | Problem → Annahmen → Chance → Brief | BRIEF.md | references/discovery.md |
| 1 | Validation | Markt, Wettbewerb, Machbarkeit, Personas (unabhängig) → Synthese → Benchmark | VALIDATION_REPORT.md, BENCHMARK.md, benchmark.json | references/validation.md |
| 2 | PRD | Anforderungen, User Stories (unabhängig) → Priorisierung, UX-Flows → PRD | PRD.md | references/prd.md |
| 3 | Coding Context | Architektur, Schema (unabhängig) → Aufgaben, Regelwerk → Paket | CODING_CONTEXT.md + Regelwerk | references/coding-context.md |
Lies nur die Referenzdatei für die Phase, die du gerade ausführst – jede enthält die Rollen- und Deliverable-Spezifikation für jeden Schritt dieser Phase.
Erste Schritte
- Sammle die Projekteingaben. Du brauchst: Projektname, die rohe Idee (ein paar Sätze reichen), und optional Domain, Zielgruppe und Gründerhintergrund (der Benchmark bewertet Gründer-Markt-Fit – ohne Hintergrund bewerte konservativ und erkläre warum). Frage einmal nach allem, was fehlt und wichtig ist; verhöre nicht.
- Lege den Umfang fest. Standard: Führe Phase 0 → 1 aus, dann pausiere. Falls der Benutzer eine bestimmte Phase angefragt hat („Schreib mir einfach ein PRD“), beginne dort – prüfe aber zuerst, ob Dokumente aus vorherigen Phasen existieren. Falls nicht, führe entweder eine komprimierte Version der fehlenden früheren Phasen durch (sag das) oder fahre mit der Idee allein fort und markiere im Output, welche Eingaben angenommen statt recherchiert wurden.
- Erstelle den Arbeitsbereich im aktuellen Verzeichnis (außer der Benutzer nennt einen anderen Ort):
launchpad/<projekt-slug>/
00-discovery/ problem.md assumptions.md opportunity.md BRIEF.md
01-validation/ market-size.md competitors.md feasibility.md personas.md
VALIDATION_REPORT.md benchmark.json BENCHMARK.md
02-prd/ requirements.md user-stories.md prioritization.md ux-flows.md PRD.md
03-coding-context/ architecture.md schema.md tasks.md CLAUDE.md|.cursorrules CODING_CONTEXT.md
project.md name, idea, domain, audience, founder background, feedback log
Schreibe zuerst project.md. Falls für dieses Projekt bereits ein Arbeitsbereich existiert, verwende ihn wieder – lies, was da ist, und fahre fort, anstatt neu zu beginnen.
Einen Schritt ausführen
Jeder Schritt Prompt ist konzeptionell:
Projekt: <Name> Idee: <rohe Idee> Domain / Zielgruppe (falls bekannt)
--- Vorheriger Phasenkontext --- Abschlussdokumente früherer Phasen (siehe unten)
--- Vorherige Schrittausgaben --- Ausgaben der Schritte, von denen dieser abhängt
--- Benutzer-Feedback --- falls nach Feedback erneut ausgeführt
--- Deine Aufgabe --- Rollen- und Deliverable-Spezifikation aus der Referenzdatei
Vorheriger Phasenkontext (ersetzt die pgvector-Abfrage der Plattform):
- Validation liest
BRIEF.md. - PRD liest
BRIEF.md,VALIDATION_REPORT.md,BENCHMARK.mdundpersonas.md. - Coding Context liest
PRD.mdundfeasibility.md, plusBRIEF.mdfür den Umfang.
Jede Ausgabedatei beginnt mit einem Metadaten-Header, gefolgt von der vollständigen Analyse:
> **Überschrift:** <der einzelne wichtigste Befund, als vollständiger spezifischer Satz – das „Was heißt das“, nicht das Thema>
>
> **Wichtigste Erkenntnisse**
> - <wichtigster Befund>
> - <zweiter>
> - <dritter> (max. 5)
Abschluss-/Synthese-Dokumente (BRIEF.md, VALIDATION_REPORT.md, PRD.md, CODING_CONTEXT.md) fügen zusätzlich eine Bewertungstafel mit 3–5 Metriken innerhalb dieses Headers hinzu:
> | Metrik | Wert | |
> |---|---|---|
> | Problem-Schweregrad | 8/10 | 🟢 |
> | Wettbewerbsdichte | Hoch | 🔴 |
(🟢 stark/positiv, 🟡 moderat/unsicher, 🔴 schwach/bedenklich.) Der Header existiert, damit ein Leser, der 20 Dokumente überfliegt, die Schlussfolgerung jedes einzelnen in fünf Sekunden erhält.
Forschungsschritte (gekennzeichnet 🔎 in den Referenzen): führe mehrere gezielte Websuchen durch – nicht eine generische Abfrage – z. B. Wettbewerbernamen + Preise, „ reddit“, Marktberichte mit Jahreszahlen. Zitiere inline als [1] mit einer ## Quellen-Liste von URLs am Ende.
Parallelität. Als unabhängig markierte Schritte können als parallele Unteragenten ausgeführt werden, falls das Agent-Werkzeug verfügbar ist – gib jedem Unteragenten die Projekteingaben, die Dateipfade des vorherigen Phasenkontexts, seinen Abschnitt der Referenzdatei und den Ausgabepfad. Ansonsten führe sie sequentiell selbst aus. Syntheseschritte laufen in jedem Fall erst, nachdem ihre Eingaben existieren, und sie lesen die vollständigen Dateien, keine Zusammenfassungen.
Der Benchmark-Score
Nach VALIDATION_REPORT.md schreibe benchmark.json (Schema in references/validation.md), führe dann aus:
python3 <skill-verzeichnis>/scripts/benchmark_score.py launchpad/<slug>/01-validation/benchmark.json "<Projektname>"
Es berechnet overall_score mit den festen Gewichten neu (so sind Scores über Projekte hinweg vergleichbar und nicht handgewunken), überschreibt das JSON und schreibt BENCHMARK.md daneben. Sei kalibriert: Die meisten Ideen landen bei 4–6 und im 40.–65. Perzentil. Ein Benchmark, bei dem alles 8+ ist, ist ein Zeichen von Jubel, nicht von Analyse.
Zwischen den Phasen
Halte nach jeder Phase inne und gib dem Benutzer eine kurze Zusammenfassung im Chat: die Überschrift des Abschlussdokuments, die Bewertungstafel, das Urteil (Validation) und die 2–3 Dinge, die seine Meinung am ehesten ändern würden. Frage dann, ob fortgefahren, überarbeitet oder abgebrochen werden soll. Rase nicht ungefragt durch alle vier Phasen – ein „Überdenken nötig“-Urteil sollte ein echter Entscheidungspunkt sein, und der Benutzer möchte die Idee vielleicht umschwenken lassen, bevor ein PRD darum herum geschrieben wird.
Wenn der Benutzer Feedback zu einer Phase gibt, hänge es an das Feedback-Protokoll in project.md an, führe nur die betroffenen Schritte plus den Syntheseschritt der Phase mit dem Feedback im Kontext erneut aus und überschreibe diese Dateien.
Abschluss
Wenn der Coding Context abgeschlossen ist, sage dem Benutzer, welche Dateien er in sein neues Repository kopieren soll: CODING_CONTEXT.md und die Regeldatei (CLAUDE.md für Claude Code, .cursorrules für Cursor, AGENTS.md für andere Agenten – frage, welches Werkzeug er verwendet, falls unklar; Standard ist CLAUDE.md), plus tasks.md als Build-Backlog.