GitHub Spec Kit 1.0: guía práctica de spec-driven development

Una spec no es documentación. Es el contrato operativo entre tu intención y el agente que la ejecuta. GitHub Spec Kit pone ese contrato en el centro de tu workflow.

GitHub Spec Kit es el toolkit open source de GitHub que lleva el spec-driven development a tu agente de IA para código. Instalas la CLI specify, ejecutas specify init en tu proyecto y el agente obtiene un pipeline de skills que convierte una descripción de lo que quieres en una implementación verificada contra esa descripción. Funciona con GitHub Copilot, Claude Code, Gemini CLI, Cursor, Codex y unos cuarenta agentes más.

La respuesta corta, para el featured snippet: Spec Kit es un toolkit open source, publicado por GitHub bajo licencia MIT, que les da a los agentes de IA para código procesos estructurados, plantillas y resultados documentados. Su proceso central es spec-driven development; la corrección de bugs y la evaluación de ideas vienen como extensions opcionales. Llegó a la 1.0 en agosto de 2026 y tiene unas 140.000 estrellas en GitHub.

Si el método de fondo es nuevo para ti, empieza por qué es spec-driven development. La herramienta viene después del método. Y si estás comparando Spec Kit con las alternativas, lo puse frente a frente en OpenSpec vs. Spec Kit vs. Superpowers, con pi-sdd-kit en la cuenta.

Qué cambió en el camino a la 1.0

La mayoría de las guías de Spec Kit se escribieron en el lanzamiento, a fines de 2025. La mitad de lo que dicen ya no es cierto. Lo curioso es que la 1.0 en sí casi no cambió nada: sus release notes argumentan que una versión mayor ya no tiene por qué significar dolor de migración, y el changelog son arreglos de rutina. Los cambios de verdad llegaron en los meses anteriores.

Cómo Spec Kit llegó a la 1.0

1. 18 jun 2026v0.11.2: llega converge

   Un paso después de implement que verifica el código contra la spec, el plan y las tasks, y agrega lo que falta.

2. 5 ago 2026v0.16.0: skills por defecto

   Copilot pasa a modo skills. Claude Code ya instalaba skills en .claude/skills.

3. 21 ago 2026v1.0.0

   La versión mayor, sin breaking changes.

4. 1 sep 2026v1.0.3: --require-spec

   Analyze y converge se niegan a correr sin un spec.md en disco.

5. 15 sep 2026v1.0.7: tres procesos

   El README ahora presenta spec-driven development, bug fixing e idea assessment como puntos de entrada independientes.

6. 21 sep 2026v1.0.9: bundles

   Los bundles oficiales empaquetan los setups de bug fixing y assessment en una sola instalación.

7. 29 sep 2026v1.0.13: extensión github

   taskstoissues empieza a salir del core hacia una extensión github empaquetada.

Cuatro cambios pesan más que el resto. Las branches son opt-in: el core de Spec Kit ya no toca git, y las feature branches numeradas vienen de una extensión de git que agregas tú. Las carpetas de feature se movieron a specs/ en la raíz del repo. El archivo de contexto del agente (CLAUDE.md para Claude Code) ahora es una extensión opt-in, así que specify init ya no lo edita. Y hay un camino corto oficial para trabajo chico, que responde a la queja más fuerte que recibió la herramienta.

El problema que resuelve Spec Kit

Los agentes de IA para código son rápidos. También son stateless y literales. Describe un objetivo de forma vaga y el agente se va hacia la implementación más común de esa descripción, no hacia tu intención específica. El resultado compila. Es sintácticamente correcto. Solo que no hace lo que querías.

La solución no es un mejor prompt. Es un artefacto estructurado, escrito y aprobado antes de que empiece la implementación, que le da al agente la claridad que no puede inferir de un mensaje en el chat. Ese artefacto es la spec.

Spec Kit no cambia esa idea. La vuelve operativa. En lugar de sostener la disciplina a mano, obtienes skills que guían al agente por cada fase, plantillas que te obligan a escribir lo correcto y una estructura de directorios que mantiene los artefactos ordenados entre features.

Instalar e inicializar

Spec Kit necesita Python 3.11 o superior y uv. Git ahora es opcional: solo lo necesitas si activas la extensión de git.

Instalar la CLI specify

1. Desde PyPI

   $ uv tool install specify-cli

