Skip to content

Spec Kit

El kit de GitHub para el desarrollo guiado por especificaciones: comandos de constitución, especificación, plan, tareas, implementación y convergencia para más de 40 agentes de programación.

Reseña de Sheela · Actualizado

Ver en GitHub Código abierto

Nuestra nota

4.3/5

Spec Kit convierte el trabajo del agente en documentos revisables en git, y lo cobra en horas de lectura humana por funcionalidad.

¿Qué es Spec Kit?

Spec Kit es la propuesta de código abierto de GitHub para el desarrollo guiado por especificaciones. La CLI specify prepara un proyecto, y los comandos slash de tu agente recorren una constitución, una especificación de la funcionalidad, un plan técnico, una lista de tareas, la implementación y un paso de convergencia que comprueba el resultado frente a los documentos.

La corrección de fallos y la evaluación de ideas son extensiones opcionales. Los presets, workflows, bundles y catálogos permiten a los equipos cambiar las plantillas, añadir controles de calidad o alojar un catálogo privado de componentes aprobados. Se instala con uv tool install specify-cli, necesita Python 3.11 o posterior y funciona en Linux, macOS y Windows.

¿Merece la pena Spec Kit?

Spec Kit es el flujo de trabajo guiado por especificaciones con más estrellas en GitHub, y su valor depende por completo de que alguien lea las especificaciones. El repositorio tiene unas 142.500 estrellas y publica rápido: la v1.0.0 llegó el 21 de agosto de 2026, y ocho versiones salieron entre el 2 y el 22 de octubre, hasta la v1.2.3. La página de integraciones enumera 41 agentes de programación por su nombre, de Claude Code y Copilot a Cursor, Codex CLI, Kiro y Zed, más una opción genérica.

Su punto fuerte es que el contrato vive en archivos. La constitución, la especificación, el plan y las tareas son Markdown en el repositorio, así que pasan por pull requests como el código, y el paso de convergencia comprueba la implementación frente a ellos hasta que informa Converged. Los presets pueden imponer los estándares de una organización, y la extensión de fallos registra una causa, una corrección y un veredicto de verificación en .specify/bugs.

El coste es el tiempo de lectura. La guía de producción de Wavect dice que por sí solo no deja el código generado por IA listo para producción, y cuando el CTO de Scott Logic reconstruyó dos funcionalidades con él, la revisión llevó unas 3,5 horas y 2 horas frente a una media hora aproximada de tiempo de agente en cada una. Para una corrección de una línea esa sobrecarga es absurda, y por eso la extensión de fallos se salta el flujo completo de funcionalidades.

Dos cuestiones de gobernanza importan a quien compra. Las entradas del catálogo de la comunidad sirven solo para descubrir, no son auditorías, así que un equipo debería mantener un catálogo privado de extensiones aprobadas, algo que Spec Kit admite junto con instalaciones sin conexión. Y el ritmo semanal de versiones hace que las plantillas y los nombres de los comandos cambien; fijar una versión, como describe la documentación de instalación, mantiene a todos los ingenieros en el mismo proceso. BMAD cubre un terreno similar con más perfiles, y usar ambos en un mismo proyecto produce dos conjuntos de planes que compiten entre sí.

Dónde se gana su sitio

  • Una líder técnica en un equipo de producto de 12 ingenieros que usa Copilot y Claude Code

    Hacer revisables las funcionalidades construidas por agentes antes de escribir el código

    Cada funcionalidad recibe una especificación y un plan en una pull request que aprueba un ingeniero sénior antes de ejecutar /speckit-implement. El software es gratuito, pero hay que presupuestar horas, no minutos, de revisión humana por cada funcionalidad no trivial.

  • Un director de ingeniería en una fintech regulada

    Mostrar a los auditores cómo se especificaron y verificaron los cambios asistidos por IA

    Un preset codifica los estándares de la empresa en la constitución y un catálogo privado limita las extensiones a las aprobadas. La especificación, el plan y la salida de convergencia en git forman un rastro documental; el riesgo es que los revisores den el visto bueno a documentos largos sin leerlos.

  • Un desarrollador en solitario que corrige un fallo en producción con un agente

    Corregir un cierre inesperado sin perder de vista la causa

    `specify extension add bug` y después los comandos de evaluación, corrección y prueba escriben un informe cuyo veredicto es verified, partial o failed. Es más ligero que el flujo de funcionalidades y solo cuesta el uso del propio agente.

