¿Qué es pdd-kit?
pdd-kit, de Itai Gendler, es un kit de código abierto para lo que llama Product-Driven Development. En lugar de una especificación por funcionalidad, mantiene en el repositorio un único directorio product-model/ que describe el producto como entidades, interfaces, dominios, capacidades, recorridos, reglas de negocio y variaciones. Agentes y personas leen ese modelo compartido, y un paso de verificación contrasta el código con él.
Se instala con npx pdd-toolkit install e incluye una interfaz de informes basada en Nuxt para explorar el modelo, además de blueprints como un ejemplo completo de tablero kanban. El autor lo sitúa frente a herramientas de desarrollo guiado por especificaciones como spec-kit y OpenSpec: donde estas escriben una especificación desechable para cada cambio, pdd-kit mantiene un modelo vivo junto al código.
El repositorio tiene licencia MIT y unas 97 estrellas en GitHub, y el paquete npm pdd-toolkit está en la 0.38.0 (25 de octubre de 2026). Es un proyecto nuevo, de un solo mantenedor, creado en julio de 2026.
¿Merece la pena pdd-kit?
La premisa de pdd-kit es que el producto ya existe, disperso entre tickets, documentos, chats y código, y que cada agente de programación lo reconstruye desde cero y de forma distinta cada vez. Su respuesta es poner ese producto por escrito una vez, como un modelo versionado en git, y hacer que los agentes lo lean. Es una diferencia real con spec-kit y OpenSpec, que producen una especificación nueva por funcionalidad; pdd-kit mantiene entidades, recorridos y reglas de negocio como documentos permanentes que comparten todo el equipo y todos los agentes.
El modelo es estructurado, no prosa libre. El directorio product-model/ separa entidades, interfaces, dominios, capacidades, recorridos, reglas de negocio (redactadas como «máximo 3 por pedido» o «solo los gerentes reembolsan») y variaciones para feature flags o niveles de plan. Una interfaz de informes lo muestra, y el blueprint del tablero kanban incluye un modelo completo sin código detrás para que el lector vea la forma antes de adoptarlo. Como el modelo y el código cambian en la misma pull request, las divergencias entre lo que es el producto y lo que hace el código deberían aflorar en la revisión.
La carga es la misma que lleva todo flujo basado en especificaciones, solo que adelantada: alguien tiene que escribir y mantener el modelo, y un modelo que va por detrás del código es peor que ninguno, porque los agentes se fiarán de él. El propio planteamiento de pdd-kit, que terminar significa que el código coincide con el modelo aprobado, solo se sostiene si el modelo está al día, y nada lo garantiza salvo la disciplina de quien revisa.
El límite honesto es la adopción. Con unas 97 estrellas y diez forks, un solo mantenedor y versiones que avanzan rápido (0.38.0 a finales de octubre), es un proyecto temprano que pone a prueba una idea, no un estándar asentado. El concepto es más interesante que el de spec-kit; su historial es una fracción del de este, y un equipo que apuesta su proceso a pdd-kit apuesta a que una persona siga publicando.
Dónde se gana su sitio
Un equipo SaaS de cuatro ingenieros cuyas reglas de producto viven en Slack y en tres documentos desactualizados
Dar a su agente de programación una única fuente sobre cómo se comporta de verdad el producto
Ejecuta npx pdd-toolkit install, traslada el repositorio existente a un modelo de producto y mantén recorridos y reglas de negocio en product-model/ para que el agente los lea antes de construir. Gratis; el coste son las horas para escribir el primer modelo y la disciplina de actualizarlo en cada pull request.
Una responsable técnica que introduce la programación con agentes en un producto con reglas de facturación complejas
Evitar que los agentes reinventen cada vez de forma distinta la lógica de reembolsos e impuestos
Codifica las reglas como reglas de negocio y variaciones en el modelo; el paso de verificación contrasta cada cambio con ellas. El beneficio crece con la complejidad del dominio, así que una app CRUD no recuperará el esfuerzo de modelado.
Un desarrollador que compara pdd-kit con spec-kit para un proyecto nuevo
Elegir entre una especificación por funcionalidad y un modelo de producto permanente
Explora el blueprint del tablero kanban y la interfaz de informes para ver el formato del modelo, y después sopesa un proyecto de 97 estrellas frente a la adopción mucho mayor de spec-kit antes de estandarizar un equipo en él.
Antes de decidirte
- Puesta en marcha
- npx pdd-toolkit install en el repositorio y después trasladar un código existente a un modelo de producto; la interfaz de informes lo explora y blueprints como kanban-board muestran el formato. Node y un agente de programación compatible son los únicos requisitos.
- Integraciones
- Funciona a través del propio modelo de tu agente de programación; se sitúa junto a herramientas guiadas por especificaciones (spec-kit, OpenSpec) en lugar de sustituir al agente. Modelo y código se revisan juntos en git.
- Datos y privacidad
- Se ejecuta en local y escribe Markdown en tu repositorio; el contenido del modelo va al proveedor de modelos de tu agente. El README no describe telemetría. Licencia MIT; no hay avisos de seguridad publicados.
- Coste a escala
- Sin edición de pago. El coste real es redactar y mantener el modelo de producto, y el tiempo de revisión para mantenerlo al ritmo del código en cada cambio.
- Límites
- Unas 14 incidencias abiertas; un solo mantenedor; el ritmo rápido de versiones cambia los comandos; no aporta valor en productos sin verdadera complejidad de dominio, donde el esfuerzo de modelado supera el beneficio.
Lo bueno
- Un modelo de producto persistente, no una especificación reescrita por funcionalidad
- Entidades, recorridos, reglas y variaciones estructurados en git
- Interfaz de informes y un blueprint completo de tablero kanban para aprender
- El paso de verificación contrasta el código con el modelo aprobado
Lo malo
- Unas 97 estrellas; un solo mantenedor y sin pruebas en uso real
- Un modelo desactualizado engaña más a los agentes que no tener modelo
- El ritmo rápido de versiones cambia comandos y plantillas
- El esfuerzo solo compensa en productos con verdadera complejidad de dominio
Ideal para
Equipos que usan agentes de programación y quieren una única definición de producto viva en git en lugar de una especificación escrita y descartada por funcionalidad.
Alternativas a pdd-kit
pdd-kit: preguntas frecuentes
- ¿Merece la pena pdd-kit?
- Una idea más afilada que la de la mayoría de herramientas de especificación, un modelo de producto persistente en lugar de especificaciones desechables, sostenida por un proyecto de 97 estrellas que mantiene una sola persona. Le damos un 3.7 sobre 5.
- ¿Cuánto cuesta pdd-kit?
- Gratuito y de código abierto (MIT).
- ¿Qué inconvenientes tiene pdd-kit?
- Unas 97 estrellas; un solo mantenedor y sin pruebas en uso real; un modelo desactualizado engaña más a los agentes que no tener modelo; el ritmo rápido de versiones cambia comandos y plantillas; el esfuerzo solo compensa en productos con verdadera complejidad de dominio.
- ¿Para quién es pdd-kit?
- Equipos que usan agentes de programación y quieren una única definición de producto viva en git en lugar de una especificación escrita y descartada por funcionalidad.
- ¿Cuánto cuesta pdd-kit para un equipo o en producción?
- Sin edición de pago. El coste real es redactar y mantener el modelo de producto, y el tiempo de revisión para mantenerlo al ritmo del código en cada cambio.
- ¿Es pdd-kit seguro para los datos de la empresa?
- Se ejecuta en local y escribe Markdown en tu repositorio; el contenido del modelo va al proveedor de modelos de tu agente. El README no describe telemetría. Licencia MIT; no hay avisos de seguridad publicados.
- ¿Cuáles son las mejores alternativas a pdd-kit?
- Las alternativas más cercanas que hemos analizado son Spec Kit, Elephant-Goldfish Model y BMAD Method.
Respuestas comprobadas el 30 oct 2026.