What is pdd-kit?
pdd-kit, by Itai Gendler, is an open-source toolkit for what it calls Product-Driven Development. Instead of a spec per feature, it keeps a single product-model/ directory in the repo describing the product as entities, interfaces, domains, capabilities, journeys, business rules and variations. Agents and humans read that shared model, and a verify step checks code against it.
It installs with npx pdd-toolkit install and ships a Nuxt-based report UI to browse the model, plus blueprints such as a worked kanban-board example. The author positions it against spec-driven development tools like spec-kit and OpenSpec: where those write a throwaway spec for each change, pdd-kit maintains one living model beside the code.
The repo is MIT-licensed with about 97 GitHub stars, and the pdd-toolkit npm package is at 0.38.0 (25 October 2026). It is a new, single-maintainer project created in July 2026.
Is pdd-kit worth it?
pdd-kit's premise is that the product already exists, scattered across tickets, docs, chats and code, and that every coding agent reconstructs it from scratch and differently each time. Its answer is to write that product down once, as a git-tracked model, and have agents read it. That is a real distinction from spec-kit and OpenSpec, which produce a fresh spec per feature; pdd-kit keeps entities, journeys and business rules as standing documents the whole team and every agent share.
The model is structured rather than free prose. The product-model/ directory separates entities, interfaces, domains, capabilities, journeys, business rules (worded as 'max 3 per order', 'only managers refund') and variations for feature flags or plan tiers. A report UI renders it, and the kanban-board blueprint ships a complete model with no code behind it so a reader can see the shape before adopting it. Because the model and the code change in the same pull request, drift between what the product is and what the code does is meant to surface in review.
The weight is the same one every spec workflow carries, moved earlier: someone has to write and maintain the model, and a model that lags the code is worse than none, because agents will trust it. pdd-kit's own framing, that done means the code matches the approved model, only holds if the model is kept current, and nothing enforces that except reviewer discipline.
The honest limit is adoption. At about 97 stars and ten forks, with a single maintainer and releases moving fast (0.38.0 in late October), this is an early project proving an idea, not a settled standard. The concept is more interesting than spec-kit's; the track record is a fraction of it, and a team betting its process on pdd-kit is betting on one person continuing to ship.
Where it earns its place
A four-engineer SaaS team whose product rules live in Slack and three stale docs
Give their coding agent one source for how the product actually behaves
Run npx pdd-toolkit install, map the existing repo into a product model, and keep journeys and business rules under product-model/ so the agent reads them before building. Free; the cost is the hours to write the first model and the discipline to update it in each pull request.
A tech lead introducing agent coding to a product with complex billing rules
Stop agents reinventing refund and tax logic differently each time
Encode the rules as business rules and variations in the model; the verify step checks a change against them. The payoff scales with domain complexity, so a CRUD app will not earn back the modelling effort.
A developer comparing pdd-kit with spec-kit for a new project
Decide between a per-feature spec and a standing product model
Browse the kanban-board blueprint and report UI to see the model format, then weigh a 97-star project against spec-kit's much larger adoption before standardising a team on it.
Before you commit
- Setup
- npx pdd-toolkit install in the repo, then map an existing codebase into a product model; the report UI browses it and blueprints such as kanban-board show the format. Node and a supported coding agent are the only requirements.
- Integrations
- Works through your coding agent's own model; positioned alongside spec-driven tools (spec-kit, OpenSpec) rather than replacing the agent. Model and code are reviewed together in git.
- Data and privacy
- Runs locally and writes Markdown into your repo; the model content goes to your agent's own model provider. No telemetry is described in the README. MIT licence; no security advisories published.
- Cost at scale
- No paid edition. The real cost is authoring and maintaining the product model, and reviewer time to keep it in step with code on every change.
- Limits
- About 14 open issues; single maintainer; fast release cadence changes commands; no value on products without real domain complexity, where the modelling overhead exceeds the benefit.
What’s good
- A persistent product model, not a spec rewritten per feature
- Structured entities, journeys, rules and variations in git
- Report UI and a worked kanban-board blueprint to learn from
- Verify step checks code against the approved model
What’s not
- About 97 stars; single maintainer and unproven in the wild
- A stale model misleads agents more than no model
- Fast release pace shifts commands and templates
- Overhead only pays off on products with real domain complexity
Best for
Teams on coding agents who want one living product definition in git rather than a spec written and discarded per feature.
pdd-kit alternatives
pdd-kit: common questions
- Is pdd-kit worth it?
- A sharper idea than most spec tools, a persistent product model rather than throwaway specs, carried by a 97-star project one person maintains. We rate it 3.7 out of 5.
- How much does pdd-kit cost?
- Free and open source (MIT).
- What are the downsides of pdd-kit?
- About 97 stars; single maintainer and unproven in the wild; a stale model misleads agents more than no model; fast release pace shifts commands and templates; overhead only pays off on products with real domain complexity.
- Who is pdd-kit best for?
- Teams on coding agents who want one living product definition in git rather than a spec written and discarded per feature.
- How much does pdd-kit cost for a team or in production?
- No paid edition. The real cost is authoring and maintaining the product model, and reviewer time to keep it in step with code on every change.
- Is pdd-kit safe for company data?
- Runs locally and writes Markdown into your repo; the model content goes to your agent's own model provider. No telemetry is described in the README. MIT licence; no security advisories published.
- What are the best pdd-kit alternatives?
- The closest alternatives we have reviewed are Spec Kit, Elephant-Goldfish Model and BMAD Method.
Answers checked Oct 30, 2026.