Antes de decidirte

Puesta en marcha
`uv tool install specify-cli` y después `specify init my-project --integration copilot` (Python 3.11+, uv y un agente compatible); la primera especificación sale de unos cuantos comandos slash en el chat del agente.
Integraciones
41 agentes por su nombre, entre ellos Claude Code, GitHub Copilot, Gemini CLI, Codex CLI, Cursor, Cline, opencode, Kiro CLI y Zed; extensiones, hooks, presets, workflows y bundles para personalizarlo.
Datos y privacidad
Se ejecuta en local y escribe Markdown en tu repositorio; tu agente envía ese contenido a su propio proveedor de modelos. La documentación no menciona telemetría. Licencia MIT; sin avisos de seguridad publicados en GitHub.
Coste a escala
No hay edición de pago. Los costes reales son el uso del agente con tu plan actual y el tiempo de los revisores: unas 2 a 3,5 horas por funcionalidad en la prueba publicada por Scott Logic.
Límites
Las versiones semanales cambian las plantillas; el catálogo de la comunidad no está auditado; es pesado para cambios pequeños; no se combina de forma sensata con BMAD en un mismo proyecto.

Lo bueno

  • Especificación, plan y tareas revisados en git como el código
  • 41 integraciones con agentes por su nombre más una opción genérica
  • Catálogos privados e instalaciones aisladas de la red para empresas
  • El paso de convergencia comprueba el código frente a la especificación

Lo malo

  • Horas de revisión de documentos por cada funcionalidad no trivial
  • Excesivo para correcciones pequeñas
  • Las entradas del catálogo de la comunidad no están auditadas
  • Las versiones frecuentes cambian plantillas y comandos

Ideal para

Equipos que quieren especificaciones escritas y revisables antes de que un agente escriba código.

Alternativas a Spec Kit

Spec Kit: preguntas frecuentes

¿Merece la pena Spec Kit?
Spec Kit convierte el trabajo del agente en documentos revisables en git, y lo cobra en horas de lectura humana por funcionalidad. Le damos un 4.3 sobre 5.
¿Cuánto cuesta Spec Kit?
Gratuito y de código abierto (MIT).
¿Qué inconvenientes tiene Spec Kit?
Horas de revisión de documentos por cada funcionalidad no trivial; excesivo para correcciones pequeñas; las entradas del catálogo de la comunidad no están auditadas; las versiones frecuentes cambian plantillas y comandos.
¿Para quién es Spec Kit?
Equipos que quieren especificaciones escritas y revisables antes de que un agente escriba código.
¿Cuánto cuesta Spec Kit para un equipo o en producción?
No hay edición de pago. Los costes reales son el uso del agente con tu plan actual y el tiempo de los revisores: unas 2 a 3,5 horas por funcionalidad en la prueba publicada por Scott Logic.
¿Es Spec Kit seguro para los datos de la empresa?
Se ejecuta en local y escribe Markdown en tu repositorio; tu agente envía ese contenido a su propio proveedor de modelos. La documentación no menciona telemetría. Licencia MIT; sin avisos de seguridad publicados en GitHub.
¿Cuáles son las mejores alternativas a Spec Kit?
Las alternativas más cercanas que hemos analizado son BMAD Method, Superpowers y Matt Pocock's Skills.

Respuestas comprobadas el 26 oct 2026.