SpecScore vs Kiro
Desenvolvimento baseado em especificações (SDD) significa escrever o que o software deve fazer antes de um agente de IA escrever o código. Kiro, da Amazon Web Services (AWS), é um ambiente de desenvolvimento com agentes — um editor, uma interface de linha de comando (CLI) e um aplicativo web — que transforma um prompt em especificações Kiro: requisitos, um design e tarefas. Esses requisitos usam EARS (abordagem fácil para a sintaxe de requisitos), frases no formato “WHEN algo acontece, THE SYSTEM SHALL fazer algo”. SpecScore é um formato de código aberto para a própria especificação, além de uma CLI que verifica os arquivos. Integração contínua (CI) — uma verificação automática de cada mudança proposta — pode rejeitar uma especificação SpecScore que quebre o formato.
O que têm em comum.
O que o Kiro faz bem.
A própria documentação do Kiro, lida em 30 de outubro de 2026, descreve o produto. A página de especificação de funcionalidade estava marcada como atualizada em 4 de agosto de 2026.
Requisitos num formato fixo de frase
As especificações Kiro colocam o comportamento em requirements.md com um padrão EARS: WHEN uma condição vale, THE SYSTEM SHALL fazer uma coisa. A documentação dá o exemplo de um formulário com dados inválidos e do sistema mostrando um erro de validação ao lado do campo. Esse formato é mais fácil de testar do que um parágrafo vago.
Um caminho completo do prompt às tarefas
Uma especificação de funcionalidade passa por requisitos, design (design.md) e tarefas (tasks.md). Dá para começar pelos requisitos ou por um design. O Quick Spec executa os três sem uma parada de aprovação entre eles. As especificações Bugfix são um caminho separado. A documentação também descreve a execução de tarefas independentes em paralelo, em ondas, a partir do grafo de dependências em tasks.md.
Verificações dentro do produto
O Analyze Requirements, disponível no IDE e na CLI, procura inconsistências, ambiguidade, restrições conflitantes e lacunas antes do design. Correctness — testes baseados em propriedades extraídos dessas linhas EARS — aparece só para o IDE, não para a CLI, web ou mobile, na tabela de capacidades das especificações.
Comparação de funcionalidades.
O Kiro é um produto que rascunha especificações. O SpecScore é o formato que um repositório pode verificar. A tabela compara esses papéis.
| Capacidade | Kiro | SpecScore |
|---|---|---|
| Papel principal | IDE com agentes, CLI e aplicativo web que rascunham especificações e implementam tarefas | Formato aberto de especificação + CLI |
| Arquivos da especificação | requirements.md (ou bugfix.md), design.md, tasks.md | Uma árvore spec/ de Markdown + YAML |
| Sintaxe dos requisitos | Padrão EARS: WHEN … THE SYSTEM SHALL … | Ids de requisitos (REQ: slug) e critérios de aceitação Given/When/Then |
| Verificação da especificação | Analyze Requirements no IDE e na CLI. Testes baseados em propriedades no IDE. Não descrito como um linter de formato para a sua própria CI. | specscore spec lint na CI. /score é uma nota de IA separada e manual. |
| Onde roda | Kiro IDE, Kiro CLI, Kiro web. Algumas verificações são só no IDE. | Qualquer repositório — um binário Go, sem conta Kiro |
| Licença | A licença do Kiro diz que o IDE e a CLI são conteúdo da AWS (AWS Content) sob o contrato de cliente da AWS (AWS Customer Agreement). O Kiro Crew é um repositório público separado. | CC BY 4.0 formato · Apache-2.0 CLI |
| Preço | Um nível gratuito e planos pagos. Os números mudam — veja o preço do Kiro, lido em 30 de outubro de 2026. | Sem taxa pelo formato nem pela CLI |
O que o SpecScore acrescenta.
O formato reprova na CI por conta própria
A análise do Kiro roda dentro do Kiro. A verificação do SpecScore é um comando. O workflow dogfood deste repositório executa specscore spec lint em cada pull request e na main. Uma especificação quebrada faz o job falhar do mesmo jeito que um teste quebrado. O skill /score avalia a redação com revisores de IA; essa passagem é manual, e o workflow acima não a executa.
$ 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)
A especificação não está presa a um IDE
As especificações Kiro são Markdown, então dá para lê-las sem o produto. O workflow que as cria e executa é do Kiro. Uma árvore SpecScore são os mesmos arquivos para Claude Code, Cursor, Copilot ou nenhum agente — a CLI não chama um modelo para lintar.
Os requisitos guardam um id
A documentação do Kiro descreve a rastreabilidade como seguir um requisito pela implementação. Ela não descreve um id estável que sobreviva a uma reescrita. O SpecScore endereça um requisito como REQ: slug e um critério de aceitação pelo id dele.
EARS e Given/When/Then respondem a perguntas diferentes
EARS, como o Kiro documenta, é uma frase de comportamento do sistema. Os critérios de aceitação do SpecScore são cenários Given/When/Then ligados a um id de requisito. Dá para escrever uma linha EARS em prosa e ainda guardar o cenário no arquivo SpecScore que o linter verifica. Os padrões de frase estão em a sintaxe de requisitos EARS.
Quando usar cada um.
Recorra ao Kiro quando…
- Você quer um IDE com agentes da AWS que rascunha requisitos, design e tarefas a partir de um prompt e depois implementa as tarefas.
- Você quer frases EARS e, no IDE, testes baseados em propriedades gerados a partir delas.
- Sua equipe já está padronizando no editor, na CLI ou no aplicativo web do Kiro.
Use o SpecScore quando…
- A especificação precisa continuar válida na CI depois que a sessão do agente termina, num repositório que não exige o Kiro.
- Você precisa de ids de requisitos, status de ciclo de vida e um resultado de lint determinístico.
- Você quer o formato de código aberto e o verificador como um único binário.
O Kiro pode rascunhar. O SpecScore pode barrar.
Nada aqui substitui o editor do Kiro. Se o Kiro é onde a equipe escreve prompts, deixe que ele rascunhe. Se a especificação precisa sobreviver como um arquivo revisado, escreva esse contrato no SpecScore e deixe o specscore spec lint reprovar o pull request quando a estrutura quebrar. Os dois arquivos podem ficar no mesmo repositório.
Escolha o Kiro para a sessão. Escolha o SpecScore para o artefato que um job de CI pode recusar.
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.
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
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.