PLAID in der Praxis - Ich habe eine echte Produktidee durch diesen Idea-to-Launch Skill laufen lassen

Vor ein paar Wochen habe ich über Addy Osmanis agent-skills-Bibliothek geschrieben und darüber, wie Anthropics Progressive-Disclosure-Skill-Format still und leise umformt, wie ich ernsthafte agentische Arbeit mache. Osmanis Skills sind generische Engineering-Disziplin - die spec → plan → build → test → review → ship-Schleife, die jede Codebasis braucht. Sie setzen voraus, dass du bereits weißt, was du baust.

PLAID (Product Led AI Development) von buildgreatproducts greift die andere Hälfte des Problems an. Es ist der Skill, der läuft, bevor du jemals /spec tippst. Er führt einen Founder von “Ich habe eine vage Idee” zu Produktvision + PRD + Build-Roadmap + Go-to-Market-Plan, als eine einzige orchestrierte Konversation. Wo Osmanis Skills eine horizontale SDLC-Bibliothek sind, ist PLAID eine vertikale Pipeline, die auf einen spezifischen Nutzer zielt: den Solo- oder Kleinteam-Founder, der shippen will.

Ich habe einen Abend damit verbracht, PLAID end-to-end auf einer Wegwerf-Pilotproduktidee laufen zu lassen. Das hier ist, was er tatsächlich produziert hat, was daran wirklich gut ist, und wo die Risse sichtbar werden.

Was PLAID kurz und knapp ist

PLAID ist ein einzelner Claude Code Skill mit drei Capabilities:

Capability	Was er macht	Output
Plan	Vision-Intake-Konversation + Dokumentengenerierung	`vision.json`, `product-vision.md`, `prd.md`, `product-roadmap.md`
Launch	Go-to-Market-Plan aus der Vision	`gtm.md`
Build	Führt die Roadmap Phase für Phase aus, committet nach jeder	Funktionierender Code, phasenweise Git-History

Der gesamte Skill umfasst rund 2.800 Zeilen Markdown verteilt auf SKILL.md plus zehn Reference-Dateien (Generation-Prompts, Schema, Intake-Guide, Tech-Stack-Vergleich). Es gibt einen Node.js-Validator mit null Dependencies. Das war’s. Kein Agent-Framework, keine State Machine, kein UI - es ist ein Set gut geschriebener Anweisungen, denen das Modell folgt.

Die Installation ist ein Einzeiler:

npx skills add BuildGreatProducts/plaid

Oder manuell: Füge den Pfad zur SKILL.md zu deiner .claude/settings.json hinzu:

{
  "skills": ["/absolute/path/to/plaid/SKILL.md"]
}

Dann tippst du in einer Claude-Code-Session PLAID oder plan a product, und der Skill lädt.

Der Testlauf

Ich brauchte eine Testidee, die realistisch genug war, damit ich die Output-Qualität beurteilen konnte. Ich habe etwas aus meinem eigenen Backlog genommen:

Currency Coach - eine Mobile App für IFR-berechtigte Piloten, die ihr vorhandenes ForeFlight- oder Garmin Pilot-Logbuch ingestiert, den Verfall jeder einzelnen Flugfähigkeit modelliert (ILS, LPV, Circling, Nacht, Seitenwind, hand-flown IMC) und ein Pre-Flight-Verdikt für einen spezifischen geplanten Trip liefert. Nicht “bist du legal?” sondern “bist du scharf genug für diesen Samstag, und falls nicht, welche einzelne 45-Minuten-Session würde das fixen?”

Ich bin die Zielgruppe, also kann ich den Unterschied zwischen einem PRD, das IFR-Fliegen versteht, und einem, das Luftfahrt-Cosplay produziert, erkennen. Gute Testumgebung.

Ich habe den Vision-Intake von PLAID laufen lassen, alle acht Sections ausgefüllt (Founder, Purpose, Product, Audience, Business, Feeling, Tech Stack, Tooling), die Antworten in vision.json gespeichert, den Validator laufen lassen (der beim ersten Versuch durchging, ein kleines Detail, das zählte) und dann die drei Dokumente generiert.

Der Output

Drei Dateien in docs/:

