Cómo convertir tu spec en prompt para Claude

Definir una spec con Spec Kit es lo que separa el picar código a ciegas de dirigir un proyecto de software con intención. Aquí aprendes a versionar tu proyecto con Git y a convertir tus especificaciones en un prompt que Claude Code transforma en una estructura completa. Es ideal para quien está dando sus primeros pasos en el spec driven development.

La idea central es simple: primero aseguras tus checkpoints con ramas independientes en Git, y luego defines el qué y el porqué de tu aplicación para que la IA decida el cómo.

Por qué usar Git para versionar cada paso del proyecto

Antes de escribir una sola especificación, conviene tener control sobre los cambios. Git es la herramienta que permite manejar el versionado de los artefactos y del código de tu proyecto de software [00:38]. Piensa en cada rama como un checkpoint al que puedes volver si algo falla.

El flujo empieza ubicándote en la raíz del proyecto, en este caso my-project, e inicializando el repositorio:

bash git init git status

Con git init habilitas el seguimiento de cambios y con git status verás todos los archivos generados al instalar Spec Kit, más la constitución de la clase anterior [01:12].

¿Para qué sirve crear una rama por cada comando? Sirve para aislar los cambios de cada paso y poder regresar al punto más estable de la aplicación en caso de que algo falle. Cada comando del curso vive en su propia rama independiente.

Cómo crear una rama y trackear los cambios en Git

La estrategia es trabajar cada avance en una rama separada. Para la constitución, se crea una rama nueva y Git se sitúa automáticamente en ella:

bash git checkout -b constitucion git add . git commit -m "constitucion del proyecto"

Con git checkout -b creas y saltas a la nueva rama de una sola vez. Luego git add agrega los cambios y git commit los confirma con un mensaje que describe qué estás guardando [02:04]. Verifícalo de nuevo con git status: si no hay cambios pendientes, todo quedó trackeado.

Dos consejos prácticos que se comparten aquí: no te agobies memorizando comandos, usa los mismos que ves en pantalla; y si quieres profundizar, existe el curso de Git de Platzi [02:33].

Qué cambio de mentalidad exige el spec driven development

Y aquí viene lo interesante. En el vibe coding estamos acostumbrados a microgestionar la IA: le dictamos qué componente usar en el backend, qué librería en el frontend, etcétera [03:14]. Ese enfoque te convierte en un supervisor de detalles.

Con el spec driven development el rol cambia por completo. Tú eres el director de producto. A un equipo de ingeniería no le dictas cómo escribir el código: le defines el qué y el porqué, y la IA decide el cómo en los pasos siguientes [03:22].

¿Qué es el spec driven development? Es un enfoque donde defines las funcionalidades y restricciones de tu aplicación, no la implementación. Tú actúas como director de producto y la inteligencia artificial se encarga de traducir esas especificaciones en código.

Qué debe contener una spec bien estructurada

Una spec sólida retoma la anatomía mínima vista antes: intención, comportamiento, restricciones y no objetivos [03:55]. La diferencia es que ahora no describes una sola funcionalidad, sino todas las de la aplicación.

En el ejemplo de una app de reservas de canchas, las features principales son:

• Autenticación de usuario.
• Exploración y selección de canchas.
• Creación de reservas.
• Gestión de reservas.

Cada funcionalidad se escribe en términos de comportamiento y restricción. Por ejemplo: los usuarios deben poder registrarse e iniciar sesión con correo y contraseña define la funcionalidad; solo los usuarios con sesión activa pueden ver la disponibilidad completa y reservar define la restricción [04:38].

Por qué los no objetivos son clave en tu especificación

Tan importante como decir qué construir es decir qué no construir. Los no objetivos evitan que la IA agregue funcionalidades que no pediste. En este proyecto se excluyen de forma explícita:

• No habrá pasarela de pagos.
• No habrá panel de administrador web.
• No habrá notificaciones externas.
• No habrá reservas de más de una hora continua.
• No habrá sistema de matchmaking para buscar compañeros de juego [05:20].

Esa lista funciona como una constitución del alcance: delimita el terreno igual que un permiso de construcción que solo autoriza casas de ladrillo de hasta tres pisos.

Cómo pasar tu spec a Claude Code con Spec Kit

El proceso replica lo que ya se hizo con la constitución: conviertes la especificación en un prompt, se lo pasas a Claude con el comando propio de Specify, y Claude devuelve la spec completamente estructurada con historias de usuario, criterios técnicos, criterios de aceptación y edge cases [05:50].

Recuerda algo que marca la diferencia: la calidad del resultado depende de la calidad del prompt. Por eso conviene evitar ambigüedades, subjetividad y darle pensamiento crítico a la IA [06:20].

Los pasos concretos son:

1. Crear la rama de spec desde la rama de constitución con git checkout -b spec.
2. Copiar el prompt con tus especificaciones.
3. Abrir Claude con el comando claude y ejecutar spec-kit specify.
4. Pegar el prompt y presionar enter.

Al darle enter, Claude Code toma la información del proyecto y comienza a llenar el template de especificación usando los skills que trae Spec Kit [07:14]. Tras un par de minutos, genera el archivo spec.md, que luego abres en Visual Studio Code para revisarlo [07:53].

¿Ya intentaste convertir tus propias especificaciones en un prompt? Cuéntame en los comentarios qué no objetivos definiste para tu proyecto.