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 convertir un requerimiento ambiguo en PRD con Cursor
Resumen
Convertir un requerimiento ambiguo en un documento técnico accionable es una de las tareas más complicadas del desarrollo. Con Cursor y su modo agente puedes transformar un problema difuso en un PRD claro, listo para implementación, sin escribir el documento tú mismo. Esta guía es para desarrolladores que quieren delegar tareas de producto en un agente de IA.
Qué es un PRD y por qué importa en desarrollo de software
El Product Requirement Document es el puente entre negocio e ingeniería. Cuando tu jefe llega con un problema incompleto, un PRD bien estructurado te ahorra semanas de retrabajo.
Durante el curso vamos a construir un programa llamado Feature Flags, una pieza de software presente en la mayoría de compañías que permite direccionar tráfico entre secciones de una web. Sirve para hacer A/B testing u ocultar funcionalidades según la zona geográfica del usuario.
¿Qué es un feature flag? Es un mecanismo que activa o desactiva funcionalidades de software sin necesidad de hacer deploy. Permite controlar qué usuarios ven qué versión de un producto en tiempo real.
El requerimiento inicial que trabajamos fue este: necesitamos una herramienta interna para activar o desactivar features por empresa, ambiente o porcentaje de tráfico, sin hacer deploy cada vez. Vago, ambiguo, típico de la vida real.
Cómo funcionan los modos Ask y Agent en Cursor
Cursor tiene dos interfaces que debes distinguir desde el inicio. La primera es el editor de código clásico, un fork de Visual Studio Code que abres desde la esquina superior derecha. La segunda es la interfaz de agentes, donde ocurre la magia real de este flujo. [0:35]
Dentro de la interfaz de agentes existen dos modos de interacción:
- Modo Ask: conversas con el agente como si fuera un chat. No ejecuta código ni modifica archivos, solo responde y ayuda a pensar.
- Modo Agent: el agente puede crear, escribir y modificar archivos en tu sistema. Aquí es donde delegas trabajo real.
- Selector con el botón +: te permite elegir entre estos modos antes de iniciar la conversación.
La regla práctica: usa Ask para desenvolver el problema y cambia a Agent cuando ya tengas claridad y quieras materializar archivos.
Cómo escribir un prompt inicial para desenvolver requerimientos ambiguos
Aquí viene lo interesante. En vez de pedirle al agente que escriba el PRD de una, le pides que actúe como product manager senior y que primero identifique qué decisiones faltan por definir. [2:05]
El prompt inicial le pide seis a ocho decisiones clave agrupadas por categorías: alcance, usuarios, dominio y técnico. Con eso conciso, el agente devuelve un mapa de dudas que tú, como desarrollador, debes resolver con tu stakeholder antes de continuar.
Una de las primeras decisiones que el agente propuso fue definir qué es un feature. Este paso es oro puro: crear un glosario compartido desde el día uno garantiza que tú y tu agente hablen el mismo lenguaje durante todo el proyecto. [3:20]
¿Por qué no pedirle el PRD directamente al agente? Porque un documento escrito sobre supuestos débiles genera código débil. Primero bloqueas decisiones, después escribes.
Cómo bloquear decisiones y limitar el alcance del documento
Una vez el agente lista las decisiones abiertas, tu trabajo es aceptar, rechazar o modificar cada una. En el ejemplo, el prompt de respuesta fue directo: acepto casi todo, pero el alcance no incluye auth para autorización, roles ni permisos avanzados. El login es solo un usuario demo. El targeting soporta ambiente, empresa y rollout. Persistencia local con SQLite.
Con esa instrucción el agente marca esas decisiones como definitivas y no vuelve a abrirlas. Delimitar lo que no va en el programa es tan importante como definir lo que sí va.
Cómo generar el PRD final en Markdown con Cursor
Cuando las decisiones están bloqueadas, envías un tercer prompt pidiendo el documento completo en Markdown con una estructura de nueve ítems, incluyendo riesgos y supuestos. Cada requerimiento debe ser funcional y verificable, escrito en lenguaje claro. [5:40]
Aquí ocurre un detalle clave que muchos pasan por alto. El agente respondió con el PRD listado en la conversación pero no creó el archivo. La razón: seguíamos en modo Ask. En el último párrafo el propio agente lo advirtió: para guardarlo como documento, activa el modo Agent y pídelo de nuevo.
Al cambiar a modo Agent y repetir la petición, el agente:
- Creó la carpeta
Docs. - Dentro creó la subcarpeta
PRDs. - Guardó el archivo Markdown con la estructura solicitada.
El documento final incluye contexto, objetivo, público objetivo, alcance del MVP, conceptos de dominio, glosario, requerimientos funcionales verificables, requisitos no funcionales, criterios de aceptación y riesgos. Todo trazable, todo accionable.
Cuál es el reto práctico para dominar este flujo
Descarga los prompts de la sección de recursos y ejecútalos en Cursor Agent Mode. Puedes usarlos tal cual o iterarlos según tu propio requerimiento. La habilidad que estás entrenando no es escribir prompts perfectos, sino guiar a un agente para que produzca artefactos de trabajo reales.
¿Ya probaste este flujo con algún requerimiento ambiguo de tu trabajo? Cuéntame en los comentarios cómo te fue con el PRD generado.