Comparações

SpecScore vs o BMAD Method

O BMAD Method (método inovador para o desenvolvimento ágil orientado por IA) é uma forma de código aberto de conduzir a entrega ágil com agentes de IA: esclarecer o trabalho, planejá-lo, construí-lo e verificá-lo, com as decisões escritas. Um documento de requisitos do produto (PRD) é a descrição em prosa do que construir e para quem; o mapa de workflow do método produz um, depois a arquitetura e as histórias. O desenvolvimento baseado em especificações (SDD) é a ideia mais ampla em que os dois se situam — o comportamento é especificado antes do código. SpecScore é um formato de código aberto para essa especificação, mais uma interface de linha de comando (CLI). A integração contínua (CI) — uma verificação automática de cada mudança proposta — pode falhar quando um arquivo SpecScore está estruturalmente errado.

O que têm em comum.

  • Ambos se recusam a deixar um agente inventar o produto enquanto escreve o código.
  • Ambos guardam os documentos de planejamento no repositório, em Markdown, ao lado do trabalho.
  • Ambos esperam que uma pessoa aprove o plano antes que a implementação siga sozinha.

O que o BMAD Method faz bem.

O README do projeto, lido em 30 de outubro de 2026, chama a v6.12 de release estável e a v7 de preview na branch main. A data da v7 nesse README já tinha passado. Trate os nomes das linhas como um instantâneo.

Um método que se dimensiona

O README diz que mudanças pequenas vão direto para a construção, e o trabalho maior recebe planejamento. O mapa de workflow na main detalha as fases: um PRD (PRD.md), uma spec de UX opcional, architecture.md com registros de decisão, arquivos de épicos e histórias, e então um sprint. Isso é um ciclo ágil completo, não um único prompt.

Uma barreira antes da implementação

O mesmo mapa lista bmad-check-implementation-readiness, que devolve PASS, CONCERNS ou FAIL antes da implementação. O agente product-manager da v6 também tem um passo validate-PRD. Essas são barreiras de workflow que o agente executa. Não são um linter de formato separado que você aponta para uma árvore Markdown qualquer.

Ele está de fato publicado

O método está sob licença MIT num repositório público. A instalação estável do README é npx bmad-method install, e ele pede Node.js 20.12 ou mais novo e Python 3.10 ou mais novo. O site bmadcode.com diz que o método é gratuito.

Comparação de funcionalidades.

O BMAD é o processo. O SpecScore é o formato do artefato que um processo pode visar. A tabela compara esses papéis.

CapacidadeBMAD MethodSpecScore
Papel principalMétodo ágil: agentes, skills e workflows da ideia ao código verificadoFormato aberto de especificação + CLI
Artefatos de planejamentoPRD, spec de UX, arquitetura, épicos e histórias, status do sprint — no mapa de workflow lido em 30 de outubro de 2026Ideias, funcionalidades, planos, tarefas numa árvore spec/, com ids de requisitos
Verificação do trabalhoBarreira de prontidão (PASS / CONCERNS / FAIL) e um workflow validate-PRD, executados pelo agentespecscore spec lint na CI, determinístico. /score é uma nota de IA manual.
Ids de requisitosHistórias e requisitos funcionais dentro do PRD e dos arquivos de épico. Não é o REQ: slug do SpecScore.REQ: slug e ids de critérios de aceitação
Ambiente de execuçãoNode.js e Python para o instalador v6.12 descrito no READMENada além de um único binário Go
LicençaMIT, bmad-code-org/BMAD-METHODCC BY 4.0 formato · Apache-2.0 CLI

O que o SpecScore acrescenta.

A verificação é um comando, não um passo do método

O resultado de prontidão do BMAD é uma decisão dentro do workflow dele. O resultado do SpecScore é um código de saída de processo. O dogfood.yml executa specscore spec lint em cada pull request. O /score avalia um artefato com os revisores configurados no repositório; você o invoca. A CI não.

$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)

O formato sobrevive a um método diferente

Os documentos do BMAD são moldados pelos workflows dele. Se você parar de rodar o BMAD, ainda tem o Markdown, mas nada fora do método impõe a forma. Uma árvore SpecScore é o contrato. Outro workflow — inclusive o BMAD — pode escrevê-la, e o linter continua valendo.

Histórias e requisitos ficam ligados por id

As histórias do BMAD carregam o contexto adiante para o agente não decidir o produto de novo. O SpecScore torna o vínculo mecânico: uma tarefa do plano cita REQ: slug, e anotações specscore: mais trailers de commit Verifies: apontam o código de volta para o critério.

Quando usar cada um.

Recorra ao BMAD Method quando…

  • Você quer um ciclo ágil completo — PRD, arquitetura, histórias, sprint — executado por agentes com workflows específicos de cada papel.
  • Você quer a barreira de prontidão e o conjunto de perspectivas de produto, arquitetura e teste que o método traz.
  • Você está padronizando como a equipe escreve prompts, e os skills do método são o padrão.

Use o SpecScore quando…

  • A especificação precisa falhar na CI quando um título, um link ou um status está errado, mesmo que ninguém rode o workflow do BMAD naquele dia.
  • Você precisa de ids de requisitos estáveis entre ferramentas, não só dentro dos arquivos de história de um método.
  • Você quer um formato de código aberto que um processo diferente possa visar.

O método pode escrever o formato.

O BMAD responde “como tocamos o trabalho”. O SpecScore responde “qual arquivo é o contrato, e como a CI sabe que ele está intacto”. Uma equipe pode manter o PRD e as histórias do BMAD para a conversa, e manter uma funcionalidade SpecScore para os requisitos que precisam passar no lint.

Use o BMAD Method para o ciclo. Use o SpecScore para o artefato que o pull request verifica.

Outras comparações.

O mesmo formato, ao lado de outras ferramentas de desenvolvimento guiado por especificação:

Todas juntas, em uma página: melhores ferramentas de desenvolvimento guiado por especificação em 2026.

Feedback

Specs que passam.

Encontrou um erro na tradução ou tem uma ideia para melhorar esta página?