SpecScore vs Tessl
Desarrollo basado en especificaciones (SDD) significa que la especificación del comportamiento previsto se escribe antes que el código. Tessl (Tessl AI Ltd) es, a 30 de octubre de 2026, una plataforma de habilitación de agentes: un registro y un plano de control para las skills, reglas y plugins que cargan los agentes de programación. «Spec as source» es la afirmación más fuerte del ensayo de junio de 2025 de Tessl: la especificación es el artefacto que perdura, y el código se deriva de ella. SpecScore es un formato de archivo de código abierto para esa especificación, comprobado por una interfaz de línea de comandos (CLI). La integración continua (CI) — una comprobación automática de cada cambio propuesto — ejecuta esa comprobación en este repositorio.
Lo que tienen en común.
Lo que Tessl hace bien.
Dos superficies distintas de Tessl se confunden con facilidad. Las notas de abajo las mantienen separadas, a partir de páginas leídas el 30 de octubre de 2026.
Un argumento claro a favor del spec as source
El ensayo de Simon Maple del 27 de junio de 2025 dice que un documento de requisitos de producto (PRD) — prosa escrita para personas sobre qué construir — suele quedar desactualizado, mientras el código se convierte en la única fuente de verdad. La alternativa del ensayo es que la especificación es lo que cambias, y un gran modelo de lenguaje (LLM) genera código, pruebas y documentación a partir de ella. Es una postura real, no un eslogan.
Una plataforma para el contexto del agente
La documentación de Tessl describe un registro, una gobernanza que analiza y puntúa skills, evaluaciones y observabilidad entre agentes. La documentación dice que las skills son artefactos planos en tu repositorio, y que la plataforma funciona con Claude Code, Cursor, Copilot, Gemini y otros. Puntuar ahí significa puntuar una skill, no puntuar una especificación de producto.
Un tile oficial de desarrollo basado en especificaciones, con comprobaciones de shell
El tile tessl-labs/spec-driven-development, con licencia MIT en el repositorio público del tile, enseña a un agente a entrevistar, escribir archivos .spec.md, esperar la aprobación y después implementar. La página del registro enumera scripts/validate-specs.sh y scripts/check-spec-links.sh para el frontmatter, targets y los enlaces [@test]. La misma página dice que el tile es contexto de orientación: sin comandos especiales, sin marco de trabajo.
Comparación de funcionalidades.
«Spec as source» es el ensayo de Tessl. El tile es un paquete de skills encima de la plataforma actual. SpecScore es un formato con un linter versionado.
| Capacidad | Tessl | SpecScore |
|---|---|---|
| Rol principal | Plataforma de skills para agentes, más un tile de desarrollo basado en especificaciones y un ensayo de 2025 sobre spec as source | Formato de especificación abierto + CLI |
| Qué es la especificación | Ensayo: la fuente duradera de la que se genera el código. Tile: un .spec.md contra el que el agente implementa, y tú conservas el código. | Un contrato junto al código. El lint no regenera el código. |
| Forma de la especificación | Tile: frontmatter YAML, globs de targets y enlaces [@test] a archivos de prueba | Markdown + YAML, REQ: slug, Dado/Cuando/Entonces |
| Comprobar la especificación | Scripts de shell que acompañan al tile, para el frontmatter y los enlaces de ese tile | specscore spec lint sobre el formato SpecScore, en la CI de este repositorio. /score es una calificación de IA manual. |
| Licencia | El tile es MIT. La plataforma es un producto. La documentación no publica el código de la plataforma. | CC BY 4.0 el formato · Apache-2.0 el CLI |
| Precio | La página de inicio de Tessl, leída el 30 de octubre de 2026, describe un nivel gratuito (1.000 créditos al mes en un espacio de trabajo) y planes de empresa de pago. | Sin coste por el formato ni por el CLI |
Lo que SpecScore agrega.
Un formato publicado, no un script del tile
Los scripts de shell del tile comprueban archivos .spec.md que ese tile pidió escribir al agente. SpecScore comprueba un formato documentado en este sitio. dogfood.yml instala una versión fijada de specscore y ejecuta specscore spec lint. /score no es esa ejecución: es una skill manual que sale con código distinto de cero cuando los revisores de IA informan de problemas.
$ 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)
Conservas el código en ambos casos — el ensayo va más lejos
El ensayo de 2025 dice que el código debería regenerarse a partir de la especificación. El tile, en la página leída el 30 de octubre de 2026, hace que el agente implemente contra una especificación aprobada y no describe un compilador que sustituya tu árbol de código. SpecScore nunca te quita el código. La especificación es el contrato revisado; el código sigue siendo tuyo.
Identidad del requisito
El tile apunta un requisito a archivos con targets y [@test]. SpecScore nombra el requisito REQ: slug para que un plan, una tarea y un tráiler de commit puedan citarlo después de que los archivos se muevan.
Cuándo usar cada uno.
Elige Tessl cuando…
- Necesitas un registro, evaluaciones y gobernanza para skills compartidas entre muchos agentes y repositorios.
- Quieres el flujo del ensayo spec as source como tile de orientación: entrevistar, aprobar un .spec.md y después implementar.
- Ya pagas la plataforma Tessl, o la estás probando, y quieres su tile de especificación en ese registro.
Usa SpecScore cuando…
- El formato de la especificación en sí tiene que ser válido en CI, también en repositorios que no instalan Tessl.
- Quieres ids de requisitos y un linter que no llama a un modelo.
- Quieres el formato de código abierto bajo una licencia Creative Commons, aparte de una plataforma de skills.
Spec as source, y una especificación que se puede lintear.
El ensayo de Tessl acierta: un PRD desactualizado pierde frente al código. Una comprobación de formato es la manera de que la especificación siga siendo lo que confías. SpecScore no genera tu aplicación a partir de la especificación. Hace que la especificación falle en CI cuando la estructura, los enlaces o el estado son incorrectos.
Usa Tessl si quieres la plataforma y el tile. Usa SpecScore si el artefacto en git es lo que el pull request tiene que demostrar.
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.
Otras comparaciones.
El mismo formato, junto a otras herramientas de desarrollo guiado por especificaciones:
Todas juntas, en una página: mejores herramientas de desarrollo basado en especificaciones en 2026.
Comentarios
Esta comparación se basa en documentación y código fuente públicamente disponibles. ¿Algo incorrecto o desactualizado? abre un issue de corrección. ¿Quieres que comparemos SpecScore con otra herramienta? solicita una.