PulseFlow Tecnologia
← Insights
·6 min de lectura·framework-playbook·spec-driven-development·spec-kit·coding-agents
PulseFlow Tecnologia

Un framework de spec-driven development con IA

Con más de 118.000 estrellas en GitHub, 10.500 forks e integración con más de 30 agentes de código distintos - incluyendo GitHub Copilot, Claude Code, Gemini y Codex CLI —, Spec Kit dejó de ser un experimento y se convirtió en referencia de cómo estructurar el spec-driven development en la práctica. El framework a continuación usa los propios comandos de Spec Kit como esqueleto.

Los comandos centrales como fases del framework

Spec Kit organiza el proceso en seis comandos principales: /speckit.constitution establece los principios y directrices del proyecto antes de cualquier especificación de feature; /speckit.specify define requisitos e historias de usuario; /speckit.plan crea la estrategia técnica de implementación; /speckit.tasks genera la división en tareas ejecutables; /speckit.implement ejecuta la implementación conforme al plan; y /speckit.converge evalúa el código ya existente contra las especificaciones - útil tanto para detectar deriva como para retrofitting de specs en código legado.

Comandos opcionales que resuelven la ambigüedad

Tres comandos adicionales cubren los casos donde la especificación inicial no es suficiente: /speckit.clarify resuelve requisitos ambiguos antes de avanzar; /speckit.analyze hace una verificación de consistencia entre los artefactos generados (spec, plan, tareas); /speckit.checklist permite validaciones de calidad personalizadas por proyecto.

La estructura de artefactos que sobrevive al código

Una vez inicializado, un proyecto genera una carpeta specs/[feature-name]/ con spec.md, plan.md, tasks.md, data-model.md y contratos de API - artefactos versionados junto con el código, no documentación externa que se desactualiza. Una carpeta .specify/ guarda la constitución del proyecto, plantillas y capas de personalización (extensiones, presets, bundles por rol).

Intent-driven, no single-prompt

La propuesta central de Spec Kit es el "intent-driven development" mediante refinamiento en múltiples etapas, en vez de generación de código en un solo prompt. Esa es la misma distinción que separa el spec-driven development del vibe coding: describir la intención y dejar que se refine en specs, planes y tareas revisables, en vez de pedir un resultado final directo y aceptar lo que llegue.

El framework de diez etapas

  1. Requisito - la necesidad de negocio, antes de cualquier spec
  2. Especificación - jornada del usuario y criterio de éxito (/speckit.specify)
  3. Criterios de aceptación - parte de la spec, no un documento aparte
  4. Plan técnico - stack, arquitectura, restricciones (/speckit.plan)
  5. Pruebas esperadas - definidas antes de la implementación, no después
  6. Ejecución por el agente - dividida en tareas revisables (/speckit.tasks, /speckit.implement)
  7. Validación - verificación de consistencia entre spec, plan y código (/speckit.analyze)
  8. Revisión humana - sobre unidades pequeñas, no un PR monolítico
  9. Corrección - ciclo de ajuste vía /speckit.clarify cuando la spec era ambigua
  10. Documentación - los propios artefactos de spec, versionados junto con el código

Fuentes