Workflow SDD

Spec Driven Development trata las specs como contratos de desarrollo vivos. Cada fase de la implementación está validada por criterios claramente definidos, verificados automáticamente en cada transición.

El Ciclo de Vida

clarify → create_spec → DoR check → implement (PLAN.md) → validate → drift detection → done

Cada flecha es una compuerta. No puedes avanzar sin satisfacer la Definition of Done de la fase anterior.

Fase 1 — Clarificar

Herramientas: clarify_requirements, reality_check

Antes de escribir una sola línea de spec, saca a la superficie las ambigüedades.

Prompt: "Use specforge to clarify requirements for [feature] in project [id]"
Prompt: "Usa specforge para clarificar los requisitos de [feature] en el proyecto [id]"

clarify_requirements genera una lista dirigida de preguntas — límites de alcance, casos borde, requisitos no funcionales, dependencias externas — para que la spec comience con una intención limpia e inequívoca.

reality_check evalúa si los requisitos son factibles dado el contexto actual del proyecto. Detecta situaciones "imposibles para el viernes" antes de que se conviertan en deuda técnica.

Fase 2 — Crear la Spec

Herramientas: create_spec, design_schema, define_ui_contract, generate_adr

Prompt: "Create a spec for [feature] in project [id]"

create_spec genera un HU.md estructurado con:

Sección	Qué contiene
User Story	Quién, qué, por qué
Criterios de Aceptación	Criterios testeables e inequívocos
Checklist DoR	Compuertas de Definition of Ready
Hints de Esquema DB	Tablas, columnas, relaciones
Contratos de UI	Contratos de componentes, gestión de estado
Hints de ADR	Architecture Decision Records
PLAN.md	Plan de ejecución paso a paso

Cuando el proyecto tiene arquitectura AI-native detectada, la spec también genera:

• Presupuestos de latencia y cadenas de fallback
• Criterios de versionado de prompts
• Requisitos de observabilidad LLM

Fase 3 — Verificación DoR

Herramientas: check_readiness, detect_contradictions

Antes de que comience la implementación, verifica que la spec esté realmente lista.

Prompt: "Check if spec SPEC-003 is ready for implementation in project [id]"

check_readiness evalúa:

• Completitud de los criterios de aceptación
• Calidad de los criterios (¿son testeables e inequívocos?)
• Estado de dependencias (¿están resueltas las specs bloqueantes?)
• Cumplimiento de la Constitución

detect_contradictions escanea todas las specs en busca de conflictos semánticos — detecta situaciones donde SPEC-A dice "los usuarios pueden eliminar su cuenta" y SPEC-B dice "las cuentas son inmutables."

Fase 4 — Implementar

Herramientas: generate_execution_plan, package_handoff, generate_tests

Prompt: "Generate an execution plan for spec SPEC-003 in project [id]"

generate_execution_plan produce un PLAN.md con:

• Pasos del ciclo RED/GREEN/VERIFY
• Pasos paralelizables identificados
• Propiedad de archivos por paso
• Esfuerzo estimado por paso

package_handoff empaqueta la spec en un paquete estructurado para que un agente de IA la implemente — objetivo, criterios, lista de archivos, restricciones — listo para implementación autónoma.

generate_tests produce un plan de tests y stubs de archivos de test a partir de los criterios de aceptación de la spec.

Fase 5 — Validar

Herramientas: validate, audit, security_check

Después de la implementación, verifica la cobertura:

Prompt: "Validate spec SPEC-003 against the code at /path/to/src"

validate comprueba:

• Qué criterios de aceptación están cubiertos por el código
• Cuáles faltan o están parcialmente implementados
• Porcentaje de cobertura global de la spec

audit puntúa la implementación de 0–100 en:

• Principios SOLID
• Clean code
• Cumplimiento de arquitectura
• Violaciones de la Constitución

security_check pasa la spec por el OWASP Top 10 y escanea el código en busca de patrones inseguros, generando un score de seguridad (A–F).

Fase 6 — Detección de Drift

Herramientas: detect_drift, reconcile_spec

A medida que los requisitos evolucionan, mantén specs y código alineados:

Prompt: "Detect drift in spec SPEC-003 for project [id]"

detect_drift reporta:

• Criterios que ya no coinciden con el código
• Violaciones de la Constitución introducidas desde el último chequeo
• Impacto downstream: qué otras specs están afectadas por el drift

Cuando el drift es intencional (la spec necesita actualizarse):

Prompt: "Reconcile spec SPEC-003 with the implementation changes in project [id]"

reconcile_spec presenta cada cambio para aprobación individual y verifica el cumplimiento de la Constitución antes de guardar.

La Constitución del Proyecto

La Constitución es un conjunto de principios arquitectónicos inmutables extraídos de tu CLAUDE.md, .cursorrules, u otros archivos de configuración de agentes de IA.

Prompt: "Initialize the constitution for project [id] from CLAUDE.md"

Una vez configurada, la Constitución se aplica automáticamente en create_spec, audit y detect_drift. Las violaciones se señalan antes de llegar al code review.

Transiciones de Estado

Estado	Descripción
draft	Spec creada, aún no lista
ready	Pasó la verificación DoR
in_progress	Implementación iniciada
review	Implementación completa, pendiente de validación
done	Validada y aceptada
blocked	Bloqueada por dependencia

Prompt: "Update status of spec SPEC-003 to in_progress in project [id]"

Cada transición ejecuta validación DoR/DoD. No puedes marcar una spec como done sin cumplir los criterios DoD.