# SpecScore vs o BMAD Method Canonical: https://specscore.md/pt-br/vs/bmad-method/ O [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD) (método inovador para o desenvolvimento ágil orientado por IA) é uma forma [de código aberto](https://github.com/bmad-code-org/BMAD-METHOD) 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](https://specscore.md/pt-br/spec-driven-development/) (SDD) é a ideia mais ampla em que os dois se situam — o comportamento é especificado antes do código. [SpecScore](https://specscore.md/pt-br/) é um formato [de código aberto](https://github.com/specscore/specscore) para essa especificação, mais uma [interface de linha de comando](https://specscore.md/pt-br/cli/) (CLI). A [integração contínua](https://specscore.md/pt-br/validators/) (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](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/reference/workflow-map.md) 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](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) 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](https://www.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. | Capacidade | BMAD Method | SpecScore | | --- | --- | --- | | Papel principal | Método ágil: agentes, skills e workflows da ideia ao código verificado | **Formato aberto de especificação + CLI** | | Artefatos de planejamento | PRD, spec de UX, arquitetura, épicos e histórias, status do sprint — no mapa de workflow lido em 30 de outubro de 2026 | **Ideias, funcionalidades, planos, tarefas** numa árvore spec/, com ids de requisitos | | Verificação do trabalho | Barreira de prontidão (PASS / CONCERNS / FAIL) e um workflow validate-PRD, executados pelo agente | **specscore spec lint** na CI, determinístico. `/score` é uma nota de IA manual. | | Ids de requisitos | Histó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ção | Node.js e Python para o instalador v6.12 descrito no README | **Nada** além de um único binário Go | | Licença | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) formato · [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) 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](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) executa `specscore spec lint` em cada pull request. O [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) 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](https://github.com/specscore/specscore) 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. ## Fontes. As páginas públicas abaixo foram lidas em 30 de outubro de 2026. Preços, nomes de planos e linhas de versão mudam. - [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) - [BMAD-METHOD — licença MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) - [Mapa de workflow do BMAD (main, lido em 30 de outubro de 2026)](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/reference/workflow-map.md) - [bmadcode.com](https://www.bmadcode.com/) - [specscore/specscore — workflow de CI dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specstudio-skills — skill /score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) - [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) - [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)