# SpecScore vs Kiro Canonical: https://specscore.md/pt-br/vs/kiro/ [Desenvolvimento baseado em especificações](https://specscore.md/pt-br/spec-driven-development/) (SDD) significa escrever o que o software deve fazer antes de um agente de IA escrever o código. [Kiro](https://kiro.dev/), da Amazon Web Services (AWS), é um ambiente de desenvolvimento com agentes — um editor, uma [interface de linha de comando](https://specscore.md/pt-br/cli/) (CLI) e um aplicativo web — que transforma um prompt em especificações Kiro: requisitos, um design e tarefas. Esses requisitos usam [EARS](https://kiro.dev/docs/specs/feature-specs/) (abordagem fácil para a sintaxe de requisitos), frases no formato “WHEN algo acontece, THE SYSTEM SHALL fazer algo”. [SpecScore](https://specscore.md/pt-br/) é um formato [de código aberto](https://github.com/specscore/specscore) para a própria especificação, além de uma CLI que verifica os arquivos. [Integração contínua](https://specscore.md/pt-br/validators/) (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. - Ambos tratam uma especificação escrita como aquilo a partir do qual o agente deve construir, e não como a transcrição de um chat. - Ambos guardam essa especificação como Markdown no projeto, para que ela possa ser revisada como código. - Ambos dividem o trabalho em requisitos, um design e tarefas. O Kiro gera esses três arquivos. O SpecScore é um formato que a equipe pode manter depois que a sessão termina. ## 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](https://specscore.md/acceptance-criteria-specification) | | 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](https://kiro.dev/license/) 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](https://github.com/kirodotdev/KiroCrew) separado. | [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 | | Preço | Um nível gratuito e planos pagos. Os números mudam — veja o [preço do Kiro](https://kiro.dev/pricing/), 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](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) 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](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) 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](https://specscore.md/articles/ears-requirements/). ## 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](https://github.com/specscore/specscore) 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. - [Documentação do Kiro — especificações](https://kiro.dev/docs/specs/) - [Documentação do Kiro — especificações de funcionalidade e EARS](https://kiro.dev/docs/specs/feature-specs/) - [Kiro — sobre](https://kiro.dev/about/) - [Kiro — licença](https://kiro.dev/license/) - [Kiro — preços](https://kiro.dev/pricing/) - [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)