mouredev/hello-sdd/spec-generator

Generador de specs

Convierte una idea vaga en una especificación acordada. La spec es el contrato: si algo no está aquí, no se implementa.

Proceso

1. Lee el contexto. docs/constitution.md si existe, y las specs previas

de specs/ para respetar convenciones y no contradecir lo ya acordado.

1. Entrevista al usuario. Preguntas de UNA en UNA, máximo 6, esperando

respuesta antes de la siguiente. Céntrate en casos límite, comportamiento ante errores y qué queda fuera. No propongas soluciones técnicas: si el usuario pregunta "¿cómo lo harías?", redirige al QUÉ. Prioriza preguntas cuya respuesta cambie lo que hay que construir; descarta las que tengan una respuesta obvia por defecto.

1. Elige el número. Mira specs/ y usa el siguiente libre con tres

dígitos: specs/NNN-<nombre-en-kebab-case>/spec.md.

1. Redacta usando spec-template.md de esta skill, sin saltarte

secciones. Criterios de aceptación siempre en notación EARS, numerados como RF-1, RF-2, … Cada requisito debe ser verificable: si no se te ocurre cómo comprobarlo, está mal escrito.

1. Marca lo que no sepas como [NECESITA ACLARACIÓN: pregunta concreta].

Nunca rellenes un hueco inventando: un hueco visible es información, una suposición silenciosa es deuda.

1. Pide aprobación explícita al terminar. No pases al plan ni escribas

código hasta tenerla.

Reglas

• La spec describe QUÉ y POR QUÉ. Prohibido incluir stack, arquitectura,

nombres de archivos, esquemas de datos, algoritmos o firmas de funciones: eso va en el plan.

• Incluye siempre la sección "Fuera de alcance". Es la que evita que la

funcionalidad crezca sola.

• Un requisito, una frase. Si necesitas un "y" para unir dos comportamientos,

son dos requisitos.

• Sin adjetivos no medibles: "rápido", "intuitivo", "robusto" no son

requisitos. Escribe el umbral o no lo escribas.

• Idioma: el de la constitución del proyecto. Si no la hay, el del usuario.

Notación EARS

Cinco patrones. Elige el que corresponda, no mezcles:

Ejemplo bien escrito:

RF-4: SI el nombre ya existe (comparación ignorando mayúsculas y espacios

exteriores), ENTONCES EL SISTEMA no creará un duplicado e informará del

conflicto (salida 1).

Mal escrito, para contrastar:

RF-4: El sistema debe manejar bien los duplicados y ser rápido.

Sin patrón EARS, sin criterio verificable, dos ideas en una frase y un

adjetivo no medible.

Al revisar una spec existente

Si el usuario pide revisar en vez de crear, no reescribas: detecta y lista, numerado, en cuatro bloques — (1) ambigüedades, (2) contradicciones entre requisitos, (3) casos límite no cubiertos, (4) conflictos con la constitución. No propongas soluciones hasta que te lo pidan.