luismori.

AI Coding Workflows

Spec Kit Cursor Claude Code

GitHub Spec Kit: cómo empezar con Cursor o Claude Code

Una guía sencilla y respaldada por fuentes para que ingenieros y PMs comiencen con GitHub Spec Kit, entiendan los comandos principales y usen el flujo de trabajo de forma ordenada en Cursor o Claude Code.

23 min de lectura Actualizado el 15 abr 2026

Si acabas de escuchar sobre GitHub Spec Kit, la explicación más breve es esta:

le da estructura a tu flujo de trabajo de programación con IA.

En lugar de pasar directamente de un prompt impreciso a un diff de código enorme, avanzas por una secuencia:

  1. principios del proyecto
  2. especificación de la funcionalidad
  3. aclaración
  4. plan técnico
  5. desglose de tareas
  6. implementación

Parece sencillo, pero cambia el ritmo de trabajo tanto para ingenieros como para PMs.

  • Los PMs obtienen algo que pueden revisar antes de que comience la implementación.
  • Los ingenieros obtienen requisitos más claros, límites mejor definidos y menos ciclos de «espera, ¿qué estamos construyendo exactamente?».
  • Las herramientas de IA obtienen un contrato mucho mejor que un solo prompt enorme.

El April 15, 2026, volví a contrastar este artículo con el README y la documentación de GitHub Spec Kit, la documentación del producto y el registro de cambios de Cursor, y la documentación de Claude Code vigentes en ese momento. Una nota importante antes de empezar:

  • los comandos y el flujo de artefactos están respaldados por las fuentes
  • el modelo de trabajo práctico de este artículo es mi síntesis para equipos reales que usan Cursor o Claude Code

En resumen

  • GitHub Spec Kit es un flujo de trabajo estructurado que parte de especificaciones para desarrollar software con asistencia de IA.
  • La distinción para empezar es sencilla:
    • usa los comandos specify ... en tu terminal para instalar y verificar el kit de herramientas
    • usa los comandos /speckit.* dentro del chat de tu asistente de IA para dirigir el flujo de trabajo de la funcionalidad
  • Un flujo ordenado para principiantes es:
    1. specify init --here --ai cursor-agent o specify init --here --ai claude
    2. specify check
    3. crea una rama de funcionalidad como 001-saved-dashboard-views
    4. ejecuta /speckit.constitution
    5. ejecuta /speckit.specify
    6. ejecuta /speckit.clarify
    7. ejecuta /speckit.plan
    8. ejecuta /speckit.tasks
    9. opcionalmente, ejecuta /speckit.checklist, /speckit.analyze y /speckit.taskstoissues
    10. ejecuta /speckit.implement
  • Cursor destaca especialmente en ciclos de planificación y exploración intensiva con worktrees.
  • Claude Code destaca especialmente cuando prefieres trabajar principalmente desde la terminal o quieres iniciar tareas de ejecución más largas, incluso desde la web.
  • Spec Kit no es solo para funcionalidades nuevas. También es útil para:
    • aplicar ingeniería inversa a funcionalidades existentes
    • migrar de especificación a especificación desde una aplicación legacy a una más reciente
    • revisar PRs con la planificación como punto de partida
    • coordinar trabajo en múltiples repositorios

Para quién es este artículo

Este artículo está escrito para que resulte claro tanto para ingenieros como para PMs.

Si eres PM, piensa en Spec Kit como una forma de convertir «lo que queremos» en un conjunto de artefactos revisables antes de que la implementación se desvíe.

Si eres ingeniero, piensa en él como un flujo de trabajo que te ayuda a separar:

  • qué debe hacer la funcionalidad
  • qué necesita aclararse todavía
  • cómo planeas construirla
  • en qué orden debe hacerse el trabajo

Qué te ofrece realmente Spec Kit

La documentación oficial describe Spec-Driven Development como un proceso en el que las especificaciones se convierten en artefactos activos del desarrollo, en lugar de notas de planificación desechables.