2. Fijada a una versión

   $ uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

3. Ejecutar una vez sin instalar

   $ uvx --from git+https://github.com/github/spec-kit.git specify init my-project

pipx install specify-cli y pip install specify-cli también funcionan. Una vez instalado, elige tu agente:

Inicializar para tu agente

1. Claude Code

   $ specify init my-project --integration claude

2. GitHub Copilot

   $ specify init my-project --integration copilot

3. Gemini CLI

   $ specify init my-project --integration gemini

4. OpenAI Codex

   $ specify init my-project --integration codex

El flag --integration le dice a specify qué agente usas, e instala los skills o comandos en el formato que ese agente espera. Para Claude Code eso significa skills en .claude/skills. Si lo omites en una terminal interactiva, specify te pregunta. En CI o en ejecuciones por pipe, usa Copilot por defecto. specify integration list los muestra todos, 42 al momento de escribir esto, y un proyecto puede tener más de uno.

Dos hábitos que vale la pena mantener. Actualiza con specify self upgrade en lugar de reinstalar. Y si quieres que Spec Kit mantenga una sección en tu CLAUDE.md o AGENTS.md, agrégala explícitamente con specify extension add agent-context. Sin esa extensión, Spec Kit nunca toca tu archivo de contexto del agente.

La estructura de Spec Kit después de una feature

• .specify/
  • memory/
    • constitution.md// principios del proyecto, leídos por plan y converge
  • scripts/// helpers que los skills invocan para resolver la feature activa
  • templates/// plantillas de spec, plan y tasks que acotan lo que escribe el agente
  • feature.json// apunta a la carpeta de la feature activa, en lugar de la branch de git
• specs/
  • 001-feature-name/feature
    • spec.md// requisitos funcionales y user stories
    • plan.md// arquitectura técnica y decisiones
    • research.md// investigación de librerías y APIs reunida durante la planificación
    • data-model.md// entidades y schemas
    • quickstart.md// cómo correr y verificar la feature
    • contracts/// contratos de API de la feature
    • tasks.md// tasks ordenadas con marcadores de paralelismo, más fases de convergencia
• .claude/skills/// los skills speckit-*, cuando la integración es Claude Code

Las plantillas dentro de .specify/templates/ son las que hacen el trabajo de verdad. Le indican al agente que marque las ambigüedades con [NEEDS CLARIFICATION] en lugar de adivinar, que separe los requisitos funcionales de las decisiones técnicas y que produzca checklists que actúan como gates de aceptación dentro de cada artefacto. La disciplina viene incorporada en las plantillas, no en tu fuerza de voluntad.

El pipeline, en orden

Después de specify init, tu agente tiene el pipeline completo. Solo hay una regla dura: tiene que existir una spec antes de planificar. Todo lo marcado como opcional es un gate de calidad que agregas cuando el trabajo lo amerita.

El pipeline de Spec Kit: de constitution a converge

Entrada

Una descripción de lo que quieres construir y por qué, sin decisión de stack

↓

1. 01/speckit-constitution (una vez por proyecto)

   Escribe los principios que rigen el proyecto en .specify/memory/constitution.md: reglas de calidad de código, requisitos de testing, restricciones. Plan los verifica y converge trata un MUST incumplido como crítico.

   ↓
2. 02/speckit-specify (por feature)

   Convierte tu descripción en spec.md con requisitos funcionales y user stories, en una carpeta nueva bajo specs/. Solo el qué y el porqué. Nada de decisiones de stack acá.

   ↓
3. 03/speckit-clarify (opcional)

   Hace preguntas estructuradas para sacar a la luz huecos y contradicciones en la spec, y registra las respuestas en una sección Clarifications.

   ↓
4. 04/speckit-plan (por feature)

   Toma la spec y tus decisiones de stack, y produce plan.md más research.md, data-model.md, quickstart.md y contracts/. Cada decisión técnica se remonta a un requisito.

   ↓
5. 05/speckit-checklist (opcional)

   Genera checklists de calidad para los artefactos, que equivalen a tests unitarios para texto en inglés: ¿la spec es inequívoca y está completa?

   ↓
6. 06/speckit-tasks (por feature)

   Produce tasks.md: unidades ordenadas y probables de forma independiente, con marcadores [P] en las tareas que pueden correr en paralelo.

   ↓
