Pdd-kit – Product-Driven Development for coding agents An open-source toolkit called pdd-kit, installed via `npx pdd-toolkit install`, introduces Product-Driven Development (PDD) to give coding agents and humans a single git-tracked product model stored in a `product-model/` directory of plain Markdown beside the code. The pdd-kit project positions PDD against spec-driven development tools such as OpenSpec, spec-kit and Kiro, which it says describe each change rather than the product, leaving agents to reconstruct the product definition from scratch and differently each time. The product model is organized into seven artifact types — Entities, Interfaces, Domains, Capabilities, Journeys, Business Rules and Variations — and pdd-kit's verification step checks code against the approved model so drift is easy to spot. Product-Driven Development for coding agents OSS The definition of your product already exists, just unstructured, incomplete and scattered across docs, code, tickets, chats and people. Every coding agent reconstructs it from scratch, and differently each time. PDD gives agents and humans a shared product model that is git-tracked, reviewable, and verifiable. npx pdd-toolkit install The problem the-problem · The Product Model the-product-model · Where it fits clear-product-model-focused-sources · Example example-the-product-model-of-a-kanban-board · Get started -get-started · Development loop the-development-loop · FAQ faq The definition of your product already exists, just unstructured, incomplete and scattered across docs, code, tickets, chats and people. Every coding agent reconstructs it from scratch, and differently each time AI is writing code for products it doesn't understand https://pdd-kit.dev/blog/your-agent-is-guessing . Spec-driven development SDD tools such as OpenSpec, spec-kit and Kiro describe each change , with the product mixed into its design, plan and tasks and spread across feature folders SDD describes the change, not the product https://pdd-kit.dev/blog/pdd-and-spec-driven-development . Product-Driven Development PDD keeps the product in one place , apart from how it's built: a shared product model for agents and humans that is git-tracked, reviewable and verifiable Introducing pdd-kit https://pdd-kit.dev/blog/introducing-pdd-kit . product-model/ , a Product Model https://pdd-kit.dev/docs/product-model : one definition of what the product does, as plain Markdown next to the code. It is made of: - Entities https://pdd-kit.dev/docs/entities : what the product keeps, and who acts on it Order, Customer, Payment provider . - Interfaces https://pdd-kit.dev/docs/interfaces : how people and systems reach the product Web app, Mobile app, Partner API . - Domains https://pdd-kit.dev/docs/domains : the subject areas the product is split into Ordering, Catalog, Billing . - Capabilities https://pdd-kit.dev/docs/capabilities : what the product lets someone do Check out, Cancel order, Refund . - Journeys https://pdd-kit.dev/docs/journeys : one goal, carried across several capabilities Browse and buy, Sign up, Reorder . - Business Rules https://pdd-kit.dev/docs/business-rules : what must always hold, and who may do what Max 3 per order, Only managers refund, Total includes tax . - Variations https://pdd-kit.dev/docs/variations : where the product works in more than one way Feature flag, Plan tier, A/B test . Bring knowledge from docs, designs, code, and people into one product model. Fill gaps, clarify uncertainty, and make every source leaner and more focused. Each information source’s purpose, supported by a shared product model | Information source | Purpose | |---|---| | User docs | Teaches people to use the product | | Internal docs | Records architecture, design decisions, and onboarding | | Design & architecture | Describes how it should look and work | | Code & tests | Implements and verifies how it is built | | Tickets, chats & people | Carry context, requests, and undocumented knowledge | More in the FAQ: Why a Product Model https://github.com/itai-gendler/pdd-kit/blob/main/docs/faq.md why-a-product-model . Agents write code faster than anyone can explain to them what the product is. They fill the gaps by guessing, and the guesses ship. 1. One definition. Not scattered across tickets, docs, chats and people, but one model beside the code. 2. Agents know what to build. They read the Journeys, Scenarios and Rules instead of guessing. 3. Done means it matches the product. Verify checks the code against the approved model. 4. Drift is easy to spot. The model stays a clear reference as behavior changes. 5. Decisions travel with the code. Model and code changes are reviewed in one pull request. To show what a Product Model answers, here is one for a kanban board : a conceptual product where a small team plans its work on shared boards of columns and cards, and an AI agent proposes the next cards . It is the Kanban Board https://github.com/itai-gendler/pdd-kit/tree/main/blueprints/kanban-board Blueprint, a model with no code behind it. Every answer below is read from the model. View the Kanban Board Product Model live Or open it on your machine: npx pdd-toolkit blueprint pull kanban-board npx pdd-toolkit view All 9 entities in the kanban model: what the product keeps, and who acts on it. Which capabilities create, change or remove each entity, filtered to the four capabilities around a proposed card: - Card proposals creates a proposed card, never a card. - Proposed card acceptance is what turns it into a card on the board. - Proposed card dismissal changes the proposal and leaves the board alone. All 23 capabilities in the kanban model: what the product lets someone do. Which interfaces offer each capability, filtered to six card capabilities: - The agent connection offers one capability: proposing cards. - Every change to a card happens in the board web application, by a member. All 32 business rules in the kanban model: what must always hold, and who may do what. Where each business rule is attached, filtered to the five attached to the Proposed card entity: - Creating one: only an AI agent a member connected proposes cards. - Deciding on one: only the board's members accept or dismiss it. - Deleting one: it goes only with its board. The Proposed card entity, one of the 9, and the information kept about it: - Four pieces of information: its title, description, reason and suggested column. How it moves through its states, and the capability behind every move: - Three states: Proposed, then Accepted or Dismissed. Created and Removed mark where its life begins and ends. - Removing it on its own is forbidden from every state; deleting its board removes it. The 4 scenarios of the Card proposals capability: - Four scenarios: proposing cards for a goal, proposing a next step for a stalled card, and two refusals. One of them, opened step by step: - Refuse a direct change from the AI agent: the agent tries to move a card itself, and the product refuses. Every step says who acts, what is read, where, and which business rules govern it. - Its edge case: editing, deleting or creating a card, or accepting its own proposal, is refused the same way. One shared definition of what the product does helps everyone who works on it: - Maintainers and reviewers see a behavior change as a change to the model, reviewed in the same pull request as the code. - New contributors learn what the product does, who may do what and where, without reading the whole codebase first. - Product managers and docs writers find product answers in one place, with optional references to the code and material behind them. - Coding agents read the scenarios and business rules before they change anything, instead of guessing. The pdd-verify skill checks the code against the model. Dogfooded: pdd-kit is developed with pdd-kit. Its own Product Model lives in this repository's product-model/ folder https://github.com/itai-gendler/pdd-kit/blob/main/product-model ; open it with npx pdd-toolkit view itai-gendler/pdd-kit . - 🤖 Agent skills: map, ideate and verify for Claude Code, Codex, Cursor, Gemini CLI and GitHub Copilot - 📝 Markdown-native: every resource is a plain .md file in your repo, reviewed in pull requests - ✅ Lint and verify: npx pdd-toolkit lint checks the files; pdd-verify checks the code against them - 🔁 Fits your workflow: implement with plan mode, an SDD tool or freestyle; check the code against the model when you choose - 🖥️ Local report: npx pdd-toolkit view opens the model in your browser and follows your edits - 📦 Blueprints: start from a reviewed model for a common product instead of a blank page - 🔒 Local-first: no account, no hosted service; the skills read your code and never run it - 🆓 MIT-licensed and open source npx pdd-toolkit install The npm package is pdd-toolkit ; it installs the pdd-kit command, so after npm install --global pdd-toolkit you can run pdd-kit install instead. This adds the skills to the coding agents it detects Claude Code, Codex, Cursor, Gemini CLI or GitHub Copilot , or to Claude Code and Codex when it detects none; you can change the selection. Then start from where you are, inside your agent Codex uses $ instead of / : Have code? Run the map skill: /pdd-map It reads the code without running it, asks what the code can't answer, and writes product-model/ once you approve. Then open the report: npx pdd-toolkit view No code yet? Describe the product you want: /pdd-ideate I want to build a booking app for dog walkers You pick from a few product shapes, then approve the model. From an idea https://pdd-kit.dev/docs/from-an-idea A familiar kind of product? List the reviewed models and pull one: npx pdd-toolkit blueprint list npx pdd-toolkit blueprint pull