SpecScore vs Spec Kit

Operan en capas distintas. Spec Kit es un flujo de trabajo — un proceso guiado que lleva a un agente de la idea a la implementación. SpecScore es el formato en el que se escriben las especificaciones, más un CLI que las lintea, consulta y traza. Spec Kit puede producir archivos de SpecScore.

Lo que tienen en común.

La misma estrella polar — especificaciones antes que código, con agentes de IA como lectores de primera clase.
Las especificaciones viven en tu repositorio como Markdown — con control de versiones, revisables en PRs.
Ambos son open source bajo la licencia MIT.
Ambos apuntan a Claude Code, Cursor, Copilot y otros agentes de codificación de IA.

Lo que Spec Kit hace bien.

Spec Kites un flujo de trabajo de desarrollo basado en especificaciones de GitHub Next.

Un proceso completo y con opinión

Spec Kit te da todo el arco:constitution → specify → plan → tasks → implement. Cada paso tiene un slash command y un prompt diseñados para mantener al agente en raíles. Si quieres un proceso, Spec Kit te entrega uno.

Fuerte distribución y reconocimiento

Respaldado por GitHub Next, con una gran comunidad y una biblioteca creciente de extensiones. Para muchos desarrolladores, Spec Kit es el primer flujo de trabajo basado en especificaciones que encuentran.

Comandos agnósticos del agente

Los comandos de Spec Kit funcionan en Claude Code, Cursor, Copilot y más — el flujo de trabajo dirige al agente sin importar cuál ejecutes.

Comparación de funcionalidades.

Estas herramientas responden preguntas distintas, así que la tabla compara roles, no ganadores.

Capacidad	Spec Kit	SpecScore
Rol principal	Flujo de trabajo / metodología	Formato de almacenamiento + CLI
Salida de especificación	Markdown libre	Markdown + YAML frontmatter (estructurado)
Linting de especificaciones	Ninguno	Calidad de contenido — verbos vagos, ACs faltantes, referencias colgantes
IDs de requisitos / ACs	Ninguno	IDs direccionables por máquina (`REQ: slug`)
Estado del ciclo de vida	Implícito (paso del flujo de trabajo)	Aplicado — Draft → Approved → Implementing → Stable → Deprecated
Trazabilidad código-a-especificación	Ninguna	`specscore:` anotaciones + `Verifies:` trailers de commits
Consultar especificaciones desde el CLI	Andamiaje (`specify`, `plan`, `tasks`)	API de consulta — `feature list / show / deps`, `lint`, `code refs`
Dependencia de runtime	Python	Ninguna — binario Go único
Integración CI	Ejecutar el flujo de trabajo	`specscore lint` sale con código no-cero, hooks de pre-commit
Relación	Se componen — Spec Kit puede producir archivos de SpecScore
Licencia	MIT	MIT

Lo que SpecScore agrega.

La salida es lintable

Spec Kit produce Markdown libre — bueno o malo, se entrega. SpecScore verifica el resultado en dos capas: lintcomprueba de forma determinista que cada requisito tenga criterios de aceptación, que las referencias cruzadas se resuelvan y que las transiciones de estado sean válidas — y un revisor de IA (/review, /score) detecta criterios ambiguos y verbos vagos.

$ specscore lint checkout/apply-discount.md
  ✗ R3  no acceptance criteria
  ✗ link  "Related Feature: discount-tiers" not found

La salida es consultable

Spec Kit escribe archivos; leerlos de vuelta significa abrirlos. Las especificaciones de SpecScore responden preguntas desde el CLI: specscore feature list,feature deps, code refs — así un agente navega el grafo de especificaciones sin leer cada archivo del repositorio.

Cada requisito tiene un ID

Spec Kit referencia requisitos por prosa. SpecScore asigna IDs basados en slug (REQ: slug-format) e IDs de ACs que sobreviven renombramientos, refactorizaciones y traspasos entre agentes.

El ciclo de vida se aplica

En Spec Kit, la etapa de una especificación es donde estés en el flujo de trabajo. En SpecScore, el ciclo de vida es un campo de estado aplicado — Draft → Approved → Implementing → Stable → Deprecated — validado por lint y transicionado por specscore change-status desde git hooks o CI.

El código se traza de vuelta a las especificaciones

Spec Kit no tiene mecanismo de trazabilidad. SpecScore tiene anotaciones de fuente specscore: y trailers de commit Verifies:— ejecuta specscore code refs para una respuesta determinista a "¿qué código implementa este requisito?"

Sin dependencia de runtime

SpecScore es un binario Go único — sin runtime que instalar. Funciona en proyectos Go, Rust, Python, Java o JavaScript sin agregar nada al toolchain.

Cuándo usar cada uno.

Recurre a Spec Kit cuando…

Quieres un proceso guiado y con opinión de la idea a la implementación.
Tu equipo necesita la disciplina de pasos explícitos de specify / plan / tasks.
Estás estandarizando cómo se dirigen los agentes en un equipo.

Usa SpecScore cuando…

Necesitas especificaciones que los agentes puedan lintear, consultar y mutar sin leer cada archivo.
Necesitas trazabilidad código-a-especificación con una respuesta determinista.
Estás construyendo un sistema grande con muchas features y transiciones de ciclo de vida.
Quieres cero dependencias de runtime — un binario, sin toolchain de lenguaje requerido.
Necesitas puertas de calidad de especificaciones en CI que salgan con código no-cero, como ESLint o go vet.

SpecScore extiende Spec Kit — no lo reemplaza.

Spec Kit es el proceso para producir una especificación; SpecScore es el formato en el que esa especificación puede escribirse. Una extensión de Spec Kit que emita el formato de SpecScore está en camino — ejecuta el flujo de trabajo de Spec Kit y obtén especificaciones que se linteen, consulten y tracen del otro lado.

Elige Spec Kit para el proceso. Elige SpecScore para el artefacto. Ejecuta ambos cuando quieras ambos.

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.