Esto importa porque la mayoría de los fallos al programar con IA no son realmente «fallos del modelo». Por lo general, son fallos del flujo de trabajo:

  • el prompt mezcló la intención del producto con decisiones sobre el stack demasiado pronto
  • los criterios de aceptación nunca se hicieron explícitos
  • la implementación avanzó antes de resolver las preguntas pendientes
  • las tareas nunca se descompusieron de forma clara

Spec Kit te da una estructura repetible para evitarlo.

El modelo mental sencillo

Esta es la forma más fácil de entender el flujo de trabajo:

idea
  -> constitution
  -> feature spec
  -> clarification
  -> technical plan
  -> task breakdown
  -> implementation

Y este es el detalle práctico importante de la guía de inicio rápido oficial:

  • los comandos de Spec Kit detectan la funcionalidad activa a partir de tu rama actual de Git

Así que, si estás en una rama como:

001-saved-dashboard-views

Spec Kit la trata como el contexto de la funcionalidad actual.

Esa es una de las razones por las que el flujo de trabajo se siente natural en los equipos de ingeniería.

Por dónde empezar: ¿Cursor o Claude Code?

Puedes usar el mismo flujo de Spec Kit con ambas herramientas. La diferencia está principalmente en los puntos fuertes de cada una.

Cursor es una excelente interfaz para la planificación

Los materiales actuales de Cursor respaldan bien un flujo de trabajo centrado en la planificación:

  • Plan Mode puede investigar el código del repositorio, crear un plan y guardarlo como Markdown
  • Cursor 3 puede ejecutar agentes en paralelo entre repositorios y entornos
  • Cursor 3 también agregó un comando /worktree para que el trabajo aislado se realice en worktrees de Git separados

Si a tu equipo le gusta un flujo de trabajo integrado al IDE, Cursor es un lugar muy cómodo para dirigir los comandos /speckit.*.

Claude Code es una excelente interfaz para la ejecución y el trabajo desde la terminal

Claude Code encaja especialmente bien cuando quieres:

  • un flujo de trabajo centrado en la terminal
  • acceso explícito a la shell
  • una ejecución sólida dentro del repositorio local
  • la opción de pasar a Claude Code en la web para tareas ejecutadas en la nube

La documentación de Anthropic ahora establece una distinción clara:

  • Remote Control mantiene la sesión en ejecución en tu máquina
  • Claude Code en la web se ejecuta en infraestructura de nube administrada por Anthropic

Esto permite un patrón útil:

  • planificar localmente en Cursor o Claude Code
  • ejecutar partes acotadas de la implementación en Claude Code en la web

Paso 1: instala Spec Kit

La guía de instalación oficial recomienda usar el paquete de Spec Kit alojado en GitHub, no paquetes de PyPI que no están relacionados pero tienen un nombre similar.

Para el uso cotidiano, recomiendo una instalación permanente:

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

Si prefieres una configuración inicial de una sola ejecución:

uvx --from git+https://github.com/github/spec-kit.git@vX.Y.Z specify init <PROJECT_NAME>

Paso 2: inicializa el repositorio para tu asistente

Si quieres trabajar en Cursor:

specify init --here --ai cursor-agent

Si quieres trabajar en Claude Code:

specify init --here --ai claude

Si estás incorporando Spec Kit a un repositorio existente, la documentación admite explícitamente inicializarlo en el directorio actual con . o --here.

Qué proporcionas como entrada

  • el directorio del repositorio
  • el asistente de IA elegido mediante --ai
  • opcionalmente, --here, --force, --script o --branch-numbering

Qué debes esperar como salida

  • una carpeta .specify/ con plantillas, scripts y archivos de memoria
  • la configuración de comandos o habilidades específica del agente
  • la posibilidad de ejecutar comandos /speckit.* desde el asistente

Por ejemplo, el README del proyecto muestra una estructura como esta después de la configuración inicial:

.specify/
  memory/
    constitution.md
  scripts/
  specs/
    001-create-taskify/
      spec.md
  templates/

Paso 3: verifica la instalación

Ejecuta:

specify check
specify version

specify check

Entrada

  • tu entorno local
  • herramientas instaladas como git y la CLI del agente de IA que elegiste

Salida

  • una comprobación que indica si las herramientas necesarias están disponibles

specify version

Entrada

  • ninguna, aparte de la CLI instalada

Salida

  • la versión actual de Spec Kit para que puedas confirmar que usas la compilación esperada

Paso 4: comienza en una rama de funcionalidad

La guía de inicio rápido deja muy claro que Spec Kit usa tu rama actual de Git como contexto de la funcionalidad.

Por eso, antes de empezar a trabajar en una funcionalidad, crea una rama:

git switch -c 001-saved-dashboard-views

Durante el resto del artículo, usaré un ejemplo sencillo:

Agregar vistas guardadas de dashboards a un producto de analítica.

La idea de la funcionalidad es lo bastante pequeña para entenderla, pero lo suficientemente realista para que PMs e ingenieros colaboren:

  • los usuarios pueden guardar una vista filtrada de un dashboard
  • pueden cambiarle el nombre o eliminarla
  • una vista guardada puede compartirse opcionalmente con su equipo
  • las vistas predeterminadas y personalizadas necesitan permisos claros

Las dos familias de comandos

Esta es la parte que confunde a la mayoría de las personas al principio.

1. Comandos de terminal: specify ...

Se usan para:

  • la instalación
  • las comprobaciones del entorno
  • la personalización del proyecto

2. Comandos del asistente: /speckit.*

Se usan para:

  • la planificación
  • la aclaración
  • el diseño técnico
  • la generación de tareas
  • la implementación

Si solo recuerdas una frase de esta sección, que sea esta:

specify prepara el flujo de trabajo y /speckit.* lo ejecuta.

Guía comando por comando

A continuación encontrarás un mapa sencillo y práctico de los principales comandos de Spec Kit.

Comandos de configuración inicial

specify init

Este es el primer comando que ejecutas.

Qué le proporcionas

  • una ruta de proyecto o --here
  • el asistente elegido, por ejemplo --ai cursor-agent o --ai claude
  • flags opcionales de configuración como --force, --script o --branch-numbering

Qué recibes

  • la estructura inicial del proyecto de Spec Kit
  • plantillas y scripts
  • integración con el agente para el flujo de comandos con barra

Ejemplo

specify init --here --ai cursor-agent

O:

specify init --here --ai claude

specify check

Úsalo justo después de la inicialización.

Qué le proporcionas

  • el estado actual de tu máquina

Qué recibes

  • confirmación de que están presentes las herramientas necesarias, como git y las herramientas del asistente elegido

Ejemplo

specify check

specify version

Úsalo cuando quieras verificar la versión instalada.

Qué le proporcionas

  • nada

Qué recibes

  • la cadena de versión instalada de Spec Kit

Ejemplo

specify version

specify extension

Normalmente no es un comando del primer día, pero cobra importancia más adelante.

Qué le proporcionas

  • una acción de gestión de extensiones
  • la extensión que quieres agregar, actualizar o administrar

Qué recibes

  • funcionalidades proporcionadas por extensiones, agregadas o actualizadas

La referencia oficial de la CLI incluye este comando, pero la guía de inicio rápido básica no ofrece un ejemplo completo para principiantes. Por eso lo trato como un comando de personalización, no como uno para desarrollar funcionalidades desde el primer día.

specify preset

Se usa para administrar configuraciones predefinidas.

Qué le proporcionas

  • una acción sobre configuraciones predefinidas
  • la configuración predefinida que quieres usar o administrar

Qué recibes

  • una capa personalizada de plantillas a nivel de proyecto sobre el comportamiento básico de Spec Kit

specify integration

Se usa para administrar integraciones.