7. 07/speckit-analyze (opcional)

   Verifica la consistencia entre artefactos: ¿cada requisito llega al plan, y cada decisión del plan llega a una tarea?

   ↓
8. 08/speckit-implement (por feature)

   Ejecuta las tareas en orden de dependencias, respetando los marcadores de paralelismo, y reporta el avance.

   ↓
9. 09/speckit-converge (por feature)

   Verifica el código contra spec, plan, tasks y constitution, y agrega los huecos como tareas nuevas. Repite implement y converge hasta que reporte que convergió.

↓

Salida

Una implementación verificada contra su propia spec, con un rastro trazable desde la intención hasta el código

Para features más chicas, el quickstart oficial lo reduce a cinco: specify, plan, tasks, implement, converge. Las nueve completas son para trabajo de producción.

Una nota sobre sintaxis, porque cada guía vieja la escribe distinto. Los nombres con guion de arriba son skills, el default en Claude Code y Copilot. Todavía vas a ver la forma con punto (/speckit.specify) en la documentación de referencia y en posts más viejos. Codex usa $speckit-specify. Los mismos comandos, con grafía distinta según el agente. /speckit-taskstoissues, que convierte tasks.md en GitHub Issues, todavía funciona pero se está moviendo a la extensión github empaquetada.

Converge: el paso que admite que el agente dice que terminó antes de tiempo

Todos los equipos que usaron Spec Kit en 2025 se toparon con la misma pared. El agente terminaba implement, reportaba éxito, y el código cubría la mayor parte de la spec. La mayor parte. Converge, agregado en junio, es Spec Kit admitiéndolo en voz alta.

Después de implement, converge lee la spec, el plan, las tasks y la constitution, y después compara la codebase con ellas. A cada hueco le asigna una clase: missing, partial, contradicts o unrequested (código que nadie pidió). Nunca reescribe tu spec, tu plan ni tus tasks existentes. Solo agrega una nueva fase de convergencia a tasks.md. Corre implement de nuevo, y después converge de nuevo. Cada pasada encuentra menos. Cuando no queda nada, tasks.md queda byte por byte sin cambios y converge reporta que convergió.

Es el diseño correcto. No confía en el reporte que el agente hace de lo que hizo. Compara el artefacto con el código, que es exactamente el paso de revisión que la mayoría se salta una noche cansado.

El gate sigue siendo tuyo

Esto es lo que no cambió: no hay gate de aprobación entre fases. Desde la 1.0.3, analyze y converge corren con --require-spec, que hace que fallen si falta spec.md. Léelo con cuidado. Verifica que el archivo exista. No verifica que una persona lo haya leído, ni que haya estado de acuerdo.

Así que la decisión de pasar de tasks a implement sigue siendo tuya, y nada en Spec Kit frena a un agente ansioso que quiere avanzar sobre un borrador. La documentación del workflow es honesta sobre esto: tu trabajo en cada fase es reflexionar y refinar, no aprobar por omisión. Si quieres que el gate se imponga, lo agregas tú. Ese es el hueco que cierra el token .status de pi-sdd-kit, y vuelvo a eso más abajo.

La constitution no es opcional

Toda herramienta de SDD necesita una capa de memoria estable: el contexto de proyecto del que se alimentan todas las features. En Spec Kit, esa capa es la constitution.

La constitution vive en .specify/memory/constitution.md y contiene los principios que rigen todo el desarrollo: qué abstracciones son innegociables, requisitos de testing, reglas de simplicidad, políticas de seguridad. La escribes una vez con /speckit-constitution. Plan corre una verificación de constitution contra ella, y converge trata un principio MUST incumplido como un hueco crítico.

Así es el tipo que escribiría para un servicio de pagos, recortado. Sigue la forma de la propia plantilla de Spec Kit: principios numerados, secciones extra, governance y una línea de versión.

# Ledger Service Constitution

## Core Principles

### I. Money Is Integer (NON-NEGOTIABLE)

All amounts are stored and computed as integer minor units (cents, satoshis).
No floats anywhere in a money path. Rounding happens once, at display.

### II. Every Write Is Idempotent

Every operation that moves money takes an idempotency key. A retry with the
same key returns the original result and never charges twice.

### III. Real Database in Integration Tests

Integration tests run against Postgres, not mocks. A test that passes on a
mock and fails on the real database is a failed test.

### IV. Contract Tests First

