Comando Plan: de la Spec al código

El comando Plan de Spec Kit convierte tus especificaciones en un plan técnico concreto, sin escribir una sola línea de código. Si trabajas con desarrollo asistido por IA y quieres estructurar tu proyecto antes de programar, aquí verás cómo funciona ese puente entre las ideas y el código.

La idea central es simple: la especificación responde el qué y el plan responde el cómo. Y ese salto es justo lo que necesitas para que una inteligencia artificial pueda construir tu aplicación sin improvisar.

Qué hace el comando Plan y por qué importa

El comando Plan lee dos archivos clave: la Constitución y la especificación. Con esa información genera el plan de trabajo completo del proyecto [00:09].

Piénsalo así: ya tenías definidas las funcionalidades y las historias de usuario, pero eso vive en el mundo del negocio. El plan traduce todo eso al mundo técnico. Es el puente que une ambos lados.

¿Para qué sirve el comando Plan en Spec Kit? Lee la Constitución y la especificación del proyecto y genera un plan de trabajo técnico. Responde el cómo se construirá lo que la especificación ya definió como el qué.

Y aquí viene lo interesante: hasta este punto no has escrito ni una sola línea de código, pero tu proyecto ya queda más estructurado que el 90 % de las aplicaciones creadas con vibe coding [03:36].

Cómo se ejecuta el comando Plan paso a paso

Antes de correr el comando conviene ordenar tu trabajo con Git. El flujo respeta una práctica que se repite en cada comando: trackear los cambios y crear una rama nueva.

Estos son los pasos que sigues desde la raíz del proyecto:

1. Verifica en qué rama estás; en este caso, la rama Clarify del comando anterior [00:52].
2. Guarda los cambios con git add y confírmalos con git commit usando un mensaje como "clarificación de Spec" [01:03].
3. Crea la nueva rama con git checkout -b plan, que además te posiciona en ella [01:19].
4. Abre Cloud Code y ejecuta el comando plan de Spec Kit [01:29].

Tras darle enter, Cloud Code recorre el archivo de Constitución y el Spec.md, define cada funcionalidad y arma el plan completo en pocos segundos [01:39].

Qué artefactos genera el comando Plan

El comando no entrega un solo archivo. Produce varios artefactos que cubren distintas capas del proyecto:

• Plan.md: contiene el contexto técnico, el chequeo de la Constitución y la estructura del proyecto [01:58].
• Research.md: investiga funcionalidades y su mejor aplicabilidad, por ejemplo la autenticación o la verificación de reserva activa única [02:16].
• Modelo de datos: define qué es un usuario y qué es una cancha [02:32].
• Contrato de las APIs: establece cómo se comunican los componentes [02:33].
• Quickstart.md: indica cómo inicializar backend y frontend de la aplicación [02:34].

Cada archivo cumple un rol específico para que nada quede a la interpretación.

Qué encuentras dentro del archivo Plan.md

El Plan.md es el corazón de todo lo generado. Al abrirlo desde la carpeta Specs verás varias secciones que vale la pena revisar con calma [02:47].

Empieza con un resumen de lo que hace la aplicación y luego pasa al contexto técnico: los lenguajes de programación en uso, cómo se manejan las dependencias y cómo se realizará el testing [03:00].

Después llega una pieza fundamental, el Constitution Check. Aquí se valida que cada definición de tus especificaciones no viole lo que estableciste en la Constitución. El plan muestra el principio, la evaluación y el estado de cada uno, confirmando que todas pasaron [03:11].

¿Qué es el Constitution Check en Spec Kit? Es una validación automática que revisa que tus especificaciones no rompan las reglas definidas en la Constitución del proyecto. Muestra cada principio, su evaluación y su estado.

Al final del archivo aparece la estructura del proyecto: el plan, el research, el modelo de datos, el Quickstart y el contrato de las APIs. También incluye la organización del repositorio dividido en subcarpetas para backend, frontend y base de datos [03:20].

Por qué el plan es el puente hacia las tareas

El objetivo real es llegar a tener tareas atomizadas que una inteligencia artificial pueda usar para crear cada componente de la aplicación [03:26].

Pero esas tareas no pueden salir directamente de las historias de usuario. Necesitas algo intermedio que conecte el negocio con lo técnico, y ese algo es precisamente el plan.

¿Por qué no crear tareas directo desde las especificaciones? Porque las especificaciones viven en el lenguaje del negocio. El plan traduce ese lenguaje a términos técnicos, y sobre esa base sí se pueden generar tareas atomizadas para la IA.

Con el plan listo, el siguiente paso será dividirlo en partes más pequeñas y crear las tareas concretas del proyecto. ¿Ya identificaste qué artefacto te resultaría más útil revisar primero en tu propio flujo? Cuéntalo en los comentarios.