El formato
Markdown + YAML. Funciona en cualquier editor que abra texto. No requiere herramientas nuevas para empezar a escribir.
Cada ambigüedad en tu especificación
es un token que tu agente quema.
Luego una pregunta a mitad del desarrollo. Luego una corrección tras el despliegue. Luego el contexto que explicas una y otra vez.
SpecScore es un formato de archivo abierto y lintable para especificaciones — como JSON para los datos. Con una CLI que tus agentes invocan para consultarlas y editarlas — como jq para JSON.
Un formato para las especificaciones que ya escribes.
SpecScore es un formato Markdown + YAML para features, requisitos y criterios de aceptación. Define una estructura que tu equipo y tus agentes de IA entienden por igual — y son solo archivos en tu repositorio.
Un proyecto SpecScore se compone de tres tipos de artefactos a lo largo de un ciclo de vida: una Idea captura una dirección a medio formar; una especificación de Featurecongela el comportamiento acordado; un Plandescompone la feature en tareas ordenadas, cada una citando los criterios de aceptación que satisface.
Por qué le importa a tu agente. Como la estructura es legible por máquina, los agentes de IA pueden consultar la especificación a través de la CLI en lugar de leer cada archivo. Pregunta «¿en qué debería trabajar ahora?» y la CLI devuelve las features abiertas y las preguntas sin responder. La misma forma que revisa tu equipo; mucho menos contexto que el agente tiene que cargar.
Las especificaciones son jerárquicas. Tu árbol de especificaciones también.
Una lista plana con cincuenta Features se vuelve un vertedero. SpecScore mantiene el árbol navegable: los padres dueños del alcance, los hijos dueños del detalle, y la forma del directorio espeja la forma del producto sobre la que tu equipo ya razona.
Las preguntas abiertas se elevan. Las preguntas sin resolver a cualquier profundidad aparecen en el índice de cada padre. Ves qué bloquea una release desde la cima del árbol, sin tener que escarbar para encontrarlo.
La mayoría de las herramientas de especificaciones asumen que una lista plana funciona. Y funciona — hasta que deja de hacerlo. SpecScore está hecho para el momento en que «¿dónde vive esta Feature?» empieza a importar.
specscore-cli/spec/features/cli/spec/features/cli/
├── agent/
│ └── setup/
├── feature/
│ ├── change-status/
│ ├── deps/
│ ├── info/
│ ├── list/
│ ├── new/
│ ├── refs/
│ └── tree/
├── idea/
│ ├── change-status/
│ ├── new/
│ └── relocate/
├── spec/
│ └── lint/
│ ├── issue-rules/ ← sub-sub-Feature
│ └── plan-rules/
├── task/
│ ├── info/
│ ├── list/
│ └── new/
└── … 10 Features más de nivel superiorQué se rompe cuando no está.
Las especificaciones se desincronizan.
La especificación en el documento, el hilo en Slack y el código en el PR discrepan en silencio durante semanas. Nadie sabe cuál versión de la conversación es la canónica.
La solución
Una sola especificación canónica, en el repo, versionada junto al código.
specscore lintcorre en CI en cada push; el historial de git es el rastro de auditoría. La especificación, el hilo y el PR no pueden discrepar en silencio — comparten el mismo archivo bajo revisión.Los AC quedan vagos.
"Maneja los errores con elegancia" debía significar"mostrar un toast y revertir." ¿O era"loggear y reintentar?" El agente tiene que adivinar.
La solución
El linter detecta criterios ambiguos antes de que se escriba una sola línea de código. El verbo no pasa el lint porque carece de objeto o condición concreta. Resolver la advertencia obliga a escribir qué significa"maneja" en realidad.
Los agentes entregan lo que no era.
Las personas interpolan, preguntan, aclaran. Los agentes de IA no — implementan el patrón más común en sus datos de entrenamiento. El código pasa la revisión porque hacealgo sensato. Solo que no es lo que querías decir.
La solución
Entrada estructurada. Los agentes de IA parsean REQ IDs, AC IDs y escenarios
GIVEN / WHEN / THENde forma determinista — no hay nada que interpolar. Cada tarea del Plan debe citar los AC IDs que satisface, de modo que lo construido siempre sea verificable contra lo especificado.Pagas dos veces por una especificación ambigua.
El agente construye algo a partir de un brief ambiguo, ves que está mal y vuelves a pedírselo — de cuatro formas distintas. Cada función a medio hacer y cada reintento se facturan en tokens. Cuanto más vaga la especificación, más rondas antes de acertar.
La solución
Lintea la especificación antes de que el agente se ejecute.
specscore lintrechaza los verbos vagos y los criterios de aceptación que faltan desde el principio, así el agente implementa un brief concreto una sola vez en lugar de adivinar entre reintentos. La ejecución más barata es la que no tienes que repetir.Los agentes pagan por releer tus especificaciones.
Un agente de IA que responde "¿qué depende de esta feature?" lee el README completo de la feature. Después cada índice padre. Después las features hermanas por si acaso. Cada consulta es un nuevo parseo. Los tokens se evaporan; la latencia sube; la factura sube con ellos.
La solución
Consultas estructuradas en vez de lectura de archivos.
specscore feature treedevuelve la jerarquía como YAML;feature depsrecorre la cadena transitiva de dependencias;feature infoexpone estado, owner y preguntas abiertas — cada una en una sola llamada. El agente navega el grafo, no la prosa.El código olvida su especificación.
Seis meses después estás depurando una función y nadie recuerda qué feature implementa. El vínculo entre código y especificación vivía en la cabeza de alguien, y esa persona ya no está. El PR que lo introdujo quedó en el archivo.
La solución
Anotaciones en el código fuente. Comentarios como
// specscore: features/checkout/apply-discount/R1.AC-2hacen el vínculo legible por máquina y sobreviven a cualquier refactor.specscore code depsresponde"¿qué especificación implementa este archivo?" en una sola llamada; el linter marca las referencias que apuntan a especificaciones eliminadas.Los cambios de estado se fugan.
Mueves una feature de Draft a Approveden su README, pero el features-index padre la sigue listando como Draft. Tres semanas después, un agente que lee el índice cree que sigue en revisión. El estado vive en dos lugares, y discrepan.
La solución
specscore feature change-statusreescribe el campo Status de la feature y resincroniza la fila del features-index en un solo paso atómico — si falla el lint, la reescritura se revierte. El estado existe en un único lugar canónico; el índice es una vista generada de ese estado.Las especificaciones olvidan lo que no saben.
Una especificación se lee como si estuviera cerrada — hasta que recuerdas que la pregunta"¿y qué pasa con las zonas horarias?" se perdió en un hilo de Slack hace dos meses y nunca llegó al documento. Ahora estás en la implementación y nadie sabe cuál fue la respuesta.
La solución
Cada feature SpecScore tiene una sección obligatoriaOutstanding Questions. El linter rechaza las features que la omiten — vacía está bien (
"None at this time."), pero ausente no. Las preguntas sin resolver están visibles en el documento, consultables desde la CLI e imposibles de olvidar.
La forma más fácil de empezar: SpecStudio Skills para agentes de IA.
SpecStudio Skillses un plugin de Claude Code que convierte el ciclo de vida de SpecScore en cuatro comandos slash. Instálalo una vez, después ejecútalos en orden — desde la idea cruda hasta un plan ejecutable.
$ /plugin marketplace add specscore/ai-marketplace $ /plugin install specstudio@specscore
Claude Codeautocompletado
> /specstudio: /specstudio:ideate Refinar una idea cruda en una SpecScore Idea /specstudio:specify Convertir una Idea aprobada en una especificación de Feature /specstudio:plan Descomponer una Feature en un Plan de tareas /specstudio:implement Ejecutar la próxima tarea del Plan
Gratis para repositorios públicos y open-source. El código del plugin está enspecscore/specstudio-skills — bajo licencia MIT.
Revisa tu especificación en dos pasadas.
Un linter determinista y rápido, y luego una revisión de IA más profunda — ejecutados sobre la especificación que acabas de ver. Dos pasadas, dos tipos de certeza.
Ejecuta el linter.
deterministic$ specscore lint apply-discount.md ✓ R1 has acceptance criteria ✓ R2 has acceptance criteria ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found ✗ section "Open Questions" missing 3 problems exit 1
El mismo resultado en cada ejecución. Gratis, rápido, se ejecuta en cada commit.
Revisa y puntúa con IA.
non-deterministic> /score apply-discount.md Grade: B — ready with edits AC-2 vague trigger — name the actor and event AC-3 no error path for an expired code prose reads clean; criteria need tightening
Lee buscando el sentido, como un revisor humano.
Qué viene en la caja.
El linter
CLI en Go. Valida estructura, referencias e integridad. Sale con código distinto de cero al fallar — funciona en tu terminal y en tu CI.
Trae tus propias herramientas.
SpecScore son solo archivos en tu repositorio. Sin SaaS al que registrarse. Sin orquestador obligatorio. Úsalo con Linear, Jira, GitHub Projects, Markdown sin más en una carpeta, o sin gestor de proyectos en absoluto. Al formato y al linter les da igual dónde vivan tus tickets.
Cómo se compara SpecScore.
El desarrollo basado en especificaciones es un espacio concurrido. Esto es dónde se sitúa SpecScore frente a las alternativas — con honestidad.
Plain MarkdownLo predeterminado. SpecScore es a lo que evoluciona tu Markdown.OpenSpecUna buena rampa de entrada. SpecScore son las barandas de seguridad.Spec KitSpec Kit es el flujo de trabajo. SpecScore es el artefacto.DatarimDatarim ejecuta el pipeline. SpecScore es lo que queda después.CodeSpeakCodeSpeak apuesta por un compilador. SpecScore apuesta por un formato.
¿Prefieres la CLI?
¿No usas agentes de IA, o necesitas validación de especificaciones en tu pipeline de CI? Hay una CLI para eso. Se instala en 60 segundos — sin cuenta, sin telemetría, funciona en cualquier carpeta de especificaciones en Markdown.
$ curl -fsSL https://specscore.md/install/get-cli | sh> irm https://specscore.md/install/get-cli.ps1 | iexPasa el linter a la especificación de ejemplo que viene con el binario:
$ specscore lint examples/checkout/apply-discount.mdMira la salida:
examples/checkout/apply-discount.md
✓ R1 has acceptance criteria
✓ R2 has acceptance criteria
✗ R3 no acceptance criteria
✗ link "Related Feature: discount-tiers" not found
✗ section "Open Questions" missing
3 problems exit 1Construido sobre SpecScore.
Codegrapher
Motor de grafo de código para exploración rápida del código y enlace bidireccional entre especificaciones y código.
codegrapher.devDALgo
Capa de acceso a datos en Go, especificada con SpecScore.
dal-go.github.ioinGitDB
Base de datos versionada respaldada por Git, especificada con SpecScore.
ingitdb.comRehearse
Capa de evidencia de aceptación: ejecuta de verdad los criterios de aceptación de una especificación, con comprobaciones reutilizables y sin código de pegamento.
rehearse.inkSpecScore Studio
Interfaz web para visualizar y editar especificaciones SpecScore.
specscore.studio