Every external API (exchange, custody, payment provider) gets a contract test
that fails before any implementation starts.

### V. Simplicity

No new service, queue, or abstraction without a requirement in spec.md that
needs it. Complexity must be justified in plan.md.

## Security Requirements

Secrets come from the environment, never from the repo. Every endpoint that
moves money requires an authenticated session and writes an audit log entry.

## Governance

This constitution overrides conflicting guidance in any spec or plan.
Amendments need a written rationale and a version bump.

**Version**: 1.0.0 | **Ratified**: 2026-09-30 | **Last Amended**: 2026-09-30

El propio repo de Spec Kit corre con una constitution con enmiendas versionadas (major, minor, patch) y un reporte de sincronización cuando cambia un principio. Es una señal de qué tan en serio el proyecto se toma la consistencia arquitectónica. Escribe la constitution el primer día y mantenla viva.

Los tres casos de uso de GitHub

El propio GitHub describe tres situaciones en las que Spec Kit justifica su costo de setup.

El desarrollo greenfield, que el anuncio llama zero-to-one, es el caso más obvio. Tienes una idea, no una codebase. El workflow de Spec Kit te obliga a definir cómo se ve el éxito antes de que el agente escriba nada, y eso elimina el modo de falla más común: el agente construye algo técnicamente correcto que no coincide con lo que imaginabas.

El trabajo de features en sistemas existentes, el caso brownfield, es donde la herramienta resulta más útil en el día a día. Sumar algo a una codebase real exige capturar cómo interactúa la nueva feature con lo que ya existe. La spec codifica esas restricciones de interacción. El plan codifica decisiones de arquitectura que respetan el sistema existente. El resultado es código nuevo que se siente nativo y no pegado con cinta. Spec Kit ahora trae una guía dedicada para adoptarlo en un proyecto existente, y de todas formas necesitas darle al agente suficiente contexto sobre la codebase que ya tienes.

La modernización de legacy es el caso más difícil y el más interesante. Cuando la intención original de un sistema se perdió con el tiempo y entre código sin documentar, Spec Kit te da un proceso para capturar la lógica de negocio esencial en una spec moderna antes de reconstruir. No solo estás migrando código. Estás reconstruyendo intención, que es el problema más difícil.

La crítica de Böckeler, un año después

Birgitta Böckeler, de Thoughtworks, publicó la mejor evaluación independiente de Spec Kit en octubre de 2025, en martinfowler.com. Tenía razón, y Spec Kit claramente la leyó: su propia documentación sobre persistencia de specs cita su artículo por nombre. Así está parado cada punto en la 1.0.

Las cuatro críticas de Böckeler vs. Spec Kit 1.0

Sus observaciones originales siguen describiendo la experiencia por defecto. La diferencia es que 1.0 te da salidas documentadas para cada una.

Crítica (oct. 2025)	Qué cambió	Veredicto
Un workflow para todos los tamaños	Camino corto oficial, el preset lean y una extensión de bugs aparte	Mayormente resuelto
Demasiado markdown para revisar	El preset lean reduce cada fase a un archivo enfocado. Las plantillas por defecto siguen siendo extensas.	Parcialmente resuelto
Los agentes se saltan instrucciones	Converge compara el código con los artefactos y agrega lo que falta	Se detecta después, no se previene
Spec-first, no spec-anchored	Las branches son opt-in, y los docs nombran tres formas de mantener viva una spec	Documentado, no impuesto

Un workflow para todos los tamaños. Su ejemplo más filoso fue un bug fix chico que salió con user stories y dieciséis criterios de aceptación, incluido “como desarrollador, quiero que la función de transformación maneje los edge cases con elegancia”. Un mazo para romper una nuez. La respuesta de Spec Kit son tres salidas. El camino corto del quickstart elimina los gates opcionales. El preset lean (specify preset add lean, empaquetado, sin descarga) reemplaza las plantillas del core con prompts autocontenidos que producen un archivo enfocado por fase. Y los bugs tienen su propia extensión (specify extension add bug) con tres pasos, assess, fix y test, y sin ningún workflow de feature de SDD.

Volumen de markdown para revisar. Cada feature sigue produciendo spec, plan, research, data model, quickstart, contracts y tasks por defecto. Su punto sigue en pie: si revisar los artefactos toma lo mismo que escribir la feature a mano, los números no cierran. Lean es la solución, y tienes que elegirla.

