SpecScore vs Spec Kit
Eles operam em camadas diferentes. O Spec Kit é um fluxo de trabalho — um processo guiado que leva um agente da ideia à implementação. O SpecScore é o formato em que as especificações são escritas, mais um CLI que faz lint, consulta e rastreia. O Spec Kit pode produzir arquivos SpecScore.
O que têm em comum.
O que o Spec Kit faz bem.
O Spec Kité um fluxo de trabalho de desenvolvimento orientado a especificações do GitHub Next.
Um processo completo e opinativo
O Spec Kit te dá todo o arco:constitution → specify → plan → tasks → implement. Cada passo tem um slash command e um prompt projetados para manter o agente nos trilhos. Se você quer um processo, o Spec Kit te entrega um.
Forte distribuição e mindshare
Apoiado pelo GitHub Next, com uma grande comunidade e uma biblioteca crescente de extensões. Para muitos desenvolvedores, o Spec Kit é o primeiro fluxo de trabalho orientado a especificações que eles encontram.
Comandos agnósticos a agentes
Os comandos do Spec Kit funcionam em Claude Code, Cursor, Copilot e outros — o fluxo de trabalho conduz o agente independentemente de qual você executa.
Comparação de funcionalidades.
Estas ferramentas respondem a perguntas diferentes, então a tabela compara papéis, não vencedores.
| Capacidade | Spec Kit | SpecScore |
|---|---|---|
| Papel principal | Fluxo de trabalho / metodologia | Formato de armazenamento + CLI |
| Saída de especificação | Markdown em formato livre | Markdown + YAML frontmatter (estruturado) |
| Linting de especificação | Nenhum | Qualidade do conteúdo — verbos vagos, ACs ausentes, referências soltas |
| IDs de requisitos / ACs | Nenhum | IDs endereçáveis por máquina (REQ: slug) |
| Status do ciclo de vida | Implícito (passo do fluxo de trabalho) | Imposto — Draft → Approved → Implementing → Stable → Deprecated |
| Rastreabilidade código-para-especificação | Nenhuma | specscore: anotações + Verifies: trailers de commit |
| Consultar especificações pelo CLI | Scaffolding (specify, plan, tasks) | API de consulta — feature list / show / deps, lint, code refs |
| Dependência de runtime | Python | Nenhuma — binário Go único |
| Integração com CI | Rodar o fluxo de trabalho | specscore lint retorna código diferente de zero, hooks de pre-commit |
| Relacionamento | Eles se compõem — o Spec Kit pode produzir arquivos SpecScore | |
| Licença | MIT | MIT |
O que o SpecScore acrescenta.
A saída é passível de lint
O Spec Kit produz Markdown em formato livre — bom ou ruim, ele entra. O SpecScore verifica o resultado em duas camadas: o lintverifica de forma determinística que todo requisito tem critérios de aceitação, referências cruzadas resolvem e transições de status são válidas — e um revisor de IA (/review, /score) pega critérios ambíguos e verbos vagos.
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found
A saída é consultável
O Spec Kit escreve arquivos; relê-los significa abri-los. As especificações do SpecScore respondem perguntas pelo CLI: specscore feature list,feature deps, code refs — então um agente navega o grafo de especificações sem ler cada arquivo do repositório.
Todo requisito tem um ID
O Spec Kit referencia requisitos por prosa. O SpecScore atribui IDs baseados em slug (REQ: slug-format) e IDs de AC que sobrevivem a renomeações, refatorações e transferências entre agentes.
O ciclo de vida é imposto
No Spec Kit, o estágio de uma especificação é onde quer que você esteja no fluxo de trabalho. No SpecScore, o ciclo de vida é um campo de status imposto — Draft → Approved → Implementing → Stable → Deprecated — validado pelo lint e transicionado por specscore change-status a partir de git hooks ou CI.
O código rastreia de volta às especificações
O Spec Kit não tem mecanismo de rastreabilidade. O SpecScore tem anotações de origem specscore: e trailers de commit Verifies:— execute specscore code refs para uma resposta determinística a "qual código implementa este requisito?"
Sem dependência de runtime
O SpecScore é um binário Go único — sem runtime para instalar. Funciona em projetos Go, Rust, Python, Java ou JavaScript sem adicionar nada ao toolchain.
Quando usar cada um.
Escolha o Spec Kit quando…
- Você quer um processo guiado e opinativo da ideia à implementação.
- Seu time precisa da disciplina de passos explícitos de specify / plan / tasks.
- Você está padronizando como os agentes são conduzidos em um time.
Use o SpecScore quando…
- Você precisa de especificações que agentes possam fazer lint, consultar e mutar sem ler cada arquivo.
- Você precisa de rastreabilidade código-para-especificação com uma resposta determinística.
- Você está construindo um sistema grande com muitas features e transições de ciclo de vida.
- Você quer zero dependências de runtime — um binário, sem necessidade de toolchain de linguagem.
- Você precisa de quality gates de especificação no CI que retornam código diferente de zero, como ESLint ou
go vet.
O SpecScore estende o Spec Kit — não o substitui.
O Spec Kit é o processo para produzir uma especificação; o SpecScore é o formato em que essa especificação pode ser escrita. Uma extensão do Spec Kit que emite o formato SpecScore está a caminho — rode o fluxo de trabalho do Spec Kit e obtenha especificações que fazem lint, consulta e rastreio do outro lado.
Escolha o Spec Kit pelo processo. Escolha o SpecScore pelo artefato. Rode ambos quando quiser ambos.
Feedback
Esta comparação é baseada em documentação e código-fonte publicamente disponíveis. Algo incorreto ou desatualizado? abra uma issue de correção. Quer que comparemos o SpecScore com outra ferramenta? solicite uma.