product-vision.md - 49 KB, ~8.000 Wörter. Vision, Mission, Core Values, Strategic Pillars, Primary + Secondary Personas, JTBD, Pain Points, Competitive Landscape, MVP Scope mit explizitem Out-of-Scope, Brand Voice mit DO/DON’T-Beispielen, Design Tokens mit Hex-Werten, Typography-Specs, Spacing Scale.
prd.md - 72 KB, ~9.200 Wörter. Stack-Tabelle, Mermaid-Architekturdiagramm, vollständiges Convex-Schema mit 12 Tabellen, API-Spezifikation, 24 funktionale Requirements mit Acceptance Criteria, Screen-by-Screen-UI mit Empty/Loading/Error/Populated-Zuständen, Tailwind-Config mit Design Tokens, Auth-Implementierung, Subscription-Integration, Edge Cases, Open Questions.
product-roadmap.md - 38 KB, ~5.200 Wörter. 72 Tasks über 5 Phasen, jeder Task mit Dateipfaden, einem Phase-Prompt, den du direkt in Claude Code einfügen kannst, und einem “Reference Sections to Load”-Block, damit der Agent nicht das gesamte PRD pro Phase in den Kontext laden muss.

Das ist kein Stub. Das ist die Form einer echten Produktspezifikation, produziert in unter 20 Minuten Modellzeit aus einer vision.json.

Was wirklich funktioniert

1. Der Vision-Intake ist das Produkt

Der Intake-Guide (references/INTAKE-GUIDE.md) ist das Beste im Repo. Acht Sections, rund vierzig Fragen, jede mit:

Dem Fragetext plus einer Ein-Satz-Begründung, warum er wichtig ist
Einem Prompt zum Generieren von drei substanziell unterschiedlichen Vorschlägen, basierend auf dem, was der Founder bis dahin gesagt hat
Einer expliziten Regel, dass die ersten beiden Fragen (Name, Expertise) keine Vorschläge bekommen (nur direkter Input)
Einer Regel, dass Vorschläge mit der Zeit besser werden müssen, nicht nur frühere Inhalte umformulieren

Die Tech-Stack-Section ist besonders gut. Sie nutzt ein Vergleichstabellen-Format, das Next.js vs Remix vs SvelteKit mit ehrlichen Pros/Cons auslegt und dann eine spezifische Empfehlung gibt, die an die früheren Antworten des Founders anknüpft. Die Default-Empfehlungen (Next.js für Web, Expo für Mobile, Convex Backend, Clerk oder Convex Auth, Polar oder RevenueCat) sind opinionated, aber gut begründet. Du kannst jede davon überschreiben, aber die Defaults sind gut genug, dass die meisten Solo-Founder sie einfach nehmen sollten.

Hier zahlt sich PLAIDs founder-spezifischer Scope aus. Ein generischer Spec-Skill kann nicht fragen “was ist dein 90-Tage-Revenue-Target” oder “wem kannst du einzigartig helfen”, weil diese Fragen nicht zu jedem User passen. PLAID verengt hart auf den Founder-Archetyp und verdient sich damit das Recht, sie zu stellen.

2. Die Drei-Doc-Kaskade

PLAID ist strikt darin, dass die Dokumente in Reihenfolge generiert werden - zuerst die Vision, dann das PRD, das die Vision liest, dann die Roadmap, die beide liest. Das ist im Nachhinein offensichtlich, aber in der Praxis selten. Die meisten Doc-Generation-Tools behandeln jedes Artefakt als unabhängig. PLAIDs Kaskade bedeutet, dass früh gesetzte Tokens (Design Tokens, Skill-Namen, Magic Moment) konsistent bis hinunter zu den Task-Level-Roadmap-Notes propagieren.