Los agentes no siempre siguen todas las instrucciones. Más contexto en la ventana no equivale a más obediencia. Böckeler vio al agente tratar notas de investigación sobre clases existentes como especificaciones nuevas y regenerarlas como duplicados. Converge no evita que eso pase. Lo detecta después y lo convierte en tasks, que es la versión honesta de una solución.

Spec-first versus spec-anchored. Su pregunta era si una spec vive para una sola solicitud de cambio o para toda la vida de una feature. Spec Kit ahora la responde por escrito. Su documentación nombra tres modelos: Flow-Back (editas cualquier artefacto y reconcilias a mano), Flow-Forward (una carpeta de spec nueva por cambio, las viejas quedan como historial) y Living Spec (editas spec.md como el contrato y regeneras plan y tasks a partir de él). Ninguno es el default, y la herramienta no impone ninguno. Tu equipo elige uno y se queda con él.

Así que úsala en features de tamaño considerable, en código greenfield o brownfield bien conocido. Para trabajo exploratorio y tareas chicas, usa el camino corto, lean o la extensión de bugs, o sáltate Spec Kit por completo.

Spec Kit vs Kiro vs Claude Code con pi-sdd-kit

Tres setups de SDD se comparan más seguido. No son la misma herramienta con distinto nombre.

Spec Kit vs Kiro vs Claude Code con pi-sdd-kit

Alcances distintos, tradeoffs distintos. Spec Kit gana en variedad de agentes. Kiro gana en integración con sus propias herramientas. pi-sdd-kit agrega un gate de aprobación explícito y legible por máquina.

Característica	Spec Kit	Kiro	Claude Code + pi-sdd-kit
Workflow central	Pipeline de skills hasta converge, cualquier agente	Requirements, design, tasks, en las herramientas propias de Kiro	Slash commands de 5 fases en Claude Code
Capa de memoria estable	constitution.md	steering/ (product, tech, structure)	steering/ con 4 archivos de contexto
Gate de aprobación legible por máquina	Ninguno: --require-spec verifica que el archivo exista	Ninguno: una persona decide cuándo avanzar	Archivo .status con token explícito
Agentes compatibles	40+ integraciones vía specify init	Kiro IDE, CLI y web	Claude Code como principal
Artefactos por feature	7 por defecto; un archivo por fase con el preset lean	3 archivos: requirements, design, tasks	Carpeta por feature con gate .status
Personalización	Extensions, presets, workflows, bundles	Steering documents y hooks	Markdown plano, cualquier estructura
Costo	Gratis, licencia MIT	Plan gratis, planes pagos desde US$ 20/mes	Gratis, paquete npm open source

Esta es la opinión honesta de alguien que usa Claude Code y pi-sdd-kit como workflow diario.

Spec Kit es la mejor opción cuando trabajas con varios agentes, quieres un estándar open source mantenido por la comunidad con un ecosistema real alrededor, o trabajas en equipos donde cada dev usa una herramienta distinta. El enfoque basado en la constitution es realmente bueno para codificar restricciones de la organización, y converge es la mejor respuesta que cualquiera de estas herramientas tiene para el agente que da su propio trabajo por terminado.

Spec Kit encaja peor cuando quieres un gate legible por máquina que impida que el agente avance sin aprobación explícita. El token .status de pi-sdd-kit no es ceremonia: elimina la ambigüedad entre “escribí la spec” y “aprobé la spec”. Un tasks.md terminado y un tasks.md aprobado se ven idénticos para un agente que recorre el directorio. El --require-spec de Spec Kit ve lo mismo: un archivo que existe. La aprobación se queda en tu cabeza.

Con Kiro, la comparación es otra. Mira qué es Kiro para el panorama completo. La versión corta: el workflow de spec de Kiro vive dentro del propio IDE, CLI y app web de Kiro, mientras que Spec Kit se conecta al agente que ya usas. Los tres archivos de Kiro (requirements, design, tasks) también son más livianos que los siete por defecto de Spec Kit, que es el hueco que cierra el preset lean.

Cuándo un trabajo merece Spec Kit

¿Este trabajo se beneficia de Spec Kit?

¿Este trabajo se beneficia de Spec Kit?. Winner: Proyecto greenfield with a weighted score of 50. Scale 1-5 (5 = best).

