# Melhores ferramentas de desenvolvimento guiado por especificação em 2026

Canonical: https://specscore.md/pt-br/spec-driven-development/tools/

SpecScore é um formato de arquivo aberto e lintável para especificações, escrito em Markdown e YAML (YAML Ain't Markup Language). [Desenvolvimento guiado por especificação](https://specscore.md/pt-br/spec-driven-development/) (SDD) é uma prática em que uma especificação escrita é a fonte de verdade com base na qual o código é construído e contra a qual ele é conferido. Ferramentas de desenvolvimento guiado por especificação são os formatos, fluxos de trabalho e produtos usados para escrever, guardar e às vezes conferir essas especificações. Um documento de requisitos do produto (PRD) é prosa que declara o problema e o escopo antes que alguém o divida em tarefas. [Abordagem Fácil à Sintaxe de Requisitos](https://kiro.dev/docs/specs/feature-specs/) (EARS) é uma frase de requisito na forma “WHEN algo acontece, THE SYSTEM SHALL fazer algo”. Uma [interface de linha de comando](https://specscore.md/pt-br/cli/) (CLI) é um programa que você executa em um terminal. [Integração contínua](https://specscore.md/pt-br/validators/) (CI) é uma verificação automática de cada mudança proposta.

Esta comparação de ferramentas de desenvolvimento guiado por especificação abrange [GitHub Spec Kit](https://github.com/github/spec-kit), [OpenSpec](https://github.com/Fission-AI/OpenSpec), [Kiro](https://kiro.dev/), [Tessl](https://docs.tessl.io/), o [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), [Task Master AI](https://github.com/eyaltoledano/claude-task-master), [CodeSpeak](https://codespeak.dev/), [Datarim](https://github.com/Arcanada-one/datarim), Markdown simples e [SpecScore](https://specscore.md/pt-br/). Páginas públicas e repositórios foram lidos em 30 de outubro de 2026. Comandos, a disposição dos arquivos e o que um produto confere podem mudar; as fontes no final nomeiam a página de onde vem cada afirmação.

A divisão que importa para um repositório é se a especificação consegue falhar na CI por conta própria. No repositório do site do SpecScore, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) instala o CLI do SpecScore e executa `specscore spec lint` em pull requests e em pushes para a main. O skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) em specstudio-skills é uma nota manual de IA de um artefato. Você o invoca. Esse fluxo de trabalho não.

## Ferramentas de desenvolvimento guiado por especificação, lado a lado.

Cada linha é um papel, não uma pontuação. Siga o nome até a comparação do SpecScore, ou o título abaixo até a fonte da célula.

