Was ist pdd-kit?
pdd-kit von Itai Gendler ist ein Open-Source-Toolkit für das, was es Product-Driven Development nennt. Statt einer Spezifikation pro Feature hält es im Repository ein einziges Verzeichnis product-model/, das das Produkt als Entitäten, Schnittstellen, Domänen, Fähigkeiten, Journeys, Geschäftsregeln und Varianten beschreibt. Agenten und Menschen lesen dieses gemeinsame Modell, und ein Verify-Schritt prüft den Code dagegen.
Installiert wird es mit npx pdd-toolkit install, und es bringt eine Nuxt-basierte Berichtsoberfläche zum Durchsehen des Modells mit, dazu Blueprints wie ein ausgearbeitetes Kanban-Board-Beispiel. Der Autor positioniert es gegen Tools für spezifikationsgetriebene Entwicklung wie spec-kit und OpenSpec: Wo diese für jede Änderung eine Wegwerf-Spezifikation schreiben, pflegt pdd-kit ein lebendiges Modell neben dem Code.
Das Repository steht unter MIT-Lizenz und hat etwa 97 GitHub-Sterne, das npm-Paket pdd-toolkit ist bei 0.38.0 (25. Oktober 2026). Es ist ein neues Projekt mit einem einzigen Maintainer, angelegt im Juli 2026.
Lohnt sich pdd-kit?
Die Prämisse von pdd-kit lautet, dass das Produkt bereits existiert, verstreut über Tickets, Dokumente, Chats und Code, und dass jeder Coding-Agent es von Grund auf und jedes Mal anders rekonstruiert. Seine Antwort: dieses Produkt einmal aufschreiben, als in git versioniertes Modell, und die Agenten es lesen lassen. Das ist ein echter Unterschied zu spec-kit und OpenSpec, die pro Feature eine neue Spezifikation erzeugen; pdd-kit hält Entitäten, Journeys und Geschäftsregeln als dauerhafte Dokumente, die das ganze Team und jeder Agent teilen.
Das Modell ist strukturiert statt freier Prosa. Das Verzeichnis product-model/ trennt Entitäten, Schnittstellen, Domänen, Fähigkeiten, Journeys, Geschäftsregeln (formuliert als „max. 3 pro Bestellung“, „nur Manager erstatten“) und Varianten für Feature-Flags oder Tarifstufen. Eine Berichtsoberfläche stellt es dar, und das Kanban-Board-Blueprint liefert ein vollständiges Modell ohne Code dahinter, damit man die Form sieht, bevor man es übernimmt. Weil Modell und Code im selben Pull Request geändert werden, soll eine Abweichung zwischen dem, was das Produkt ist, und dem, was der Code tut, im Review sichtbar werden.
Die Last ist dieselbe, die jeder Spezifikations-Workflow trägt, nur nach vorn verlagert: Jemand muss das Modell schreiben und pflegen, und ein Modell, das dem Code hinterherhinkt, ist schlechter als keins, weil Agenten ihm vertrauen. pdd-kits eigene Lesart, dass fertig bedeutet, der Code entspreche dem freigegebenen Modell, gilt nur, wenn das Modell aktuell gehalten wird, und das erzwingt nichts außer der Disziplin der Reviewer.
Die ehrliche Grenze ist die Verbreitung. Mit etwa 97 Sternen und zehn Forks, einem einzigen Maintainer und schnell aufeinanderfolgenden Releases (0.38.0 Ende Oktober) ist das ein frühes Projekt, das eine Idee erprobt, kein etablierter Standard. Das Konzept ist interessanter als das von spec-kit; die Erfolgsbilanz ist ein Bruchteil davon, und ein Team, das seinen Prozess auf pdd-kit setzt, setzt darauf, dass eine Person weiter ausliefert.
Wo es sich lohnt
Ein SaaS-Team aus vier Entwicklern, dessen Produktregeln in Slack und drei veralteten Dokumenten liegen
Dem eigenen Coding-Agenten eine einzige Quelle dafür geben, wie sich das Produkt tatsächlich verhält
npx pdd-toolkit install ausführen, das bestehende Repository in ein Produktmodell überführen und Journeys und Geschäftsregeln unter product-model/ pflegen, damit der Agent sie vor dem Bauen liest. Kostenlos; die Kosten sind die Stunden für das erste Modell und die Disziplin, es in jedem Pull Request zu aktualisieren.
Eine Tech Lead, die Agenten-Coding in ein Produkt mit komplexen Abrechnungsregeln einführt
Verhindern, dass Agenten die Logik für Erstattungen und Steuern jedes Mal anders neu erfinden
Die Regeln als Geschäftsregeln und Varianten im Modell festhalten; der Verify-Schritt prüft eine Änderung dagegen. Der Nutzen wächst mit der fachlichen Komplexität, eine CRUD-App holt den Modellierungsaufwand also nicht wieder herein.
Ein Entwickler, der pdd-kit für ein neues Projekt mit spec-kit vergleicht
Zwischen einer Spezifikation pro Feature und einem dauerhaften Produktmodell entscheiden
Das Kanban-Board-Blueprint und die Berichtsoberfläche durchsehen, um das Modellformat kennenzulernen, und dann ein Projekt mit 97 Sternen gegen die weit größere Verbreitung von spec-kit abwägen, bevor man ein Team darauf festlegt.
Bevor du dich festlegst
- Einrichtung
- npx pdd-toolkit install im Repository, dann eine bestehende Codebasis in ein Produktmodell überführen; die Berichtsoberfläche zeigt es an, und Blueprints wie kanban-board veranschaulichen das Format. Node und ein unterstützter Coding-Agent sind die einzigen Voraussetzungen.
- Integrationen
- Arbeitet über das Modell deines Coding-Agenten; positioniert neben spezifikationsgetriebenen Tools (spec-kit, OpenSpec), statt den Agenten zu ersetzen. Modell und Code werden gemeinsam in git geprüft.
- Daten und Datenschutz
- Läuft lokal und schreibt Markdown in dein Repository; der Modellinhalt geht an den Modellanbieter deines Agenten. Das README beschreibt keine Telemetrie. MIT-Lizenz; keine Sicherheitshinweise veröffentlicht.
- Kosten im großen Maßstab
- Keine kostenpflichtige Edition. Die eigentlichen Kosten sind das Verfassen und Pflegen des Produktmodells und die Review-Zeit, um es bei jeder Änderung mit dem Code im Einklang zu halten.
- Grenzen
- Etwa 14 offene Issues; ein einziger Maintainer; schnelle Release-Folge ändert Befehle; kein Nutzen bei Produkten ohne echte fachliche Komplexität, wo der Modellierungsaufwand den Nutzen übersteigt.
Was gut ist
- Ein dauerhaftes Produktmodell, keine pro Feature neu geschriebene Spezifikation
- Strukturierte Entitäten, Journeys, Regeln und Varianten in git
- Berichtsoberfläche und ein ausgearbeitetes Kanban-Board-Blueprint zum Lernen
- Der Verify-Schritt prüft den Code gegen das freigegebene Modell
Was nicht
- Etwa 97 Sterne; ein einziger Maintainer und im Praxiseinsatz unerprobt
- Ein veraltetes Modell führt Agenten stärker in die Irre als gar keins
- Schnelles Release-Tempo verändert Befehle und Vorlagen
- Der Aufwand lohnt sich nur bei Produkten mit echter fachlicher Komplexität
Am besten für
Teams mit Coding-Agenten, die eine lebendige Produktdefinition in git wollen statt einer Spezifikation, die pro Feature geschrieben und verworfen wird.
Alternativen zu pdd-kit
pdd-kit: häufige Fragen
- Lohnt sich pdd-kit?
- Eine schärfere Idee als bei den meisten Spezifikations-Tools, ein dauerhaftes Produktmodell statt Wegwerf-Spezifikationen, getragen von einem Projekt mit 97 Sternen, das eine Person pflegt. Wir bewerten es mit 3.7 von 5.
- Was kostet pdd-kit?
- Kostenlos und Open Source (MIT).
- Welche Nachteile hat pdd-kit?
- Etwa 97 Sterne; ein einziger Maintainer und im Praxiseinsatz unerprobt; Ein veraltetes Modell führt Agenten stärker in die Irre als gar keins; Schnelles Release-Tempo verändert Befehle und Vorlagen; Der Aufwand lohnt sich nur bei Produkten mit echter fachlicher Komplexität.
- Für wen eignet sich pdd-kit?
- Teams mit Coding-Agenten, die eine lebendige Produktdefinition in git wollen statt einer Spezifikation, die pro Feature geschrieben und verworfen wird.
- Was kostet pdd-kit für ein Team oder im Produktivbetrieb?
- Keine kostenpflichtige Edition. Die eigentlichen Kosten sind das Verfassen und Pflegen des Produktmodells und die Review-Zeit, um es bei jeder Änderung mit dem Code im Einklang zu halten.
- Ist pdd-kit sicher für Firmendaten?
- Läuft lokal und schreibt Markdown in dein Repository; der Modellinhalt geht an den Modellanbieter deines Agenten. Das README beschreibt keine Telemetrie. MIT-Lizenz; keine Sicherheitshinweise veröffentlicht.
- Was sind die besten Alternativen zu pdd-kit?
- Die nächsten Alternativen, die wir getestet haben, sind Spec Kit, Elephant-Goldfish Model und BMAD Method.
Antworten geprüft am 30. Okt. 2026.