Criterio (peso)	Script de una vez	Bug fix pequeño	Feature de varias sesiones	Proyecto greenfield
Dura más que una sentada (3)	1	1	4	5
Abarca varias sesiones o personas del equipo (3)	1	2	4	5
Requiere decisiones de arquitectura (2)	1	1	4	5
Se beneficia de un documento de spec vivo (2)	1	1	3	5
Puntuación ponderada	10	13	38	50

Scale 1-5 (5 = best). Highlighted column: winner by weighted score.

El pipeline completo tiene un overhead real, y ese overhead no es proporcional para trabajo chico. La propia documentación de la herramienta ahora lo reconoce, con el camino corto y el proceso de bugs como puntos de entrada separados. No corras nueve pasos para un bug fix.

Usa el pipeline en features donde el costo de construir lo equivocado supera el costo de la spec. Úsalo en proyectos greenfield donde quieres consistencia arquitectónica desde el inicio, llevada a cada feature. Úsalo en equipos que quieren artefactos de spec compartidos en el control de versiones, como fuente de verdad entre devs.

Extensions, presets, workflows, bundles

La personalización es donde más creció la 1.0. Ahora hay cuatro mecanismos.

Las extensions suman capacidades: comandos nuevos, fases nuevas, integraciones con herramientas como Jira o GitHub. Varias vienen empaquetadas con la CLI y solo necesitan specify extension add: git (feature branches), agent-context (tu sección de CLAUDE.md o AGENTS.md), bug, assess y github. Los presets cambian cómo se comportan los comandos existentes, sobrescribiendo sus plantillas. Lean es el empaquetado que vale la pena conocer. Los workflows automatizan procesos de varios pasos en YAML, con loops, fan-out y pausa y reanudación. Los bundles empaquetan un conjunto curado de extensions, presets y workflows para un rol, como un product manager o un security researcher, instalado de una sola vez.

Los catálogos de la comunidad viven dentro del propio repo de Spec Kit, con más de 130 extensions de la comunidad hechas por más de 70 autores, que se buscan con specify extension search y specify preset search. El orden de resolución está documentado y es estable: los overrides locales del proyecto ganan sobre los presets, los presets ganan sobre las extensions, las extensions ganan sobre las plantillas del core.

Lo importante es el método, no la herramienta

Spec Kit es una implementación de spec-driven development. El método existe con independencia de cualquier herramienta. Puedes hacer SDD con archivos markdown planos, sin CLI, sin skills, y aun así obtener el beneficio. El método es: escribir y aprobar una spec antes de que empiece la implementación, mantener la spec como fuente de verdad y usar gates claros para que el agente no se adelante.

Lo que Spec Kit te da encima de eso es consistencia, una comunidad y el ecosistema más grande del espacio. La plantilla de constitution está bien diseñada. La separación entre spec funcional y plan técnico es clara y las plantillas la hacen cumplir. Converge cierra el loop que la mayoría deja abierto. Y las integraciones resuelven las diferencias de formato entre más de cuarenta agentes.

Si usas Claude Code, el enfoque que armé construyendo yo solo una fintech cripto de 13 apps en 70 días está en Spec-driven development con Claude Code. El enfoque de pi-sdd-kit agrega el gate .status y el sistema de contexto en tres capas (CLAUDE.md, steering, specs), que le dan al agente memoria duradera y una señal de aprobación explícita y legible por máquina. Estos enfoques resuelven partes contiguas del mismo problema. Puedes tomar ideas de los dos.

FAQ

¿Qué es GitHub Spec Kit?+

GitHub Spec Kit es un toolkit open source publicado por GitHub bajo licencia MIT. Les da a los agentes de IA para código procesos estructurados, plantillas y resultados documentados. Instalas la CLI specify, ejecutas specify init, y tu agente obtiene un pipeline de skills para spec-driven development: constitution, specify, clarify, plan, checklist, tasks, analyze, implement y converge.

Desde la 1.0 también ofrece bug fixing y evaluación de ideas como extensions opcionales. Funciona con más de 40 agentes, incluidos Claude Code, GitHub Copilot, Gemini CLI, Cursor y Codex.

¿Qué hay de nuevo en Spec Kit 1.0?+