In meinem Lauf tauchten die in der Vision gewählten Color Tokens (#0A0C10 für Ink, ein amber Warning, ein gedämpftes Sage für “sharp”) wortwörtlich in der Tailwind-Config des PRDs wieder auf und dann erneut in den Phase-0-Tasks der Roadmap (“kopiere die vollständige Tailwind-Config aus PRD § 9”). Ich musste null Reconciliation-Arbeit machen. Das ist die Art von kompoundierender Konsistenz, die man normalerweise nur von einem Menschen bekommt, der alle drei Dokumente in einem Rutsch geschrieben hat.

3. Das Task-Format

Jeder Task in der Roadmap nutzt genau diese Form:

- [ ] **TASK-023** - Implement the decay-model unit tests.
  Files: `convex/decayModel.ts`, `convex/decayModel.test.ts`
  Notes: Test half-life curves for each skill type. Seed with 50 flights
  from fixtures/sample-logbook.json. Expected accuracy >= 90% vs labels.

Plus: Jede Phase hat einen “Reference sections to read before starting”-Block, der auf spezifische Sections der Vision und des PRDs verweist. Das ist wichtig, weil es bedeutet, dass der Build-Agent nicht 72 KB PRD für jeden Task in den Kontext laden muss. Er lädt nur die relevanten Sections. Das ist Progressive Disclosure angewendet innerhalb eines einzelnen Projekts - genau der richtige Move.

4. Der Validator

node scripts/validate-vision.js --migrate sind 340 Zeilen Node.js mit null externen Dependencies. Er prüft das JSON-Schema, wendet Migrationen an, falls du eine ältere vision.json aus einer früheren PLAID-Version hast, und meldet Warnungen, ohne zu blockieren. Es ist ein kleines Detail und es verändert die Vibe komplett. Die meisten “AI Skills” shippen keinen Validator. Einen zu shippen signalisiert, dass die Autoren das als Engineering betrachten, nicht als Prompting.

5. Resumability

PLAIDs Capability-Dateien prüfen alle beim Einstieg den Projekt-State: Existiert vision.json? Sind die Docs da? Ist die Roadmap teilweise erledigt? Dann macht er dort weiter, wo du aufgehört hast. Du kannst eine Session mitten im Intake schließen und in einer Woche wiederkommen, und der Skill sagt dir genau, wo du pausiert hast. Das passt natürlich zur Philosophie des Skills Frameworks “Skills sind Workflows, keine Single-Shot-Prompts”.

Wo die Risse sichtbar werden

Ich will hier ehrlich sein, weil der Grund, warum ich diese Dinge teste, der ist, zu wissen, wann man ihnen vertrauen kann.

1. Vision und PRD überlappen mehr, als sie sollten

Die product-vision.md-Section zu Product Strategy enthält MVP Scope und Out-of-Scope. Die prd.md-Overview- und “Out of Scope”-Sections decken denselben Boden ab. Die Generation Guides sagen dem Modell “wiederhole keine Informationen zwischen Sections” und geben dann Section-Requirements, die Wiederholungen erzwingen. Ich landete mit drei leicht unterschiedlichen Framings derselben Scope-Liste an drei verschiedenen Stellen. Eine sauberere Struktur würde den Scope einmal setzen (in der Vision) und das PRD darauf verweisen lassen.

2. Das PRD-Template tendiert zu REST

Der PRD-Generation-Guide enthält REST-Endpoint-Beispiele (Method, Path, Request Body, Response Body). Für eine Convex-App - die PLAID selbst als Default-Backend empfiehlt - gibt es keine REST-Endpoints, nur typisierte Queries und Mutations. Das Modell hat das REST-Template korrekt ignoriert und Convex-RPC-Signaturen produziert, aber es musste dafür gegen das Template kämpfen. Ein stack-aware Template (eines für REST, eines für Convex, eines für tRPC) würde diese Reibung eliminieren. Einen PR wert.

3. Die Roadmap-Task-Granularität ist aspirational

PLAID schreibt Tasks vor, die für 15-45 Minuten Agent-Arbeit dimensioniert sind. Einige Tasks, die aus meinem Testlauf kamen, sind offensichtlich Multi-Session - “TASK-021: Implement the decay-model classifier with >= 90% accuracy on a 50-flight labeled set.” Das ist ein Research-Problem, kein 30-Minuten-Task. Die Regel blockiert das Modell daran, das zu sagen. Du endest mit Tasks, die nominell atomar, aber praktisch Multi-Day sind, was ein falsches Gefühl von Scope erzeugt. Mir wäre lieber, der Skill würde sagen “einige Tasks sind als Research klassifiziert, so gehst du damit um”, statt alles in dieselbe Granularität zu pressen.

4. Opinionated Defaults schneiden in beide Richtungen

PLAID ist stark opinionated: Convex, Clerk oder Convex Auth, Polar für Web-Payments, RevenueCat für Mobile. Wenn du zustimmst, sparst du Stunden - die Auth- und Payments-Sections des PRDs kommen implementation-ready mit spezifischen Convex + RevenueCat-Code-Patterns raus. Wenn du widersprichst, kämpft der Skill gegen dich. Die Tech-Stack-Comparison-Datei listet ehrlich Alternativen auf (Supabase, Firebase, Stripe, etc.), aber die Generation Guides setzen implizit die Defaults voraus. Founder auf einem Stripe + Postgres + Supabase Stack bekommen nützlichen Output, aber weniger Polish.

Das ist der richtige Trade-off für PLAIDs Zielgruppe (Solo-Founder, die shippen wollen) und der falsche für meine bei manchen Projekten. Wisse, auf welcher Seite du stehst, bevor du dich festlegst.

5. Keine Tests im PRD oder in der Roadmap

Das ist der Punkt, der mich davon abhalten wird, PLAID as-is für irgendetwas Ernsthaftes zu nutzen. Das PRD hat eine “Non-Functional Requirements”-Section, die Qualitäts-Thresholds erwähnt, aber die 72 Tasks der Roadmap enthalten nicht einen einzigen Task für das Schreiben von Unit Tests oder Integration Tests. Testing fehlt komplett im Phase-Prompt-Scaffolding. Das ist genau das, wozu Osmanis test-driven-development-Skill existiert.

Die ehrliche Lösung ist zu layern: Nutze PLAID, um Vision + PRD + Roadmap zu generieren, dann lasse Osmanis Skills (oder Äquivalente) obendrauf laufen für Test-First-Implementation, Code Review und Shipping. So werde ich ihn ab jetzt nutzen.

Wie PLAID neben Osmanis Agent-Skills und Spec Kit passt

Die drei sind komplementär, nicht konkurrierend:

Dimension	PLAID	Agent-Skills (Osmani)	Spec Kit (GitHub)
Scope	Founder-vertikal: Idee → Launch	Generische horizontale SDLC-Bibliothek	Spec-Driven Development Lifecycle
Wann greifst du dazu?	Neues Produkt, noch keine Docs	Jede Codebasis, jede Phase	Start eines Greenfield-Projekts
Primäre Einheit	3-Doc-Kaskade (Vision/PRD/Roadmap)	20+ phasenspezifische Skills	Slash-Command-Scaffolding
Opinionated Stack?	Ja - Convex/Clerk/Polar/RevenueCat Defaults	Nein	Nein
Testing eingebaut?	Fehlt	Kern-Skill	Implizit im gated Flow
Anti-Rationalisierung	Implizit	Expliziter Abschnitt pro Skill	Implizit in Phase Gates

Mein sich herausbildender Workflow für ein Greenfield-Produkt:

PLAID Plan zum Generieren von vision.json, product-vision.md, prd.md, product-roadmap.md. Rund eine Stunde inklusive Intake-Konversation. Ich editiere die Docs von Hand für alles, was PLAID falsch gemacht oder übersehen hat.
Trimmen und annotieren der Roadmap-Tasks - Multi-Session-Tasks flaggen, eine Handvoll expliziter Test-Tasks hinzufügen, Granularität anpassen.
Osmanis /spec, /plan, /build, /test, /review, /ship für die Ausführung. Diese Skills leben auf PLAIDs Artefakten, nicht unter ihnen.
PLAID Launch für den GTM-Plan, wenn ich bereit bin zu announcen.
PLAID Build nur für die wirklich trivialen Scaffold-Phasen (Phase-0-Setup, Plumbing). Für alles Nicht-Triviale bevorzuge ich Osmanis Skills wegen der Testing-Disziplin.

Das Fazit

PLAID ist der erste Skill, den ich gesehen habe, der Produktdefinition als First-Class-Workflow behandelt, nicht als Nebenprodukt des Promptings. Der Intake-Guide allein ist eine sauberere, meinungsstärkere Version dessen, was die meisten Founder versuchen (und scheitern) aus ChatGPT über ein Dutzend chaotischer Sessions zu extrahieren. Die Drei-Doc-Kaskade ist eine echte Innovation in erzwungener Konsistenz. Der Validator ist ein leises Signal, dass die Autoren sich um das Engineering der Sache kümmern.

Er ist auch schmaler als Osmanis Bibliothek und lässt die Testing-Schicht vermissen, die eine Spec in ein vertrauenswürdiges Produkt verwandelt. Nutze ihn nicht als kompletten agentischen Stack. Nutze ihn als dessen Frontend.

Wenn du ein Founder bist, der auf ein leeres docs/-Verzeichnis starrt, lass PLAID heute Abend laufen. Wenn du ein Engineer mit einer bereits in Flight befindlichen Codebasis bist, bleib bei Osmani. Wenn du ein Greenfield-Produkt startest und es ordentlich machen willst, nutze beide.

Referenzen

buildgreatproducts/plaid - Das PLAID-Skill-Repository
Mein früherer Artikel zum Skills Framework - Agent-Skills, Progressive Disclosure und warum das alles wichtig ist
addyosmani/agent-skills - Die horizontale SDLC-Skill-Bibliothek
github/spec-kit - GitHubs Spec-Driven-Development-Toolkit
skills CLI - Der npx skills add-Installer
Anthropics Skill-Docs - Das zugrundeliegende Format