Qué le proporcionas

  • una acción de integración
  • el destino de la integración

Qué recibes

  • soporte de integración configurado para el proyecto

Al igual que extension y preset, este es un comando de administración de la plataforma, no uno para desarrollar tu primera funcionalidad.

Comandos del flujo de trabajo

Ahora llegamos a los comandos a los que la mayoría se refiere cuando habla de «comandos de Spec Kit».

/speckit.constitution

Este comando establece los principios del proyecto que las especificaciones y los planes posteriores deben respetar.

Qué debes proporcionar

  • reglas permanentes del proyecto
  • restricciones del equipo
  • principios de ingeniería
  • restricciones de producto o de cumplimiento que deban orientar las funcionalidades futuras

Qué no debes proporcionar

  • un montón de detalles temporales de implementación para una sola funcionalidad

Qué produce

  • una constitución del proyecto, normalmente almacenada en .specify/memory/constitution.md

Ejemplo sencillo

/speckit.constitution
This product is audit-first and reliability-first.
All user-visible state changes must be attributable.
We prefer small reversible changes over large migrations.
All new features must include acceptance criteria and monitoring expectations.

Por qué importa

Este es el comando que evita que las respuestas posteriores de la IA se desvíen hacia «lo que parezca más conveniente».

Para repositorios existentes, recomiendo firmemente derivar esto de la evidencia del repositorio, no de lemas aspiracionales. Lo expliqué con más detalle en mi artículo complementario sobre cómo integrar GitHub Spec Kit en repositorios existentes con Cursor.

/speckit.specify

Aquí describes la funcionalidad en términos de negocio y de usuario.

Qué debes proporcionar

  • lo que necesitan los usuarios
  • por qué importa
  • los resultados deseados
  • los límites clave de aceptación

Qué debes evitar aquí

  • decisiones detalladas sobre el stack
  • arquitectura de implementación
  • esquemas de tablas
  • argumentos sobre frameworks

Qué produce

  • un nuevo directorio de especificación de la funcionalidad en la rama activa
  • un archivo spec.md con historias de usuario y requisitos funcionales

Ejemplo sencillo

/speckit.specify
Add saved dashboard views for analysts and managers.
Users should be able to save the current filters and layout as a named view,
load a saved view later, rename it, delete it, and optionally share it with
their team. Shared views should respect team boundaries and role permissions.

Estructura esperada de la salida

.specify/specs/001-saved-dashboard-views/spec.md

O, según las convenciones de organización del proyecto, el directorio equivalente de especificación de la funcionalidad para la rama activa.

/speckit.clarify

Este comando sirve para eliminar ambigüedades.

El README lo describe como una revisión estructurada de aclaración que registra las respuestas en una sección Clarifications.

Qué debes proporcionar

  • áreas poco claras
  • disyuntivas que necesitan una decisión explícita
  • preguntas sobre despliegue, seguridad, permisos, comportamiento ante fallos o retención de datos

Qué produce

  • respuestas aclaratorias registradas en el conjunto de artefactos de la especificación
  • una definición de la funcionalidad más precisa y menos ambigua antes de la planificación

Ejemplo sencillo

/speckit.clarify
Focus on team-sharing permissions, rename/delete permissions, default-view behavior,
and how private views behave when a user changes teams.

Por qué importa

Aquí mejora considerablemente la alineación entre producto e ingeniería. En lugar de discutir demasiado tarde durante la implementación, haces visibles las preguntas pendientes antes de que el plan técnico quede definido.

/speckit.checklist

La mejor forma de entender este comando es como una ayuda para revisar la calidad.

La descripción oficial lo presenta como una forma de generar listas de verificación de calidad que validan la integridad, claridad y coherencia de los requisitos.

Qué debes proporcionar

  • normalmente, el contexto de la especificación actual
  • opcionalmente, el aspecto de calidad que quieres validar

Qué produce

  • un artefacto de validación en forma de lista de verificación o un recurso de revisión para la especificación actual

