Mejores herramientas de desarrollo basado en especificaciones en 2026
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 (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 (EARS) es una frase de requisito de la forma «WHEN ocurre algo, THE SYSTEM SHALL hacer algo». Una interfaz de línea de comandos (CLI) es un programa que ejecutas en una terminal. La integración continua (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, OpenSpec, Kiro, Tessl, el BMAD Method, Task Master AI, CodeSpeak, Datarim, Markdown simple y SpecScore. 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 instala el CLI de SpecScore y ejecuta specscore spec lint en las pull requests y en los push a main. La skill /score 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 | 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 en github/spec-kit | Un equipo que quiere un proceso compartido para el agente |
| 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 en Fission-AI/OpenSpec | Un equipo que quiere una carpeta de cambio ligera más una comprobación de estructura |
| 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 (AWS Customer Agreement). | Alguien que quiere que Kiro redacte los requisitos, el diseño y las tareas |
| 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 en 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 | 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 en 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 | 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 en eyaltoledano/claude-task-master | Un equipo que ya tiene un PRD y quiere dividirlo en tareas |
| 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 (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 | 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 en Arcanada-one/datarim | Un equipo que quiere comandos por etapas y un backlog en el repositorio |
| Markdown simple | 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 | Formato de especificación abierto más un CLI que lintea los archivos | Markdown + YAML en un árbol spec/ | dogfood.yml ejecuta specscore spec lint en las pull requests y en los push a main. /score es una calificación manual de IA, y ese workflow no lo ejecuta. | CC BY 4.0, formato en specscore/specscore. Apache-2.0, CLI en 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 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, 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 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, en el repositorio público 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.
OpenSpec
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, 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, 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, en 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.
Kiro
Kiro, 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, 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, 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. Los patrones de frase están en la sintaxis de requisitos EARS.
Tessl
La documentación de Tessl, 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 y figura en el registro de Tessl. 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, 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.
BMAD Method
El README del repositorio del 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, en 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.
Task Master AI
Task Master AI 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 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, en 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.
CodeSpeak
El sitio de CodeSpeak, 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, 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.
Datarim
El README de 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, en 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.
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.
SpecScore
SpecScore 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. El CLI vive en specscore/specscore-cli.
Cómo escribir los criterios para que un agente pueda comprobarlos está en cómo escribir criterios de aceptación.
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.
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.
Cómo ejecutar ese linter en la integración continua está en cómo lintear especificaciones en CI.
En el repositorio de este sitio web, 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 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, en specscore/specscore. La licencia del CLI es Apache-2.0, en 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/.
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. 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.