Contenido del curso
Crear la base full-stack del producto
- 6

Composer 2.5 ejecuta tu primer spec en Cursor
02:26 min - 7

Cómo actualizar dependencias sin errores del LLM
06:35 min - 8

Cómo usar MCP en Cursor para validar tu API
07:32 min - 9

Hooks en Cursor para proteger tu código
07:20 min - 10

Playwright y Multitask para testear tu app
06:21 min - 11

Worktrees: ejecuta dos agentes en paralelo
05:27 min
Calidad, entrega y automatización
Cómo dividir un PRD en specs con Cursor
Resumen
Convertir un PRD en piezas ejecutables es el paso que separa una idea documentada de un software funcional. Con Spec Driven Development puedes tomar tu PRD y dividirlo en especificaciones pequeñas para que un subagente en Cursor las ejecute sin ambigüedad. Esto te sirve si construyes productos con IA y quieres ganar velocidad real.
Qué es Spec Driven Development y por qué importa
La idea es simple: un PRD grande es difícil de ejecutar de un solo golpe, así que lo partes en specs pequeñas y autocontenidas que un agente pueda resolver por sí solo.
¿Qué es una spec? Es una especificación técnica pequeña, derivada del PRD, con alcance acotado para que un subagente la ejecute sin depender de decisiones externas.
La técnica se llama Spec Driven Development y su valor está en que reduce ambigüedad, permite paralelizar el trabajo y mantiene trazabilidad entre lo que pediste en el PRD y lo que se está construyendo. [0:05]
Cómo responder las preguntas previas antes de generar las specs
Antes de crear las specs, Cursor te lanza preguntas para cerrar decisiones abiertas del PRD. En este flujo aparecieron dos.
La primera fue sobre el SDK ligero que el PRD mencionaba con un cache total TTL de 30 a 60 segundos de propagación, pero sin spec dedicada. Puedes elegir entre las opciones sugeridas o escribir tu propia respuesta. Aquí decidimos no incluir el SDK en esta iteración. [0:32]
La segunda pregunta apuntaba al spec 01, el monorepo setup, y preguntaba qué orquestador usar:
- PNPM workspaces con Turborepo.
- PNPM workspaces sin Turborepo.
Esta ya es una decisión técnica, no de producto. Elegimos PNPM workspaces sin Turborepo y continuamos. [1:05]
Por qué estas preguntas son decisiones técnicas y no de producto
El PRD define qué se construye y para quién. Las specs definen cómo se construye. Cuando Cursor pregunta por orquestadores, gestores o inclusión de paquetes, te está pidiendo cerrar el cómo para que el agente no improvise en mitad de la ejecución.
Cómo revisar el plan que genera Cursor
Después de responder, Cursor genera un plan, que es la fuente de verdad de las decisiones. Ese documento incluye varias piezas que conviene leer con calma:
- La referencia al PRD como fuente original.
- El stack definido y las exclusiones, como el SDK que dejamos fuera.
- La plantilla obligatoria que debe seguir cada spec.
- El mapeo de cada spec contra el PRD.
Este plan es editable directamente en la vista de Cursor. Si algo no te cuadra, ajústalo antes de ejecutar, porque será la base sobre la que se construirá todo lo demás. [1:40]
¿Debo leer el plan completo antes de ejecutar? Sí. Es tu última oportunidad de corregir decisiones antes de que los subagentes empiecen a crear specs y código.
Qué hace la opción Build in parallel en Cursor
Cuando el plan te convence, Cursor muestra un botón Build en la parte superior derecha. Si abres la flecha lateral, aparecen dos variantes:
- Build local, para ejecutar dentro de tu máquina.
- Build in parallel, para que Cursor decida qué to-dos puede paralelizar.
Al elegir build in parallel, Cursor analiza las tareas pendientes y lanza los subagentes que considere necesarios al mismo tiempo. En este caso lanzó tres subagentes con esta repartición:
- Subagente 1: specs del 1 al 3.
- Subagente 2: specs del 4 al 5.9.
- Subagente 3: specs 6, 7, 8, 10 y 11.
Eso significa que Cursor detectó que entre esos grupos no había dependencias directas y decidió que tres agentes bastaban para ejecutar en serie lo que debía ir en serie y en paralelo lo que podía ir en paralelo. [2:30]
Cuándo conviene paralelizar y cuándo no
Paralelizar acelera, pero solo funciona cuando las tareas son independientes. Si dos specs comparten archivos o dependen del resultado de otra, Cursor las mantiene en serie. Por eso es él quien decide, según el contenido de cada spec, cuántos subagentes lanzar.
En proyectos pequeños quizá no notes la diferencia. En software grande, esta feature ahorra tiempo real porque Cursor lanza automáticamente los subagentes que necesita y luego entrega un resumen dentro de la misma conversación.
Tu turno para dividir el PRD en specs
Toma el PRD que ya tienes y divídelo en specs usando el prompt que está en la sección de recursos. Tienes dos caminos:
- Usar el prompt tal cual, con los specs ya descritos.
- Eliminar los specs propuestos y dejar que el agente sugiera cuántos crear.
Cuéntame en los comentarios cuántos specs te propuso Cursor y si decidiste ejecutarlos con build in parallel o en local.