Ejemplo sencillo

/speckit.checklist
Generate a checklist for requirement clarity, edge-case completeness, and
review readiness for PM and engineering signoff.

Interpretación práctica

Pienso en esto como «pruebas unitarias para el texto antes de escribir el código».

/speckit.plan

Aquí pasas del qué al cómo.

Qué debes proporcionar

  • el stack elegido
  • las restricciones de arquitectura
  • los supuestos sobre el entorno de ejecución
  • las decisiones de almacenamiento de datos
  • los puntos de integración

Qué produce

  • plan.md
  • documentos complementarios con detalles de implementación, como research.md, quickstart.md, data-model.md y contracts/*, según la funcionalidad

El README muestra un árbol de salida como este:

specs/001-create-taskify/
  contracts/
    api-spec.json
    signalr-spec.md
  data-model.md
  plan.md
  quickstart.md
  research.md
  spec.md

Ejemplo sencillo

/speckit.plan
Use Next.js for the web application, Postgres for persistence, and a simple
REST API. Saved views should support private and team-shared visibility.
Track ownership, sharing scope, created_at, updated_at, and last_used_at.

Por qué importa

Este es el punto de transición entre la intención del producto y el diseño técnico.

/speckit.tasks

Este comando convierte el plan en trabajo ejecutable.

El README es especialmente concreto en este punto. Indica que el tasks.md generado incluye:

  • desglose de tareas por historia de usuario
  • orden de dependencias
  • marcadores de paralelismo como [P]
  • rutas exactas de archivos
  • secuenciación de tareas compatible con TDD cuando se solicita
  • puntos de control para validación independiente

Qué debes proporcionar

  • normalmente, nada más que el conjunto actual de artefactos
  • opcionalmente, una solicitud para hacer énfasis en la secuenciación o las pruebas

Qué produce

  • tasks.md para la funcionalidad activa

Ejemplo sencillo

/speckit.tasks

Salida esperada

specs/001-saved-dashboard-views/tasks.md

Este es el artefacto que hace mucho más segura la implementación en paralelo.

/speckit.analyze

Esta es la revisión cruzada de los artefactos.

La descripción oficial del comando lo presenta como un análisis de coherencia y cobertura entre artefactos, y el README recomienda ejecutarlo después de /speckit.tasks y antes de /speckit.implement.

Qué debes proporcionar

  • normalmente, el conjunto actual de artefactos
  • opcionalmente, una solicitud para enfocarse en riesgos, dependencias faltantes o contradicciones

Qué produce

  • un análisis que destaca vacíos, inconsistencias o falta de cobertura entre la especificación, el plan y las tareas

Ejemplo sencillo

/speckit.analyze
Look for mismatches between permission rules in the spec, the data model,
and the task breakdown.

Por qué importa

Este comando detecta situaciones como «el plan suena bien, pero ya no coincide con la funcionalidad que acordamos».

/speckit.taskstoissues

Este es el puente entre los artefactos de planificación y el seguimiento de issues en GitHub.

La descripción oficial es concisa: convierte las listas de tareas generadas en issues de GitHub para su seguimiento y ejecución.

Qué debes proporcionar

  • un tasks.md completo
  • acceso al repositorio de GitHub y al flujo de seguimiento correspondientes

Qué produce

  • issues de GitHub o artefactos de seguimiento listos para convertirse en issues, derivados de la lista de tareas

Ejemplo sencillo

/speckit.taskstoissues

Nota importante

El propósito general del comando está documentado claramente, pero la guía de inicio rápido no ofrece aquí el mismo recorrido detallado que para plan, tasks e implement. Por eso lo considero un comando puente muy útil, pero no uno que obligaría a incluir en todos los flujos para principiantes desde el primer día.

/speckit.implement

Esta es la fase de ejecución.

El README indica que este comando:

  • valida los requisitos previos
  • analiza tasks.md
  • ejecuta las tareas en orden
  • respeta las dependencias y los marcadores de paralelismo
  • sigue la estructura de TDD definida en el plan de tareas
  • proporciona actualizaciones de progreso y maneja errores

Qué debes proporcionar

  • un conjunto completo de artefactos
  • un entorno local lo suficientemente limpio para ejecutar las herramientas necesarias

Qué produce

  • trabajo de implementación real en el repositorio
  • actualizaciones de progreso mientras el asistente ejecuta el plan

Ejemplo sencillo

/speckit.implement
Implement the feature in thin slices and stop to report if the permission model
requires a schema or API decision not covered in the current plan.

Nota importante

Este no es solo un paso de generación de texto. Puede ejecutar comandos locales reales, por lo que tu entorno necesita los runtimes de lenguaje y las herramientas que espera la implementación.

Un flujo sencillo de principio a fin para principiantes

Si solo quieres un camino ordenado para empezar, yo usaría este:

En Cursor

specify init --here --ai cursor-agent
specify check
git switch -c 001-saved-dashboard-views

Luego, en el chat de Cursor:

/speckit.constitution
Our product is reliability-first and audit-first.
All user-visible changes need acceptance criteria.
We prefer incremental delivery.
/speckit.specify
Add saved dashboard views so users can preserve filters and layout, return to
them later, and optionally share them with their team.
/speckit.clarify
Focus on permissions, shared-view ownership, and default-view behavior.
/speckit.plan
Use the existing Next.js app and Postgres database. Prefer small API changes,
clear ownership rules, and reversible rollout.
/speckit.tasks
/speckit.analyze
/speckit.implement

En Claude Code

El mismo flujo funciona usando Claude Code como interfaz de chat:

specify init --here --ai claude
specify check
git switch -c 001-saved-dashboard-views
claude

Luego ejecuta la misma secuencia de /speckit.* dentro de Claude Code.

Si te gusta un flujo híbrido, un patrón sólido es:

  1. hacer constitution, specify, clarify y, a veces, plan en Cursor
  2. validar y ejecutar tasks, analyze e implement en Claude Code

No es un patrón obligatorio. Es simplemente una opción práctica.

¿Qué archivos debes esperar a medida que avanzas?

Este es el modelo mental más sencillo:

.specify/
  memory/
    constitution.md
  specs/
    001-saved-dashboard-views/
      spec.md
      plan.md
      tasks.md
      research.md
      quickstart.md
      data-model.md
      contracts/

No todas las funcionalidades generarán todos los archivos complementarios de la misma manera, pero esta es la estructura general documentada en los ejemplos del proyecto.

¿Qué más puedes hacer con Spec Kit?

Aquí es donde Spec Kit se vuelve más interesante que un tutorial para principiantes.

1. Aplicar ingeniería inversa a una funcionalidad existente

No tienes que empezar desde cero.

Uno de los usos más valiosos en proyectos existentes es:

  • elegir una funcionalidad existente
  • reunir evidencia del código, las pruebas, las rutas y la interfaz
  • reconstruir los archivos spec.md, plan.md y tasks.md del estado actual

Escribí una guía completa sobre eso aquí:

Esto es especialmente útil para:

  • la incorporación de nuevos integrantes
  • refactors más seguros
  • la alineación entre producto e ingeniería sobre el comportamiento legacy

2. Migrar de especificación a especificación desde una aplicación legacy a una más reciente

Este es uno de mis casos de uso modernos favoritos.

En lugar de copiar el código antiguo directamente a un stack nuevo, puedes:

  1. aplicar ingeniería inversa a la funcionalidad antigua para crear especificaciones del estado actual
  2. tratar esas especificaciones como un contrato de comportamiento
  3. escribir un nuevo plan del estado objetivo en la nueva aplicación
  4. implementar partes con paridad funcional en lugar de copiar la estructura legacy

Lo expliqué en profundidad aquí:

Para muchos equipos, ese es un camino de modernización más seguro que comenzar directamente trasladando el código.

3. Usar Spec Kit como eje de planificación para el desarrollo en paralelo

Una vez que tienes tasks.md, puedes dividir el trabajo de forma más segura entre:

  • worktrees
  • agentes de IA
  • integrantes del equipo
  • PRs separados

Es ahí donde Spec Kit se convierte en algo más que documentación. Se convierte en el contrato de planificación para la ejecución en paralelo.

Lectura relacionada:

4. Usarlo en entornos existentes o con múltiples repositorios

Spec Kit no es solo para un monorepositorio nuevo y limpio.

Una configuración práctica para trabajar con múltiples repositorios suele incluir:

  • una ubicación canónica para las especificaciones
  • un identificador de funcionalidad compartido
  • una línea de implementación específica por repositorio

Escribí más sobre eso aquí:

5. Asignar diferentes fases a diferentes modelos o herramientas

No todas las fases se benefician de la misma herramienta o modelo.

Una división práctica puede ser:

  • redacción y aclaración más rápidas en Cursor
  • validación o ejecución más profunda en Claude Code
  • diferentes modelos para specify, plan e implement

Exploré ese enfoque aquí:

Patrones de uso modernos que recomiendo

Estas no son reglas oficiales. Son los patrones que considero más sólidos.

Producto escribe el «por qué» e ingeniería escribe el «cómo»

Da protagonismo a:

  • los aportes de producto en /speckit.specify
  • el liderazgo de ingeniería en /speckit.plan

Esto mantiene la especificación enfocada y el plan bien fundamentado.

Trata /speckit.clarify como una etapa real de revisión

No pases por ella con prisa.

A menudo, aquí es donde los malentendidos más costosos todavía son baratos de corregir.

Mantén el PR de planificación separado del PR de implementación cuando la funcionalidad sea grande

Para funcionalidades más grandes, prefiero:

  1. PR 1 para constitución/especificación/plan/tareas
  2. PR 2 en adelante para partes de la implementación

No es obligatorio, pero mejora mucho la calidad de la revisión.

Usa SPECIFY_FEATURE solo cuando realmente necesites reemplazar la detección basada en ramas

La referencia de la CLI documenta SPECIFY_FEATURE para flujos de trabajo sin Git o situaciones inusuales. La mayoría de los equipos debería confiar en el comportamiento predeterminado basado en la rama, salvo que tenga una razón de peso para no hacerlo.

Errores comunes

Estos son los errores de principiantes que veo con más frecuencia:

Incluir el stack en /speckit.specify

Eso debilita la separación entre intención y diseño.

Omitir /speckit.clarify

Ahorras cinco minutos y a menudo pierdes mucho más después.

Tratar el primer plan generado como definitivo

Debes revisar y refinar el plan.

Pasar a /speckit.implement antes de que tasks.md sea confiable

Spec Kit funciona mejor cuando el desglose de tareas es lo suficientemente bueno para guiar la ejecución.

Intentar usar una especificación enorme para todo un subsistema

El flujo de trabajo suele funcionar mejor cuando delimitas una funcionalidad a la vez.

Conclusión

Si eres nuevo en GitHub Spec Kit, no compliques demasiado la primera ejecución.

Empieza con una funcionalidad, en una rama, con una secuencia clara de /speckit.*.

Luego, cuando eso te resulte natural, amplía el uso hacia patrones más avanzados:

  • ingeniería inversa en proyectos existentes
  • planificación de migraciones
  • desarrollo en paralelo
  • flujos de trabajo con varias herramientas entre Cursor y Claude Code

El valor real de Spec Kit no es que cree más archivos.

El valor real es que les da a los ingenieros, PMs y herramientas de IA el mismo conjunto de artefactos de trabajo antes de que la implementación comience a desviarse.

Lista de fuentes

Validado con estas fuentes el April 15, 2026.

Fuentes oficiales

Artículos complementarios en este repositorio