Melhores ferramentas de desenvolvimento guiado por especificação em 2026
SpecScore é um formato de arquivo aberto e lintável para especificações, escrito em Markdown e YAML (YAML Ain't Markup Language). Desenvolvimento guiado por especificação (SDD) é uma prática em que uma especificação escrita é a fonte de verdade com base na qual o código é construído e contra a qual ele é conferido. Ferramentas de desenvolvimento guiado por especificação são os formatos, fluxos de trabalho e produtos usados para escrever, guardar e às vezes conferir essas especificações. Um documento de requisitos do produto (PRD) é prosa que declara o problema e o escopo antes que alguém o divida em tarefas. Abordagem Fácil à Sintaxe de Requisitos (EARS) é uma frase de requisito na forma “WHEN algo acontece, THE SYSTEM SHALL fazer algo”. Uma interface de linha de comando (CLI) é um programa que você executa em um terminal. Integração contínua (CI) é uma verificação automática de cada mudança proposta.
Esta comparação de ferramentas de desenvolvimento guiado por especificação abrange GitHub Spec Kit, OpenSpec, Kiro, Tessl, o BMAD Method, Task Master AI, CodeSpeak, Datarim, Markdown simples e SpecScore. Páginas públicas e repositórios foram lidos em 30 de outubro de 2026. Comandos, a disposição dos arquivos e o que um produto confere podem mudar; as fontes no final nomeiam a página de onde vem cada afirmação.
A divisão que importa para um repositório é se a especificação consegue falhar na CI por conta própria. No repositório do site do SpecScore, dogfood.yml instala o CLI do SpecScore e executa specscore spec lint em pull requests e em pushes para a main. O skill /score em specstudio-skills é uma nota manual de IA de um artefato. Você o invoca. Esse fluxo de trabalho não.
Ferramentas de desenvolvimento guiado por especificação, lado a lado.
Cada linha é um papel, não uma pontuação. Siga o nome até a comparação do SpecScore, ou o título abaixo até a fonte da célula.
| Ferramenta | O que é | Como as especificações são escritas e guardadas | Validação automática da especificação | Licença | Para quem serve |
|---|---|---|---|---|---|
| GitHub Spec Kit | Fluxo de trabalho de agente que produz artefatos Markdown | Diretório da funcionalidade sob specs/: spec.md, plan.md, tasks.md | /speckit.analyze relata lacunas entre artefatos na sessão do agente. Extensões da comunidade podem acrescentar portões. | MIT em github/spec-kit | Uma equipe que quer um processo compartilhado para o agente |
| OpenSpec | Pastas de mudança e comandos de agente para combinar antes do código | Markdown simples sob openspec/changes/: proposal, specs, design, tasks | openspec validate confere a estrutura da mudança e da spec e pode sair com código diferente de zero, inclusive a partir de um script de CI. | MIT em Fission-AI/OpenSpec | Uma equipe que quer uma pasta de mudança leve mais uma conferência de estrutura |
| Kiro | IDE agêntica, CLI e aplicativo web da AWS que redige specs | requirements.md em EARS, mais design.md e tasks.md | Analyze Requirements dentro do Kiro, antes do design. A página de spec de funcionalidade descreve essa conferência no produto. | A IDE e a CLI são conteúdo da AWS (AWS Content) sob a licença do Kiro (AWS Customer Agreement). | Alguém que quer que o Kiro redija os requisitos, o design e as tarefas |
| Tessl | Plataforma de skills para agentes, mais um tile de desenvolvimento guiado por especificação | Skills como arquivos no repositório. O tile escreve .spec.md sob specs/. | O tile traz scripts/validate-specs.sh e scripts/check-spec-links.sh. Os GitHub Actions dele fazem lint do próprio tile. | O tile é MIT em tesslio/spec-driven-development-tile. A plataforma é o produto da Tessl. | Uma equipe que padroniza skills de agente, ou que usa as regras de spec antes do código do tile |
| BMAD Method | Método ágil para desenvolvimento conduzido por IA | Briefs, especificações e arquitetura que você pode levar para outro fluxo de trabalho | O README descreve os artefatos do método e os fluxos de trabalho do agente. Não documenta um linter de formato para a CI. | MIT em bmad-code-org/BMAD-METHOD, com um aviso de marca nesse arquivo. | Uma equipe que quer um método ágil de agente no tamanho da mudança |
| Task Master AI | Lista de tarefas para agentes de código, extraída de um PRD | Prosa de PRD, muitas vezes .taskmaster/docs/prd.txt, e então as tarefas geradas | O README descreve a análise de um PRD em tarefas. Não descreve um linter para o PRD. | MIT com uma Commons Clause em eyaltoledano/claude-task-master | Uma equipe que já tem um PRD e quer dividi-lo em tarefas |
| CodeSpeak | Kit agêntico que transforma a intenção do chat em requisitos mapeados ao código | Requisitos estruturados dentro do produto, mapeados ao código | O site diz que os requisitos são aplicados em cada mudança, dentro do produto. | Termos de serviço (vigentes em 3 de março de 2026): a CodeSpeak Ltd retém o Serviço, inclusive o código-fonte dele. O site do produto não publica um repositório de código do kit. | Uma equipe que quer a intenção capturada dos chats e mantida mapeada ao código |
| Datarim | Fluxo de trabalho iterativo para Claude Code, Codex CLI, Cursor e Antigravity | /dr-prd escreve um PRD. As tarefas ativas ficam em backlog.md. | /dr-compliance e /dr-dream lint rodam quando você invoca esses comandos. | MIT em Arcanada-one/datarim | Uma equipe que quer comandos em etapas e um backlog no repositório |
| Plain Markdown | Um arquivo Markdown comum que você escreve e faz commit | Qualquer arquivo .md, no diretório que você escolher | A revisão que você fizer lendo, até acrescentar um verificador | Não há produto nem arquivo de licença. Os termos do arquivo são os do repositório. | Uma nota curta, um spike ou uma revisão que você fará lendo |
| SpecScore | Formato aberto de especificação mais um CLI que faz lint dos arquivos | Markdown + YAML em uma árvore spec/ | dogfood.yml executa specscore spec lint em pull requests e pushes para a main. /score é uma nota manual de IA, e esse fluxo de trabalho não o executa. | CC BY 4.0 para o formato em specscore/specscore. Apache-2.0 para o CLI em specscore/specscore-cli. | Uma equipe que precisa que o arquivo da spec falhe na CI quando o formato quebra |
GitHub Spec Kit
GitHub Spec Kit é um kit aberto que entrega a um agente de código um processo: Specify, Plan, Tasks, Implement e Converge. A página inicial da documentação do Spec Kit, datada de 28 de setembro de 2026, diz que cada fase produz um artefato Markdown que a fase seguinte lê.
Esses arquivos ficam em um diretório de funcionalidade sob specs/. O guia de atualização, lido em 30 de outubro de 2026, dá caminhos como specs/001-my-feature/spec.md, com plan.md e tasks.md ao lado. A referência de SDD agêntico descreve /speckit.analyze como um relatório de inconsistências entre a spec, o plano e as tarefas, sem editar os arquivos. /speckit.clarify e /speckit.checklist são outros comandos que você executa no agente. A página inicial da documentação também nomeia extensões da comunidade, inclusive uma chamada CI Guard, que acrescentam portões de conformidade.
A licença é MIT, no repositório público github/spec-kit. O Spec Kit serve a uma equipe que quer esse processo e aceita manter a especificação como o Markdown que o agente escreveu. O lado a lado com o SpecScore está em SpecScore vs Spec Kit.
OpenSpec
OpenSpec, da Fission-AI, guarda cada mudança na própria pasta para que uma pessoa e um agente possam combinar antes de o código ser escrito. O README, lido em 30 de outubro de 2026, mostra openspec/changes/add-dark-mode/ com proposal.md, um diretório specs/, design.md e tasks.md. Os requisitos são Markdown simples: uma declaração SHALL e um cenário WHEN / THEN. O mesmo README diz que oferece suporte a 30+ assistentes de IA.
openspec validate confere mudanças e specs em busca de problemas estruturais. A referência da CLI, lida em 30 de outubro de 2026, documenta uma saída diferente de zero quando a validação falha, e um trecho de shell que um job de CI pode executar. Essa conferência é a estrutura de mudança e de spec do OpenSpec.
A licença é MIT, em Fission-AI/OpenSpec. O OpenSpec serve a uma equipe que quer a pasta de mudança e essa conferência de estrutura. Veja SpecScore vs OpenSpec.
Kiro
Kiro, da Amazon Web Services (AWS), é um ambiente de desenvolvimento agêntico: um editor, uma CLI e um aplicativo web. A página de specs de funcionalidade, atualizada em 4 de agosto de 2026, conduz uma funcionalidade por requisitos, design e tarefas. requirements.md usa EARS. design.md e tasks.md ficam ao lado. O Quick Spec pode executar os três sem uma parada de aprovação entre eles.
O Analyze Requirements procura inconsistências, ambiguidade, restrições conflitantes e lacunas antes do design. Essa análise roda dentro do Kiro. A página de spec de funcionalidade descreve a conferência no produto.
A licença do Kiro, lida em 30 de outubro de 2026, diz que a IDE e a CLI são licenciadas como conteúdo da AWS (AWS Content) sob o contrato de cliente da AWS (AWS Customer Agreement) ou outro acordo escrito, e a AWS Intellectual Property License. O Kiro serve a alguém que quer que esse produto redija os três arquivos. Veja SpecScore vs Kiro. Os padrões de frase estão em a sintaxe de requisitos EARS.
Tessl
A documentação da Tessl, lida em 30 de outubro de 2026, descreve uma plataforma aberta para gerenciar skills de agente: um registro, governança, evals e controles relacionados. Skills, regras e docs são arquivos no repositório.
Um artefato separado, o tile de desenvolvimento guiado por especificação, é publicado a partir de tesslio/spec-driven-development-tile e listado no registro da Tessl. O README do tile diz que o agente escreve arquivos .spec.md em um diretório specs/, com frontmatter YAML, targets e links [@test]. Ele documenta scripts/validate-specs.sh e scripts/check-spec-links.sh, e GitHub Actions que fazem lint do próprio tile.
A licença do tile é MIT, nesse repositório. A documentação descreve a plataforma de registro como produto da Tessl e não aponta um repositório público da plataforma inteira. A Tessl serve a uma equipe que padroniza skills, ou a uma equipe que quer a orientação de spec antes do código do tile. Veja SpecScore vs Tessl.
BMAD Method
O README do repositório BMAD Method, lido em 30 de outubro de 2026, descreve um método ágil para desenvolvimento conduzido por IA. Diz que você pode usar o método de ponta a ponta, ou levar os briefs, as especificações e a arquitetura para um fluxo de trabalho que você já tem. A linha estável nomeada ali é a v6.12. A v7 é descrita como uma prévia no branch main. O projeto escreve o nome como BMad; o repositório é BMAD-METHOD.
O README centra esses artefatos de planejamento e as skills de agente que os produzem. Não documenta um comando que faça lint de um esquema fixo de spec na CI.
A licença é MIT, em bmad-code-org/BMAD-METHOD. Esse arquivo de licença também traz um aviso de marca para BMad. O método serve a uma equipe que quer o ciclo ágil e vai manter a especificação nesses briefs e specs. Veja SpecScore vs the BMAD Method.
Task Master AI
Task Master AI é uma lista de tarefas para agentes de código de IA. O README, lido em 30 de outubro de 2026, recomenda um PRD, muitas vezes em .taskmaster/docs/prd.txt, e task-master parse-prd para transformar essa prosa em tarefas. A documentação cobre a estrutura das tarefas, as dependências e as tags.
O README trata o PRD como entrada e a lista de tarefas como aquilo a partir do qual o agente trabalha. Não descreve um linter para a redação ou a estrutura do PRD.
A licença é MIT com uma Commons Clause, em eyaltoledano/claude-task-master. O README diz que você pode construir produtos com o Task Master, e que vender o próprio Task Master ou oferecê-lo como um serviço hospedado está fora dessa concessão. Serve a uma equipe que quer o PRD dividido em tarefas. Veja SpecScore vs Task Master AI.
CodeSpeak
O site do CodeSpeak, lido em 30 de outubro de 2026, descreve um kit de engenharia agêntico. Ele captura a intenção dos chats do agente, transforma essa intenção em requisitos estruturados mapeados ao código e diz que aplica esses requisitos em cada mudança. O site também diz que uma ferramenta web recupera a intenção dos chats até o produto completo ser lançado.
Os termos de serviço, vigentes em 3 de março de 2026, afirmam que a CodeSpeak Ltd retém o Serviço, inclusive o software e o código-fonte dele. O site do produto não publica um repositório de código desse kit, então esta página não nomeia uma licença de software para ele.
O CodeSpeak serve a uma equipe que quer requisitos capturados da conversa e mantidos mapeados ao código dentro desse produto. Veja SpecScore vs CodeSpeak.
Datarim
O README do Datarim, com um selo de versão 4.9.0 e lido em 30 de outubro de 2026, descreve um fluxo de trabalho iterativo para Claude Code, Codex CLI, Cursor e Google Antigravity. /dr-prd gera um PRD. As tarefas ativas ficam em backlog.md, com o histórico concluído em backlog-archive.md.
/dr-compliance confere uma implementação contra o PRD quando você executa esse comando. /dr-dream lint faz uma verificação de saúde de uma base de conhecimento em busca de contradições, órfãos, links quebrados, conteúdo desatualizado e duplicatas. Esses são comandos no fluxo de trabalho.
A licença é MIT, em Arcanada-one/datarim. O Datarim serve a uma equipe que quer esses comandos em etapas nos agentes que o README nomeia. Veja SpecScore vs Datarim.
Plain Markdown
Markdown simples é a especificação como um arquivo .md comum: um título, alguns tópicos, onde você fizer o commit. Não há esquema. A revisão é alguém lendo o arquivo, até você acrescentar um verificador próprio.
Não há produto nem arquivo de licença para vincular. Os termos do arquivo são a licença que você aplicar ao repositório. O Markdown simples serve a uma nota curta, um spike ou uma equipe que vai revisar a prosa lendo-a. Veja SpecScore vs plain Markdown.
SpecScore
SpecScore é um formato para a especificação — funcionalidades, requisitos e critérios de aceitação como Markdown com YAML — e um CLI que confere os arquivos. O formato fica em specscore/specscore. O CLI fica em specscore/specscore-cli.
Como escrever os critérios para que um agente possa verificá-los está em como escrever critérios de aceitação.
Um modelo de especificação de funcionalidade em Markdown — requisitos, critérios de aceitação, um plano e tarefas — está em modelo de PRD em Markdown.
O desenvolvimento guiado por especificação com Claude Code e Cursor — o arquivo da funcionalidade, o arquivo de instruções do agente e specscore spec lint no laço estão em desenvolvimento guiado por especificação com Claude Code e Cursor.
Como executar esse linter na integração contínua está em como lintar especificações na CI.
No repositório deste site, dogfood.yml instala esse CLI e executa specscore spec lint em pull requests e em pushes para a main. Uma spec que quebra o formato faz esse job falhar. O skill /score é uma nota manual de IA: ele executa de novo os revisores configurados quando você pede, e o fluxo de trabalho dogfood não o chama.
A licença do formato é CC BY 4.0, em specscore/specscore. A licença do CLI é Apache-2.0, em specscore/specscore-cli. O SpecScore serve a uma equipe que precisa que a especificação falhe na CI quando um título, um link ou um status está errado, qualquer que seja o agente que escreveu o arquivo. openspec validate é a conferência estrutural mais próxima entre as outras ferramentas desta página; ele confere a própria forma de mudança do OpenSpec. As comparações individuais começam em /vs/.
Como escolher.
Escolha GitHub Spec Kit, OpenSpec, o BMAD Method ou o Datarim quando você quer um processo guiado e Markdown que dá para revisar em um pull request. Escolha o Kiro quando você quer que esse produto redija requisitos EARS. Escolha o Task Master AI quando o PRD deve virar uma lista de tarefas. Escolha o CodeSpeak quando a intenção deve ser capturada dos chats dentro desse produto. Escolha a Tessl quando o problema são skills de agente, com o tile de spec como uma orientação opcional.
Escolha o SpecScore quando o próprio arquivo da especificação tem de falhar na CI. A conferência neste repositório é specscore spec lint em dogfood.yml. Um fluxo de trabalho da lista acima ainda pode ser o modo como a spec é escrita.
Fontes.
Lido em 30 de outubro de 2026, exceto onde a página imprime a própria data de atualização. Preços e nomes de planos ficam de fora porque mudam.