# Mejores herramientas de desarrollo basado en especificaciones en 2026

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

SpecScore es un formato de archivo abierto y lintable para especificaciones, escrito en Markdown y YAML (YAML Ain't Markup Language). [El desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/) (SDD) es una práctica en la que una especificación escrita es la fuente de verdad contra la que se construye y se comprueba el código. Las herramientas de desarrollo basado en especificaciones son los formatos, los workflows y los productos que se usan para escribir, guardar y, a veces, comprobar esas especificaciones. Un documento de requisitos de producto (PRD) es prosa que expone el problema y el alcance antes de que alguien lo divida en tareas. El [enfoque sencillo de la sintaxis de requisitos](https://kiro.dev/docs/specs/feature-specs/) (EARS) es una frase de requisito de la forma «WHEN ocurre algo, THE SYSTEM SHALL hacer algo». Una [interfaz de línea de comandos](https://specscore.md/es/cli/) (CLI) es un programa que ejecutas en una terminal. La [integración continua](https://specscore.md/es/validators/) (CI) es una comprobación automática de cada cambio propuesto.

Esta comparación de herramientas de desarrollo basado en especificaciones cubre [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/), el [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 simple y [SpecScore](https://specscore.md/es/). Las páginas y los repositorios públicos se leyeron el 30 de octubre de 2026. Los comandos, la disposición de los archivos y lo que un producto comprueba pueden cambiar; las fuentes al final nombran la página de la que sale cada afirmación.

La distinción que importa para un repositorio es si la especificación puede hacer fallar la CI por sí sola. En el repositorio del sitio web de SpecScore, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) instala el CLI de SpecScore y ejecuta `specscore spec lint` en las pull requests y en los push a main. La skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) de specstudio-skills es una calificación manual de IA de un artefacto. Tú la invocas. Ese workflow no.

## Herramientas de desarrollo basado en especificaciones, una junto a la otra.

Cada fila es un rol, no una puntuación. Sigue el nombre hasta la comparación de SpecScore, o el encabezado de más abajo para la fuente que hay detrás de la celda.

| Herramienta | Qué es | Cómo se escriben y se guardan las especificaciones | Validación automática de la especificación | Licencia | A quién le conviene |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/es/vs/spec-kit/) | Workflow de agente que produce artefactos Markdown | Directorio de funcionalidad bajo `specs/`: `spec.md`, `plan.md`, `tasks.md` | `/speckit.analyze` informa de huecos entre artefactos en la sesión del agente. Las extensiones de la comunidad pueden agregar controles. | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) en [github/spec-kit](https://github.com/github/spec-kit) | Un equipo que quiere un proceso compartido para el agente |
| [OpenSpec](https://specscore.md/es/vs/openspec/) | Carpetas de cambio y comandos de agente para acordar antes del código | Markdown simple bajo `openspec/changes/`: propuesta, especificaciones, diseño, tareas | `openspec validate` comprueba la estructura del cambio y de la especificación y puede salir con un código distinto de cero, incluso desde un script de CI. | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) en [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | Un equipo que quiere una carpeta de cambio ligera más una comprobación de estructura |
| [Kiro](https://specscore.md/es/vs/kiro/) | IDE agéntico, CLI y aplicación web de AWS que redacta especificaciones | `requirements.md` en EARS, más `design.md` y `tasks.md` | Analyze Requirements dentro de Kiro, antes del diseño. La página de especificaciones de funcionalidad describe esa comprobación dentro del producto. | El IDE y el CLI son AWS Content bajo la [licencia de Kiro](https://kiro.dev/license/) (AWS Customer Agreement). | Alguien que quiere que Kiro redacte los requisitos, el diseño y las tareas |
| [Tessl](https://specscore.md/es/vs/tessl/) | Plataforma de skills para agentes, más un tile de desarrollo basado en especificaciones | Skills como archivos en el repositorio. El tile escribe `.spec.md` bajo `specs/`. | El tile incluye `scripts/validate-specs.sh` y `scripts/check-spec-links.sh`. Sus GitHub Actions lintean el tile. | El tile es [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) en [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile). La plataforma es el producto de Tessl. | Un equipo que estandariza skills de agente, o que usa las reglas de especificación antes del código del tile |
| [BMAD Method](https://specscore.md/es/vs/bmad-method/) | Método ágil para el desarrollo impulsado por IA | Briefs, especificaciones y arquitectura que puedes llevar a otro workflow | El README describe los artefactos del método y los workflows del agente. No documenta un linter de formato para la CI. | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) en [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD), con un aviso de marca en ese archivo. | Un equipo que quiere un método ágil de agente dimensionado según el cambio |
| [Task Master AI](https://specscore.md/es/vs/task-master-ai/) | Lista de tareas para agentes de programación, analizada a partir de un PRD | Prosa de PRD, a menudo `.taskmaster/docs/prd.txt`, y luego tareas generadas | El README describe el análisis de un PRD para convertirlo en tareas. No describe un linter para el PRD. | [MIT con una Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) en [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | Un equipo que ya tiene un PRD y quiere dividirlo en tareas |
| [CodeSpeak](https://specscore.md/es/vs/codespeak/) | Kit de herramientas agéntico que convierte la intención del chat en requisitos asignados al código | Requisitos estructurados dentro del producto, asignados al código | El sitio dice que los requisitos se hacen cumplir en cada cambio, dentro del producto. | [Términos del servicio](https://codespeak.dev/terms-of-service) (vigentes el 3 de marzo de 2026): CodeSpeak Ltd conserva el Service, incluido su código fuente. El sitio del producto no publica un repositorio de código del kit de herramientas. | Un equipo que quiere la intención capturada de los chats y mantenida asignada al código |
| [Datarim](https://specscore.md/es/vs/datarim/) | Workflow iterativo para Claude Code, Codex CLI, Cursor y Antigravity | `/dr-prd` escribe un PRD. Las tareas activas están en `backlog.md`. | `/dr-compliance` y `/dr-dream lint` se ejecutan cuando invocas esos comandos. | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) en [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | Un equipo que quiere comandos por etapas y un backlog en el repositorio |
| [Markdown simple](https://specscore.md/es/vs/plain-markdown/) | Un archivo Markdown corriente que escribes y del que haces commit | Cualquier archivo `.md`, en el directorio que elijas | La revisión que hagas leyendo, hasta que agregues un comprobador | No hay producto ni archivo de licencia. Las condiciones del archivo son las del repositorio. | Una nota breve, un spike o una revisión que harás leyendo |
| [SpecScore](https://specscore.md/es/) | Formato de especificación abierto más un CLI que lintea los archivos | Markdown + YAML en un árbol `spec/` | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) ejecuta `specscore spec lint` en las pull requests y en los push a main. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) es una calificación manual de IA, y ese workflow no lo ejecuta. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), formato en [specscore/specscore](https://github.com/specscore/specscore). [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), CLI en [specscore/specscore-cli](https://github.com/specscore/specscore-cli). | Un equipo que necesita que el archivo de especificación haga fallar la CI cuando se rompe el formato |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) es un kit de herramientas abierto que entrega a un agente de programación un proceso: Specify, Plan, Tasks, Implement y Converge. La página de inicio de la documentación de Spec Kit, con fecha del 28 de septiembre de 2026, dice que cada fase produce un artefacto Markdown que lee la fase siguiente.

Esos archivos viven en un directorio de funcionalidad bajo `specs/`. La [guía de actualización](https://github.github.io/spec-kit/upgrade.html), leída el 30 de octubre de 2026, da rutas como `specs/001-my-feature/spec.md`, con `plan.md` y `tasks.md` junto a ella. La [referencia de SDD agéntico](https://github.github.io/spec-kit/reference/agentic-sdd.html) describe `/speckit.analyze` como un informe de incoherencias entre la especificación, el plan y las tareas, sin editar los archivos. `/speckit.clarify` y `/speckit.checklist` son otros comandos que ejecutas en el agente. La página de inicio de la documentación también nombra extensiones de la comunidad, incluida una llamada CI Guard, que agregan controles de cumplimiento.

La licencia es [MIT](https://github.com/github/spec-kit/blob/main/LICENSE), en el repositorio público [github/spec-kit](https://github.com/github/spec-kit). Spec Kit le conviene a un equipo que quiere ese proceso y se conforma con conservar la especificación como el Markdown que escribió el agente. Una comparación en paralelo con SpecScore está en [SpecScore vs Spec Kit](https://specscore.md/es/vs/spec-kit/).

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec), de Fission-AI, guarda cada cambio en su propia carpeta para que una persona y un agente puedan acordar antes de que se escriba el código. El [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md), leído el 30 de octubre de 2026, muestra `openspec/changes/add-dark-mode/` con `proposal.md`, un directorio `specs/`, `design.md` y `tasks.md`. Los requisitos son Markdown simple: una declaración SHALL y un escenario WHEN / THEN. El mismo README dice que admite 30+ asistentes de IA.

`openspec validate` comprueba cambios y especificaciones en busca de problemas estructurales. La [referencia del CLI](https://openspec.dev/docs/cli), leída el 30 de octubre de 2026, documenta una salida distinta de cero cuando la validación falla, y un fragmento de shell que puede ejecutar un job de CI. Esa comprobación es la estructura de cambios y especificaciones de OpenSpec.

La licencia es [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE), en [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec). OpenSpec le conviene a un equipo que quiere la carpeta de cambio y esa comprobación de estructura. Consulta [SpecScore vs OpenSpec](https://specscore.md/es/vs/openspec/).

## Kiro

[Kiro](https://kiro.dev/), de Amazon Web Services (AWS), es un entorno de desarrollo agéntico: un editor, un CLI y una aplicación web. La [página de especificaciones de funcionalidad](https://kiro.dev/docs/specs/feature-specs/), actualizada el 4 de agosto de 2026, recorre una funcionalidad por requisitos, diseño y tareas. `requirements.md` usa EARS. `design.md` y `tasks.md` están junto a él. Quick Spec puede ejecutar las tres sin una parada de aprobación entre ellas.

Analyze Requirements busca incoherencias, ambigüedad, restricciones en conflicto y huecos antes del diseño. Ese análisis se ejecuta dentro de Kiro. La página de especificaciones de funcionalidad describe la comprobación dentro del producto.

La [licencia de Kiro](https://kiro.dev/license/), leída el 30 de octubre de 2026, dice que el IDE y el CLI se licencian como AWS Content bajo el AWS Customer Agreement u otro acuerdo escrito, y la AWS Intellectual Property License. Kiro le conviene a alguien que quiere que ese producto redacte los tres archivos. Consulta [SpecScore vs Kiro](https://specscore.md/es/vs/kiro/). Los patrones de frase están en [la sintaxis de requisitos EARS](https://specscore.md/es/articles/ears-requirements/).

## Tessl

La [documentación de Tessl](https://docs.tessl.io/), leída el 30 de octubre de 2026, describe una plataforma abierta para gestionar skills de agente: un registro, gobernanza, evals y controles relacionados. Las skills, las reglas y los documentos son archivos en el repositorio.

Un artefacto aparte, el tile de desarrollo basado en especificaciones, se publica desde [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) y figura en el [registro de Tessl](https://tessl.io/registry/tessl-labs/spec-driven-development). El README del tile dice que el agente escribe archivos `.spec.md` en un directorio `specs/`, con frontmatter YAML, `targets` y enlaces `[@test]`. Documenta `scripts/validate-specs.sh` y `scripts/check-spec-links.sh`, y GitHub Actions que lintean el propio tile.

La licencia del tile es [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE), en ese repositorio. La documentación describe la plataforma del registro como el producto de Tessl y no señala un repositorio público para toda la plataforma. Tessl le conviene a un equipo que estandariza skills, o a un equipo que quiere la orientación de especificación antes del código del tile. Consulta [SpecScore vs Tessl](https://specscore.md/es/vs/tessl/).

## BMAD Method

El README del repositorio del [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), leído el 30 de octubre de 2026, describe un método ágil para el desarrollo impulsado por IA. Dice que puedes usar el método de principio a fin, o llevar sus briefs, especificaciones y arquitectura a un workflow que ya tienes. La línea estable que se nombra allí es v6.12. v7 se describe como una vista previa en la rama main. El proyecto escribe el nombre BMad; el repositorio es BMAD-METHOD.

El README pone en el centro esos artefactos de planificación y las skills de agente que los producen. No documenta un comando que lintee un esquema fijo de especificación en la CI.

La licencia es [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), en [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD). Ese archivo de licencia también lleva un aviso de marca para BMad. El método le conviene a un equipo que quiere el ciclo ágil y va a conservar la especificación en esos briefs y especificaciones. Consulta [SpecScore vs el BMAD Method](https://specscore.md/es/vs/bmad-method/).

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) es una lista de tareas para agentes de programación con IA. El README, leído el 30 de octubre de 2026, recomienda un PRD, a menudo en `.taskmaster/docs/prd.txt`, y `task-master parse-prd` para convertir esa prosa en tareas. [La documentación](https://tryhamster.com/docs/taskmaster) cubre la estructura de las tareas, las dependencias y los tags.

El README trata el PRD como entrada y la lista de tareas como aquello a partir de lo cual trabaja el agente. No describe un linter para la redacción o la estructura del PRD.

La licencia es [MIT con una Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE), en [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master). El README dice que puedes crear productos con Task Master, y que vender Task Master en sí u ofrecerlo como servicio alojado queda fuera de esa concesión. Le conviene a un equipo que quiere el PRD dividido en tareas. Consulta [SpecScore vs Task Master AI](https://specscore.md/es/vs/task-master-ai/).

## CodeSpeak

El sitio de [CodeSpeak](https://codespeak.dev/), leído el 30 de octubre de 2026, describe un kit de herramientas de ingeniería agéntica. Captura la intención de los chats del agente, convierte esa intención en requisitos estructurados asignados al código y dice que hace cumplir esos requisitos en cada cambio. El sitio también dice que una herramienta web recupera la intención de los chats hasta que se lance el producto completo.

Los [términos del servicio](https://codespeak.dev/terms-of-service), vigentes el 3 de marzo de 2026, afirman que CodeSpeak Ltd conserva el Service, incluido su software y su código fuente. El sitio del producto no publica un repositorio de código para ese kit de herramientas, así que esta página no nombra una licencia de software para él.

CodeSpeak le conviene a un equipo que quiere requisitos capturados de la conversación y mantenidos asignados al código dentro de ese producto. Consulta [SpecScore vs CodeSpeak](https://specscore.md/es/vs/codespeak/).

## Datarim

El README de [Datarim](https://github.com/Arcanada-one/datarim), que lleva una insignia de versión 4.9.0 y se leyó el 30 de octubre de 2026, describe un workflow iterativo para Claude Code, Codex CLI, Cursor y Google Antigravity. `/dr-prd` genera un PRD. Las tareas activas están en `backlog.md`, con el historial completado en `backlog-archive.md`.

`/dr-compliance` comprueba una implementación contra el PRD cuando ejecutas ese comando. `/dr-dream lint` revisa el estado de una base de conocimiento en busca de contradicciones, huérfanos, enlaces rotos, contenido obsoleto y duplicados. Son comandos del workflow.

La licencia es [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE), en [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim). Datarim le conviene a un equipo que quiere esos comandos por etapas en los agentes que nombra el README. Consulta [SpecScore vs Datarim](https://specscore.md/es/vs/datarim/).

## Markdown simple

Markdown simple es la especificación como un archivo `.md` corriente: un encabezado, algunas viñetas, donde hagas commit. No hay esquema. La revisión es alguien que lee el archivo, hasta que agregues un comprobador propio.

No hay producto ni archivo de licencia que enlazar. Las condiciones del archivo son la licencia que apliques al repositorio. Markdown simple conviene para una nota breve, un spike o un equipo que va a revisar la prosa leyéndola. Consulta [SpecScore vs Markdown simple](https://specscore.md/es/vs/plain-markdown/).

## SpecScore

[SpecScore](https://specscore.md/es/) es un formato para la especificación — funcionalidades, requisitos y criterios de aceptación como Markdown con YAML — y un CLI que comprueba los archivos. El formato vive en [specscore/specscore](https://github.com/specscore/specscore). El CLI vive en [specscore/specscore-cli](https://github.com/specscore/specscore-cli).

Cómo escribir los criterios para que un agente pueda comprobarlos está en [cómo escribir criterios de aceptación](https://specscore.md/es/articles/acceptance-criteria/).

Una plantilla de especificación de funcionalidad en Markdown — requisitos, criterios de aceptación, un plan y tareas — está en [plantilla de PRD en Markdown](https://specscore.md/es/articles/feature-spec-template/).

El desarrollo basado en especificaciones con Claude Code y Cursor — el archivo de la funcionalidad, el archivo de instrucciones del agente y `specscore spec lint` en el bucle están en [desarrollo basado en especificaciones con Claude Code y Cursor](https://specscore.md/es/articles/claude-code-specs/).

Cómo ejecutar ese linter en la integración continua está en [cómo lintear especificaciones en CI](https://specscore.md/es/articles/lint-specs-in-ci/).

En el repositorio de este sitio web, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) instala ese CLI y ejecuta `specscore spec lint` en las pull requests y en los push a main. Una especificación que rompe el formato hace fallar ese job. La skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) es una calificación manual de IA: vuelve a ejecutar los revisores configurados cuando lo pides, y el workflow dogfood no la llama.

La licencia del formato es [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), en [specscore/specscore](https://github.com/specscore/specscore). La licencia del CLI es [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), en [specscore/specscore-cli](https://github.com/specscore/specscore-cli). SpecScore le conviene a un equipo que necesita que la especificación haga fallar la CI cuando un encabezado, un enlace o un estado está mal, sea cual sea el agente que escribió el archivo. `openspec validate` es la comprobación estructural más cercana entre las otras herramientas de aquí; comprueba la forma de cambio propia de OpenSpec. Las comparaciones individuales empiezan en [/vs/](https://specscore.md/es/vs/).

## Cómo elegir.

Elige GitHub Spec Kit, OpenSpec, el BMAD Method o Datarim cuando quieres un proceso guiado y Markdown que puedes revisar en una pull request. Elige Kiro cuando quieres que ese producto redacte requisitos EARS. Elige Task Master AI cuando el PRD deba convertirse en una lista de tareas. Elige CodeSpeak cuando la intención deba capturarse de los chats dentro de ese producto. Elige Tessl cuando el problema son las skills de agente, con el tile de especificación como una orientación opcional.

Elige SpecScore cuando el propio archivo de especificación tiene que hacer fallar la CI. La comprobación en este repositorio es `specscore spec lint` en [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Un workflow de la lista de arriba puede seguir siendo la forma en que se escribe la especificación.

## Fuentes.

Leído el 30 de octubre de 2026, salvo donde una página imprime su propia fecha de actualización. Se omiten los precios y los nombres de los planes porque cambian.

- [Documentación de GitHub Spec Kit (página con fecha del 28 de septiembre de 2026)](https://github.github.io/spec-kit/)
- [Spec Kit — Referencia de SDD agéntico](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — Guía de actualización (rutas specs/)](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — licencia MIT](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [Referencia del CLI de OpenSpec — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — licencia MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Documentación de Kiro — especificaciones de funcionalidad y EARS (actualizada el 4 de agosto de 2026)](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — Licencia](https://kiro.dev/license/)
- [Documentación de Tessl — ¿Qué es Tessl?](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tile de desarrollo basado en especificaciones de Tessl — licencia 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 — licencia 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 con Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — Términos del servicio (vigentes el 3 de marzo de 2026)](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README (insignia 4.9.0)](https://github.com/Arcanada-one/datarim)
- [Datarim — licencia 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 (calificación 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)