Menos de lo que sugiere el número de versión. La 1.0.0 salió en agosto de 2026 sin breaking changes; los cambios grandes llegaron en los releases anteriores. Los que importan: el paso converge, skills como la forma de invocación por defecto, carpetas de feature en specs/ en la raíz del repo, las branches de git movidas a una extensión opt-in, el archivo de contexto del agente movido a una extensión opt-in, y extensions empaquetadas para bug fixing y evaluación de ideas.

Después de la 1.0: --require-spec para analyze y converge, bundles que empaquetan el setup de un rol en una sola instalación, y una extensión github que va tomando el lugar de taskstoissues.

¿Qué hace /speckit-converge?+

Corre después de implement y compara la codebase con la spec, el plan, las tasks y la constitution. Cada hueco se clasifica como missing, partial, contradicts o unrequested, y se agrega a tasks.md como una nueva fase de convergencia. Nunca reescribe tus artefactos existentes.

Repites implement y converge hasta que reporta que convergió, momento en el que tasks.md queda sin cambios. Detecta lo que el agente dejó afuera, después del hecho. No evita que el agente lo deje afuera.

¿Hay una forma más liviana de usar Spec Kit para cambios chicos?+

Sí, tres. El camino corto oficial solo corre specify, plan, tasks, implement y converge. El preset lean empaquetado (specify preset add lean) reemplaza las plantillas del core con prompts autocontenidos que producen un archivo enfocado por fase. Y los bugs tienen su propia extensión (specify extension add bug) con assess, fix y test, y sin ningún workflow de feature de SDD.

¿Spec Kit es gratis?+

Sí. Spec Kit se publica bajo licencia MIT. No hay plan pago, suscripción ni límite de uso. La CLI specify se instala desde PyPI con uv, pipx o pip.

¿Cómo instalo Spec Kit?+

Instala uv (https://docs.astral.sh/uv/), y después ejecuta: uv tool install specify-cli. Para fijar un release, usa uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z. Después inicializa tu proyecto con specify init my-project --integration claude para Claude Code, o --integration copilot para GitHub Copilot.

Para probarlo una vez sin instalar: uvx --from git+https://github.com/github/spec-kit.git specify init my-project. Para actualizar después: specify self upgrade.

¿Spec Kit funciona con Claude Code, Cursor y Copilot?+

Sí. Spec Kit lista 42 integraciones, incluidas Claude Code, GitHub Copilot, Gemini CLI, Cursor, OpenAI Codex, Kiro CLI y Goose. Para Claude Code instala skills en .claude/skills. Copilot también usa modo skills por defecto.

Ejecuta specify integration list para ver todas las integraciones de tu versión instalada. Un proyecto puede tener más de una.

Spec Kit vs Kiro: ¿cuál elijo?+

Spec Kit se conecta al agente que ya usas, con más de 40 integraciones y un ecosistema grande de extensions y presets. Kiro es el entorno propio de AWS (IDE, CLI y web) con un workflow de spec más liviano de tres archivos (requirements, design, tasks) integrado.

Si quieres flexibilidad de agente y un estándar abierto que cualquier persona del equipo pueda usar con su propia herramienta, usa Spec Kit. Si quieres el workflow de spec integrado en el entorno y no te molesta trabajar en las herramientas de Kiro, lee la guía dedicada a Kiro. La lógica del workflow es parecida. Los entornos son muy distintos.

¿Qué crea realmente specify init?+

Un directorio .specify con memory/ (para la constitution), scripts/ y templates/, además de los skills o comandos para tu agente, como .claude/skills para Claude Code. No edita CLAUDE.md ni AGENTS.md a menos que agregues la extensión agent-context.

Las carpetas de feature las crea después /speckit-specify, bajo specs/ en la raíz del repo (specs/001-feature-name/). El archivo .specify/feature.json apunta a la feature activa, así que Spec Kit ya no depende de tu branch de git.

¿Cuáles son las principales debilidades de Spec Kit?+

Tres que conviene conocer. Primero, no hay gate de aprobación: --require-spec verifica que spec.md exista, no que alguien lo haya aprobado, así que avanzar entre fases sigue siendo tu disciplina. Segundo, el volumen de artefactos por defecto es alto (siete archivos por feature) a menos que elijas el preset lean. Tercero, converge detecta lo que el agente dejó afuera, pero después del hecho; no lo previene.

El análisis de octubre de 2025 de Birgitta Böckeler en martinfowler.com sigue siendo la mejor evaluación independiente, y la propia documentación de Spec Kit sobre persistencia de specs ahora le responde.