O que é pdd-kit?
O pdd-kit, de Itai Gendler, é um kit de ferramentas de código aberto para o que ele chama de Product-Driven Development. Em vez de uma spec por recurso, ele mantém no repositório um único diretório product-model/ que descreve o produto como entidades, interfaces, domínios, capacidades, jornadas, regras de negócio e variações. Agentes e pessoas leem esse modelo compartilhado, e uma etapa de verificação confere o código contra ele.
Ele se instala com npx pdd-toolkit install e traz uma interface de relatório baseada em Nuxt para navegar pelo modelo, além de blueprints como um exemplo completo de quadro kanban. O autor o posiciona contra ferramentas de desenvolvimento orientado a specs como spec-kit e OpenSpec: enquanto elas escrevem uma spec descartável para cada mudança, o pdd-kit mantém um modelo vivo ao lado do código.
O repositório tem licença MIT e cerca de 97 estrelas no GitHub, e o pacote npm pdd-toolkit está na 0.38.0 (25 de outubro de 2026). É um projeto novo, de um único mantenedor, criado em julho de 2026.
pdd-kit vale a pena?
A premissa do pdd-kit é que o produto já existe, espalhado entre tickets, documentos, chats e código, e que cada agente de programação o reconstrói do zero e de um jeito diferente a cada vez. A resposta é escrever esse produto uma vez, como um modelo versionado no git, e fazer os agentes o lerem. É uma diferença real em relação ao spec-kit e ao OpenSpec, que produzem uma spec nova por recurso; o pdd-kit mantém entidades, jornadas e regras de negócio como documentos permanentes que a equipe inteira e todos os agentes compartilham.
O modelo é estruturado, não prosa livre. O diretório product-model/ separa entidades, interfaces, domínios, capacidades, jornadas, regras de negócio (redigidas como 'max 3 per order', 'only managers refund') e variações para feature flags ou níveis de plano. Uma interface de relatório o exibe, e o blueprint de quadro kanban traz um modelo completo sem código por trás, para que o leitor veja o formato antes de adotá-lo. Como modelo e código mudam no mesmo pull request, a divergência entre o que o produto é e o que o código faz deve aparecer na revisão.
O peso é o mesmo que todo fluxo baseado em specs carrega, só que antecipado: alguém precisa escrever e manter o modelo, e um modelo atrasado em relação ao código é pior que nenhum, porque os agentes vão confiar nele. A própria definição do pdd-kit, de que pronto significa que o código bate com o modelo aprovado, só vale se o modelo for mantido em dia, e nada garante isso além da disciplina dos revisores.
O limite honesto é a adoção. Com cerca de 97 estrelas e dez forks, um único mantenedor e versões andando rápido (0.38.0 no fim de outubro), é um projeto inicial provando uma ideia, não um padrão consolidado. O conceito é mais interessante que o do spec-kit; o histórico é uma fração do dele, e uma equipe que aposta seu processo no pdd-kit está apostando que uma pessoa continue entregando.
Onde ele se destaca
Uma equipe SaaS de quatro engenheiros cujas regras de produto vivem no Slack e em três documentos desatualizados
Dar ao agente de programação uma única fonte sobre como o produto realmente se comporta
Rodar npx pdd-toolkit install, mapear o repositório existente em um modelo de produto e manter jornadas e regras de negócio em product-model/ para que o agente as leia antes de construir. Gratuito; o custo são as horas para escrever o primeiro modelo e a disciplina para atualizá-lo em cada pull request.
Um tech lead introduzindo programação com agentes em um produto com regras de cobrança complexas
Impedir que os agentes reinventem a lógica de reembolso e impostos de um jeito diferente a cada vez
Codificar as regras como regras de negócio e variações no modelo; a etapa de verificação confere cada mudança contra elas. O retorno cresce com a complexidade do domínio, então um app CRUD não vai recuperar o esforço de modelagem.
Um desenvolvedor comparando pdd-kit e spec-kit para um projeto novo
Decidir entre uma spec por recurso e um modelo de produto permanente
Navegar pelo blueprint de quadro kanban e pela interface de relatório para ver o formato do modelo, e depois pesar um projeto de 97 estrelas contra a adoção muito maior do spec-kit antes de padronizar uma equipe nele.
Antes de decidir
- Configuração
- npx pdd-toolkit install no repositório, depois mapear um código existente em um modelo de produto; a interface de relatório o navega e blueprints como kanban-board mostram o formato. Node e um agente de programação suportado são os únicos requisitos.
- Integrações
- Funciona pelo próprio modelo do seu agente de programação; posicionado ao lado de ferramentas orientadas a specs (spec-kit, OpenSpec), sem substituir o agente. Modelo e código são revisados juntos no git.
- Dados e privacidade
- Roda localmente e escreve Markdown no seu repositório; o conteúdo do modelo vai para o provedor de modelo do seu agente. O README não descreve telemetria. Licença MIT; nenhum aviso de segurança publicado.
- Custo em escala
- Sem edição paga. O custo real é escrever e manter o modelo de produto, além do tempo dos revisores para mantê-lo alinhado ao código a cada mudança.
- Limites
- Cerca de 14 issues abertos; mantenedor único; o ritmo rápido de versões muda comandos; nenhum valor em produtos sem complexidade de domínio real, onde o esforço de modelagem supera o benefício.
O que é bom
- Um modelo de produto persistente, não uma spec reescrita a cada recurso
- Entidades, jornadas, regras e variações estruturadas no git
- Interface de relatório e um blueprint completo de quadro kanban para aprender
- A etapa de verificação confere o código contra o modelo aprovado
O que não é
- Cerca de 97 estrelas; mantenedor único e sem prova no mundo real
- Um modelo desatualizado engana os agentes mais do que nenhum modelo
- O ritmo rápido de versões muda comandos e templates
- O esforço extra só compensa em produtos com complexidade de domínio real
Ideal para
Equipes que usam agentes de programação e querem uma definição de produto viva no git, em vez de uma spec escrita e descartada a cada recurso.
Alternativas ao pdd-kit
pdd-kit: perguntas frequentes
- pdd-kit vale a pena?
- Uma ideia mais afiada que a da maioria das ferramentas de specs, um modelo de produto persistente em vez de specs descartáveis, sustentada por um projeto de 97 estrelas que uma pessoa mantém. Damos nota 3.7 de 5.
- Quanto custa pdd-kit?
- Gratuito e de código aberto (MIT).
- Quais são as desvantagens de pdd-kit?
- Cerca de 97 estrelas; mantenedor único e sem prova no mundo real; um modelo desatualizado engana os agentes mais do que nenhum modelo; o ritmo rápido de versões muda comandos e templates; o esforço extra só compensa em produtos com complexidade de domínio real.
- Para quem pdd-kit é indicado?
- Equipes que usam agentes de programação e querem uma definição de produto viva no git, em vez de uma spec escrita e descartada a cada recurso.
- Quanto custa pdd-kit para uma equipe ou em produção?
- Sem edição paga. O custo real é escrever e manter o modelo de produto, além do tempo dos revisores para mantê-lo alinhado ao código a cada mudança.
- pdd-kit é seguro para dados da empresa?
- Roda localmente e escreve Markdown no seu repositório; o conteúdo do modelo vai para o provedor de modelo do seu agente. O README não descreve telemetria. Licença MIT; nenhum aviso de segurança publicado.
- Quais são as melhores alternativas ao pdd-kit?
- As alternativas mais próximas que analisamos são Spec Kit, Elephant-Goldfish Model e BMAD Method.
Respostas verificadas em 30 de out. de 2026.