| Ferramenta | O que é | Como as especificações são escritas e guardadas | Validação automática da especificação | Licença | Para quem serve |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/pt-br/vs/spec-kit/) | Fluxo de trabalho de agente que produz artefatos Markdown | Diretório da funcionalidade sob `specs/`: `spec.md`, `plan.md`, `tasks.md` | `/speckit.analyze` relata lacunas entre artefatos na sessão do agente. Extensões da comunidade podem acrescentar portões. | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) em [github/spec-kit](https://github.com/github/spec-kit) | Uma equipe que quer um processo compartilhado para o agente |
| [OpenSpec](https://specscore.md/pt-br/vs/openspec/) | Pastas de mudança e comandos de agente para combinar antes do código | Markdown simples sob `openspec/changes/`: proposal, specs, design, tasks | `openspec validate` confere a estrutura da mudança e da spec e pode sair com código diferente de zero, inclusive a partir de um script de CI. | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) em [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | Uma equipe que quer uma pasta de mudança leve mais uma conferência de estrutura |
| [Kiro](https://specscore.md/pt-br/vs/kiro/) | IDE agêntica, CLI e aplicativo web da AWS que redige specs | `requirements.md` em EARS, mais `design.md` e `tasks.md` | Analyze Requirements dentro do Kiro, antes do design. A página de spec de funcionalidade descreve essa conferência no produto. | A IDE e a CLI são conteúdo da AWS (AWS Content) sob a [licença do Kiro](https://kiro.dev/license/) (AWS Customer Agreement). | Alguém que quer que o Kiro redija os requisitos, o design e as tarefas |
| [Tessl](https://specscore.md/pt-br/vs/tessl/) | Plataforma de skills para agentes, mais um tile de desenvolvimento guiado por especificação | Skills como arquivos no repositório. O tile escreve `.spec.md` sob `specs/`. | O tile traz `scripts/validate-specs.sh` e `scripts/check-spec-links.sh`. Os GitHub Actions dele fazem lint do próprio tile. | O tile é [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) em [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile). A plataforma é o produto da Tessl. | Uma equipe que padroniza skills de agente, ou que usa as regras de spec antes do código do tile |
| [BMAD Method](https://specscore.md/pt-br/vs/bmad-method/) | Método ágil para desenvolvimento conduzido por IA | Briefs, especificações e arquitetura que você pode levar para outro fluxo de trabalho | O README descreve os artefatos do método e os fluxos de trabalho do agente. Não documenta um linter de formato para a CI. | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) em [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD), com um aviso de marca nesse arquivo. | Uma equipe que quer um método ágil de agente no tamanho da mudança |
| [Task Master AI](https://specscore.md/pt-br/vs/task-master-ai/) | Lista de tarefas para agentes de código, extraída de um PRD | Prosa de PRD, muitas vezes `.taskmaster/docs/prd.txt`, e então as tarefas geradas | O README descreve a análise de um PRD em tarefas. Não descreve um linter para o PRD. | [MIT com uma Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) em [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | Uma equipe que já tem um PRD e quer dividi-lo em tarefas |
| [CodeSpeak](https://specscore.md/pt-br/vs/codespeak/) | Kit agêntico que transforma a intenção do chat em requisitos mapeados ao código | Requisitos estruturados dentro do produto, mapeados ao código | O site diz que os requisitos são aplicados em cada mudança, dentro do produto. | [Termos de serviço](https://codespeak.dev/terms-of-service) (vigentes em 3 de março de 2026): a CodeSpeak Ltd retém o Serviço, inclusive o código-fonte dele. O site do produto não publica um repositório de código do kit. | Uma equipe que quer a intenção capturada dos chats e mantida mapeada ao código |
| [Datarim](https://specscore.md/pt-br/vs/datarim/) | Fluxo de trabalho iterativo para Claude Code, Codex CLI, Cursor e Antigravity | `/dr-prd` escreve um PRD. As tarefas ativas ficam em `backlog.md`. | `/dr-compliance` e `/dr-dream lint` rodam quando você invoca esses comandos. | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) em [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | Uma equipe que quer comandos em etapas e um backlog no repositório |
| [Plain Markdown](https://specscore.md/pt-br/vs/plain-markdown/) | Um arquivo Markdown comum que você escreve e faz commit | Qualquer arquivo `.md`, no diretório que você escolher | A revisão que você fizer lendo, até acrescentar um verificador | Não há produto nem arquivo de licença. Os termos do arquivo são os do repositório. | Uma nota curta, um spike ou uma revisão que você fará lendo |
| [SpecScore](https://specscore.md/pt-br/) | Formato aberto de especificação mais um CLI que faz lint dos arquivos | Markdown + YAML em uma árvore `spec/` | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) executa `specscore spec lint` em pull requests e pushes para a main. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) é uma nota manual de IA, e esse fluxo de trabalho não o executa. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) para o formato em [specscore/specscore](https://github.com/specscore/specscore). [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) para o CLI em [specscore/specscore-cli](https://github.com/specscore/specscore-cli). | Uma equipe que precisa que o arquivo da spec falhe na CI quando o formato quebra |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) é um kit aberto que entrega a um agente de código um processo: Specify, Plan, Tasks, Implement e Converge. A página inicial da documentação do Spec Kit, datada de 28 de setembro de 2026, diz que cada fase produz um artefato Markdown que a fase seguinte lê.

Esses arquivos ficam em um diretório de funcionalidade sob `specs/`. O [guia de atualização](https://github.github.io/spec-kit/upgrade.html), lido em 30 de outubro de 2026, dá caminhos como `specs/001-my-feature/spec.md`, com `plan.md` e `tasks.md` ao lado. A [referência de SDD agêntico](https://github.github.io/spec-kit/reference/agentic-sdd.html) descreve `/speckit.analyze` como um relatório de inconsistências entre a spec, o plano e as tarefas, sem editar os arquivos. `/speckit.clarify` e `/speckit.checklist` são outros comandos que você executa no agente. A página inicial da documentação também nomeia extensões da comunidade, inclusive uma chamada CI Guard, que acrescentam portões de conformidade.

A licença é [MIT](https://github.com/github/spec-kit/blob/main/LICENSE), no repositório público [github/spec-kit](https://github.com/github/spec-kit). O Spec Kit serve a uma equipe que quer esse processo e aceita manter a especificação como o Markdown que o agente escreveu. O lado a lado com o SpecScore está em [SpecScore vs Spec Kit](https://specscore.md/pt-br/vs/spec-kit/).

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec), da Fission-AI, guarda cada mudança na própria pasta para que uma pessoa e um agente possam combinar antes de o código ser escrito. O [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md), lido em 30 de outubro de 2026, mostra `openspec/changes/add-dark-mode/` com `proposal.md`, um diretório `specs/`, `design.md` e `tasks.md`. Os requisitos são Markdown simples: uma declaração SHALL e um cenário WHEN / THEN. O mesmo README diz que oferece suporte a 30+ assistentes de IA.

`openspec validate` confere mudanças e specs em busca de problemas estruturais. A [referência da CLI](https://openspec.dev/docs/cli), lida em 30 de outubro de 2026, documenta uma saída diferente de zero quando a validação falha, e um trecho de shell que um job de CI pode executar. Essa conferência é a estrutura de mudança e de spec do OpenSpec.

A licença é [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE), em [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec). O OpenSpec serve a uma equipe que quer a pasta de mudança e essa conferência de estrutura. Veja [SpecScore vs OpenSpec](https://specscore.md/pt-br/vs/openspec/).

## Kiro

[Kiro](https://kiro.dev/), da Amazon Web Services (AWS), é um ambiente de desenvolvimento agêntico: um editor, uma CLI e um aplicativo web. A [página de specs de funcionalidade](https://kiro.dev/docs/specs/feature-specs/), atualizada em 4 de agosto de 2026, conduz uma funcionalidade por requisitos, design e tarefas. `requirements.md` usa EARS. `design.md` e `tasks.md` ficam ao lado. O Quick Spec pode executar os três sem uma parada de aprovação entre eles.

O Analyze Requirements procura inconsistências, ambiguidade, restrições conflitantes e lacunas antes do design. Essa análise roda dentro do Kiro. A página de spec de funcionalidade descreve a conferência no produto.

A [licença do Kiro](https://kiro.dev/license/), lida em 30 de outubro de 2026, diz que a IDE e a CLI são licenciadas como conteúdo da AWS (AWS Content) sob o contrato de cliente da AWS (AWS Customer Agreement) ou outro acordo escrito, e a AWS Intellectual Property License. O Kiro serve a alguém que quer que esse produto redija os três arquivos. Veja [SpecScore vs Kiro](https://specscore.md/pt-br/vs/kiro/). Os padrões de frase estão em [a sintaxe de requisitos EARS](https://specscore.md/pt-br/articles/ears-requirements/).

## Tessl

[A documentação da Tessl](https://docs.tessl.io/), lida em 30 de outubro de 2026, descreve uma plataforma aberta para gerenciar skills de agente: um registro, governança, evals e controles relacionados. Skills, regras e docs são arquivos no repositório.

Um artefato separado, o tile de desenvolvimento guiado por especificação, é publicado a partir de [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) e listado no [registro da Tessl](https://tessl.io/registry/tessl-labs/spec-driven-development). O README do tile diz que o agente escreve arquivos `.spec.md` em um diretório `specs/`, com frontmatter YAML, `targets` e links `[@test]`. Ele documenta `scripts/validate-specs.sh` e `scripts/check-spec-links.sh`, e GitHub Actions que fazem lint do próprio tile.

A licença do tile é [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE), nesse repositório. A documentação descreve a plataforma de registro como produto da Tessl e não aponta um repositório público da plataforma inteira. A Tessl serve a uma equipe que padroniza skills, ou a uma equipe que quer a orientação de spec antes do código do tile. Veja [SpecScore vs Tessl](https://specscore.md/pt-br/vs/tessl/).

## BMAD Method

O README do repositório [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), lido em 30 de outubro de 2026, descreve um método ágil para desenvolvimento conduzido por IA. Diz que você pode usar o método de ponta a ponta, ou levar os briefs, as especificações e a arquitetura para um fluxo de trabalho que você já tem. A linha estável nomeada ali é a v6.12. A v7 é descrita como uma prévia no branch main. O projeto escreve o nome como BMad; o repositório é BMAD-METHOD.

O README centra esses artefatos de planejamento e as skills de agente que os produzem. Não documenta um comando que faça lint de um esquema fixo de spec na CI.

A licença é [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), em [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD). Esse arquivo de licença também traz um aviso de marca para BMad. O método serve a uma equipe que quer o ciclo ágil e vai manter a especificação nesses briefs e specs. Veja [SpecScore vs the BMAD Method](https://specscore.md/pt-br/vs/bmad-method/).

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) é uma lista de tarefas para agentes de código de IA. O README, lido em 30 de outubro de 2026, recomenda um PRD, muitas vezes em `.taskmaster/docs/prd.txt`, e `task-master parse-prd` para transformar essa prosa em tarefas. [A documentação](https://tryhamster.com/docs/taskmaster) cobre a estrutura das tarefas, as dependências e as tags.

O README trata o PRD como entrada e a lista de tarefas como aquilo a partir do qual o agente trabalha. Não descreve um linter para a redação ou a estrutura do PRD.

A licença é [MIT com uma Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE), em [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master). O README diz que você pode construir produtos com o Task Master, e que vender o próprio Task Master ou oferecê-lo como um serviço hospedado está fora dessa concessão. Serve a uma equipe que quer o PRD dividido em tarefas. Veja [SpecScore vs Task Master AI](https://specscore.md/pt-br/vs/task-master-ai/).

## CodeSpeak

O site do [CodeSpeak](https://codespeak.dev/), lido em 30 de outubro de 2026, descreve um kit de engenharia agêntico. Ele captura a intenção dos chats do agente, transforma essa intenção em requisitos estruturados mapeados ao código e diz que aplica esses requisitos em cada mudança. O site também diz que uma ferramenta web recupera a intenção dos chats até o produto completo ser lançado.

Os [termos de serviço](https://codespeak.dev/terms-of-service), vigentes em 3 de março de 2026, afirmam que a CodeSpeak Ltd retém o Serviço, inclusive o software e o código-fonte dele. O site do produto não publica um repositório de código desse kit, então esta página não nomeia uma licença de software para ele.

O CodeSpeak serve a uma equipe que quer requisitos capturados da conversa e mantidos mapeados ao código dentro desse produto. Veja [SpecScore vs CodeSpeak](https://specscore.md/pt-br/vs/codespeak/).

## Datarim

O README do [Datarim](https://github.com/Arcanada-one/datarim), com um selo de versão 4.9.0 e lido em 30 de outubro de 2026, descreve um fluxo de trabalho iterativo para Claude Code, Codex CLI, Cursor e Google Antigravity. `/dr-prd` gera um PRD. As tarefas ativas ficam em `backlog.md`, com o histórico concluído em `backlog-archive.md`.

`/dr-compliance` confere uma implementação contra o PRD quando você executa esse comando. `/dr-dream lint` faz uma verificação de saúde de uma base de conhecimento em busca de contradições, órfãos, links quebrados, conteúdo desatualizado e duplicatas. Esses são comandos no fluxo de trabalho.

A licença é [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE), em [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim). O Datarim serve a uma equipe que quer esses comandos em etapas nos agentes que o README nomeia. Veja [SpecScore vs Datarim](https://specscore.md/pt-br/vs/datarim/).

## Plain Markdown

Markdown simples é a especificação como um arquivo `.md` comum: um título, alguns tópicos, onde você fizer o commit. Não há esquema. A revisão é alguém lendo o arquivo, até você acrescentar um verificador próprio.

Não há produto nem arquivo de licença para vincular. Os termos do arquivo são a licença que você aplicar ao repositório. O Markdown simples serve a uma nota curta, um spike ou uma equipe que vai revisar a prosa lendo-a. Veja [SpecScore vs plain Markdown](https://specscore.md/pt-br/vs/plain-markdown/).

## SpecScore

[SpecScore](https://specscore.md/pt-br/) é um formato para a especificação — funcionalidades, requisitos e critérios de aceitação como Markdown com YAML — e um CLI que confere os arquivos. O formato fica em [specscore/specscore](https://github.com/specscore/specscore). O CLI fica em [specscore/specscore-cli](https://github.com/specscore/specscore-cli).

Como escrever os critérios para que um agente possa verificá-los está em [como escrever critérios de aceitação](https://specscore.md/pt-br/articles/acceptance-criteria/).

Um modelo de especificação de funcionalidade em Markdown — requisitos, critérios de aceitação, um plano e tarefas — está em [modelo de PRD em Markdown](https://specscore.md/pt-br/articles/feature-spec-template/).

O desenvolvimento guiado por especificação com Claude Code e Cursor — o arquivo da funcionalidade, o arquivo de instruções do agente e `specscore spec lint` no laço estão em [desenvolvimento guiado por especificação com Claude Code e Cursor](https://specscore.md/pt-br/articles/claude-code-specs/).

Como executar esse linter na integração contínua está em [como lintar especificações na CI](https://specscore.md/pt-br/articles/lint-specs-in-ci/).

No repositório deste site, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) instala esse CLI e executa `specscore spec lint` em pull requests e em pushes para a main. Uma spec que quebra o formato faz esse job falhar. O skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) é uma nota manual de IA: ele executa de novo os revisores configurados quando você pede, e o fluxo de trabalho dogfood não o chama.

A licença do formato é [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), em [specscore/specscore](https://github.com/specscore/specscore). A licença do CLI é [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), em [specscore/specscore-cli](https://github.com/specscore/specscore-cli). O SpecScore serve a uma equipe que precisa que a especificação falhe na CI quando um título, um link ou um status está errado, qualquer que seja o agente que escreveu o arquivo. `openspec validate` é a conferência estrutural mais próxima entre as outras ferramentas desta página; ele confere a própria forma de mudança do OpenSpec. As comparações individuais começam em [/vs/](https://specscore.md/pt-br/vs/).

## Como escolher.

Escolha GitHub Spec Kit, OpenSpec, o BMAD Method ou o Datarim quando você quer um processo guiado e Markdown que dá para revisar em um pull request. Escolha o Kiro quando você quer que esse produto redija requisitos EARS. Escolha o Task Master AI quando o PRD deve virar uma lista de tarefas. Escolha o CodeSpeak quando a intenção deve ser capturada dos chats dentro desse produto. Escolha a Tessl quando o problema são skills de agente, com o tile de spec como uma orientação opcional.

Escolha o SpecScore quando o próprio arquivo da especificação tem de falhar na CI. A conferência neste repositório é `specscore spec lint` em [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Um fluxo de trabalho da lista acima ainda pode ser o modo como a spec é escrita.

## Fontes.

Lido em 30 de outubro de 2026, exceto onde a página imprime a própria data de atualização. Preços e nomes de planos ficam de fora porque mudam.

- [Documentação do GitHub Spec Kit (página datada de 28 de setembro de 2026)](https://github.github.io/spec-kit/)
- [Spec Kit — referência de SDD agêntico](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — guia de atualização (caminhos specs/)](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — licença MIT](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [Referência da CLI do OpenSpec — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — licença MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Documentação do Kiro — specs de funcionalidade e EARS (atualizado em 4 de agosto de 2026)](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — licença](https://kiro.dev/license/)
- [Documentação da Tessl — o que é a Tessl?](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tile de desenvolvimento guiado por especificação da Tessl — licença MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)
- [bmad-code-org/BMAD-METHOD — README](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD — licença MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [eyaltoledano/claude-task-master — README](https://github.com/eyaltoledano/claude-task-master)
- [Task Master — MIT com Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — termos de serviço (vigentes em 3 de março de 2026)](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README (selo 4.9.0)](https://github.com/Arcanada-one/datarim)
- [Datarim — licença MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml (specscore spec lint)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — skill /score (nota manual de IA)](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)