# SpecScore vs Kiro Canonical: https://specscore.md/es/vs/kiro/ [Desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/) (SDD) significa escribir qué debe hacer el software antes de que un agente de IA escriba el código. [Kiro](https://kiro.dev/), de Amazon Web Services (AWS), es un entorno de desarrollo agéntico — un editor, una [interfaz de línea de comandos](https://specscore.md/es/cli/) (CLI) y una aplicación web — que convierte un prompt en Kiro specs: requisitos, un diseño y tareas. Esos requisitos usan [EARS](https://kiro.dev/docs/specs/feature-specs/) (Easy Approach to Requirements Syntax), frases con la forma «WHEN ocurre algo, THE SYSTEM SHALL hacer algo». [SpecScore](https://specscore.md/es/) es un formato [de código abierto](https://github.com/specscore/specscore) para la especificación en sí, más un CLI que comprueba los archivos. La [integración continua](https://specscore.md/es/validators/) (CI) — una comprobación automática de cada cambio propuesto — puede rechazar una especificación SpecScore que rompa el formato. ## Lo que tienen en común. - Ambos tratan una especificación escrita como aquello a partir de lo cual debe construir un agente, no como la transcripción de un chat. - Ambos guardan esa especificación como Markdown en el proyecto, de modo que se puede revisar como el código. - Ambos dividen el trabajo en requisitos, un diseño y tareas. Kiro genera esos tres archivos. SpecScore es un formato que un equipo puede conservar cuando termina la sesión. ## Lo que Kiro hace bien. La documentación propia de Kiro, leída el 30 de octubre de 2026, describe el producto. La página de especificaciones de funcionalidad estaba marcada como actualizada el 4 de agosto de 2026. ### Requisitos con una forma de frase fija Las Kiro specs ponen el comportamiento en `requirements.md` con un patrón EARS: WHEN se cumple una condición, THE SYSTEM SHALL hacer una cosa. La documentación pone el ejemplo de un formulario con datos no válidos y el sistema mostrando un error de validación junto al campo. Esa forma es más fácil de probar que un párrafo vago. ### Un camino completo del prompt a las tareas Una especificación de funcionalidad pasa por requisitos, diseño (`design.md`) y tareas (`tasks.md`). Puedes empezar por los requisitos o por un diseño. Quick Spec ejecuta las tres sin una parada de aprobación entre ellas. Las Bugfix specs son un camino aparte. La documentación también describe ejecutar tareas independientes en paralelo, por oleadas, a partir del grafo de dependencias de `tasks.md`. ### Comprobaciones dentro del producto Analyze Requirements, disponible en el IDE y en el CLI, busca incoherencias, ambigüedad, restricciones en conflicto y huecos antes del diseño. Correctness — pruebas basadas en propiedades extraídas de esas líneas EARS — figura solo para el IDE, no para el CLI, la web ni el móvil, en la tabla de capacidades de las specs. ## Comparación de funcionalidades. Kiro es un producto que redacta especificaciones. SpecScore es el formato que un repositorio puede comprobar. La tabla compara esos roles. | Capacidad | Kiro | SpecScore | | --- | --- | --- | | Rol principal | IDE agéntico, CLI y aplicación web que redacta especificaciones e implementa tareas | **Formato de especificación abierto + CLI** | | Archivos de la especificación | `requirements.md` (o `bugfix.md`), `design.md`, `tasks.md` | **Un árbol spec/** de Markdown + YAML | | Sintaxis de requisitos | Patrón EARS: WHEN … THE SYSTEM SHALL … | **Identificadores de requisitos** (`REQ: slug`) y criterios de aceptación [Dado/Cuando/Entonces](https://specscore.md/acceptance-criteria-specification) | | Comprobar la especificación | Analyze Requirements en el IDE y el CLI. Pruebas basadas en propiedades en el IDE. No se describe como un linter de formato para tu propia CI. | **specscore spec lint** en CI. `/score` es una calificación de IA aparte y manual. | | Dónde se ejecuta | Kiro IDE, Kiro CLI, Kiro web. Algunas comprobaciones son solo del IDE. | **Cualquier repositorio** — un binario Go, sin cuenta de Kiro | | Licencia | La [licencia de Kiro](https://kiro.dev/license/) dice que el IDE y el CLI son AWS Content bajo el AWS Customer Agreement. Kiro Crew es un [repositorio público](https://github.com/kirodotdev/KiroCrew) aparte. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) el formato · [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) el CLI | | Precio | Un nivel gratuito y planes de pago. Las cifras cambian — consulta [los precios de Kiro](https://kiro.dev/pricing/), leídos el 30 de octubre de 2026. | **Sin coste** por el formato ni por el CLI | ## Lo que SpecScore agrega. ### El formato hace fallar la CI por sí solo El análisis de Kiro se ejecuta dentro de Kiro. La comprobación de SpecScore es un comando. El [flujo de trabajo dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) de este repositorio ejecuta `specscore spec lint` en cada pull request y en main. Una especificación rota hace fallar la ejecución como lo haría una prueba rota. La skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) califica la redacción con revisores de IA; esa pasada es manual, y el flujo de arriba no la ejecuta. ``` $ 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) ``` ### La especificación no está atada a un solo IDE Las Kiro specs son Markdown, así que puedes leerlas sin el producto. El flujo que las crea y las ejecuta es el de Kiro. Un árbol SpecScore son los mismos archivos para Claude Code, Cursor, Copilot o ningún agente — el CLI no llama a un modelo para lintear. ### Los requisitos conservan un id La documentación de Kiro describe la trazabilidad como seguir un requisito a lo largo de la implementación. No describe un id estable que sobreviva a una reescritura. SpecScore se dirige a un requisito como `REQ: slug` y a un criterio de aceptación por su propio id. ### EARS y Dado/Cuando/Entonces responden a preguntas distintas EARS, tal como lo documenta Kiro, es una frase de comportamiento del sistema. Los criterios de aceptación de SpecScore son escenarios Dado/Cuando/Entonces ligados a un id de requisito. Puedes escribir una línea EARS en la prosa y conservar el escenario en el archivo SpecScore que comprueba el linter. Los patrones de frase están en [la sintaxis de requisitos EARS](https://specscore.md/articles/ears-requirements/). ## Cuándo usar cada uno. ### Elige Kiro cuando… - Quieres un IDE agéntico de AWS que redacte requisitos, diseño y tareas a partir de un prompt y después implemente las tareas. - Quieres frases EARS y, en el IDE, pruebas basadas en propiedades generadas a partir de ellas. - Tu equipo ya se está estandarizando en el editor, el CLI o la aplicación web de Kiro. ### Usa SpecScore cuando… - La especificación tiene que seguir siendo válida en CI cuando termina la sesión del agente, en un repositorio que no exige Kiro. - Necesitas ids de requisitos, estado del ciclo de vida y un resultado de lint determinista. - Quieres el formato [de código abierto](https://github.com/specscore/specscore) y que el comprobador sea un solo binario. ## Kiro puede redactar. SpecScore puede hacer de compuerta. Nada de esto sustituye al editor de Kiro. Si Kiro es donde el equipo escribe el prompt, deja que redacte. Si la especificación tiene que sobrevivir como archivo revisado, escribe ese contrato en SpecScore y deja que `specscore spec lint` haga fallar el pull request cuando se rompa la estructura. Los dos archivos pueden convivir en el mismo repositorio. Elige Kiro para la sesión. Elige SpecScore para el artefacto que una ejecución de CI puede rechazar. ## Fuentes. Las páginas públicas de abajo se leyeron el 30 de octubre de 2026. Los precios, los nombres de los planes y las líneas de versión cambian. - [Documentación de Kiro — Specs](https://kiro.dev/docs/specs/) - [Documentación de Kiro — especificaciones de funcionalidad y EARS](https://kiro.dev/docs/specs/feature-specs/) - [Kiro — Acerca de](https://kiro.dev/about/) - [Kiro — Licencia](https://kiro.dev/license/) - [Kiro — Precios](https://kiro.dev/pricing/) - [specscore/specscore — flujo 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)