- Estás empezando una app nueva o una nueva función importante con un constructor de IA.
- Puedes nombrar a una persona que tiene el problema, aunque todavía no hayas hablado con ella.
- Quieres evitar que el constructor añada funciones que nadie pidió.
- Quieres una lista de verificación para evaluar cada versión en lugar de hacer clic al azar.
Casos de usoEspañol
De una idea a un brief listo para construir
Escribe un PRD de una página que tu constructor de IA pueda seguir y un usuario real pueda probar.
Los constructores de IA hacen lo que el prompt da a entender y rellenan los huecos con suposiciones: una pantalla de inicio de sesión, un panel, una página de pago. Un PRD breve nombra para quién es la app, qué debe hacer, qué no debe hacer y cómo sabrás que cada parte funciona.
Cuándo aplica
Usa un PRD cuando el constructor no deja de suponer.
Un prompt de una línea sirve para una demo. En cuanto quieres que otra persona use la app, el constructor necesita las mismas pocas decisiones cada vez que cambia el código.
- Necesitas un documento de requisitos empresarial completo con la aprobación de las partes interesadas.
- Quieres un generador que escriba el PRD sin tus decisiones.
- Esperas que el PRD demuestre que la gente quiere la app; solo las personas pueden hacerlo.
- Necesitas una revisión de seguridad, una aprobación de cumplimiento normativo o un certificado de preparación para producción.
El flujo de trabajo completo más pequeño
Seis decisiones en una página y, después, una versión cada vez.
Rellena la plantilla de abajo en un archivo Markdown sencillo. Cada paso elimina algo que, de otro modo, el constructor tendría que suponer.
- 01
Nombra al primer usuario y el detonante
Escribe una persona concreta y el momento en que necesita la app: «Quienes comparten piso y nevera, justo después de que alguien pague una compra del súper». Si no puedes nombrar a nadie, habla con personas antes de construir.
- 02
Escribe un trabajo y como máximo tres imprescindibles
Expresa el trabajo en una frase y luego enumera hasta tres comportamientos que la app debe tener para ese trabajo. Todo lo demás va después. Tres es un límite, no un objetivo.
- 03
Enumera explícitamente los no-objetivos
Nombra lo que la primera versión no debe incluir, como cuentas, pagos, notificaciones, un panel de administración o un panel de control. Los constructores tienden a añadirlos por defecto; los no-objetivos escritos te dan un motivo para rechazarlos.
- 04
Describe los datos y las pantallas con palabras sencillas
Enumera las pocas cosas que guarda la app y las pantallas por las que pasa un usuario. Bastan sustantivos sencillos: lista, artículo, quién pagó, importe. Deja la elección del framework al constructor salvo que tengas un motivo.
- 05
Da a cada imprescindible una comprobación
Escribe lo que verás cuando funcione: «Un artículo añadido en un teléfono aparece en el segundo teléfono tras actualizar». Evita palabras como rápido, intuitivo o moderno, que no se pueden comprobar.
- 06
Colócalo donde la herramienta lo lee y construye una pieza
Pégalo en el archivo de conocimiento de Lovable, o guárdalo como PRD.md y referéncialo desde CLAUDE.md o AGENTS.md. Pide al constructor que planifique antes de construir, implemente un imprescindible, ejecute su comprobación y actualice el PRD cuando cambies una decisión.
Control verificable
Ejemplo de tarjeta de aprobación: construir solo el imprescindible 1
Esta es una tarjeta de tarea ilustrativa, no un resultado de cliente declarado ni un experimento completado.
- Objetivo
- Permitir que dos personas que comparten piso añadan artículos a una misma lista de compras compartida desde teléfonos distintos, como imprescindible 1 del PRD de la app ficticia Splitlist.
- Acción
- Implementar el imprescindible 1 en el proyecto proporcionado. Devolver el cambio y el resultado de cada comprobación de aceptación para su revisión.
- Objeto
- Un proyecto y su repositorio. Sin proveedores de inicio de sesión, pagos, notificaciones ni los otros dos imprescindibles.
- Criterio de aceptación
- Un artículo añadido en el teléfono A aparece en el teléfono B tras actualizar; se rechazan los artículos vacíos; la lista cabe en una pantalla de 390px sin desplazamiento lateral; ninguna otra pantalla cambia.
- Condición de parada
- Detenerse si el modelo de datos necesitara cuentas de usuario, que el PRD incluye como no-objetivo, o si una comprobación no puede ejecutarse en el sandbox.
ModificarRechazarAprobar el alcance exacto
PRD copiable de una página
Ocho encabezados. Una página. Cada línea, comprobable.
Ejemplo ilustrativo: Splitlist es una app ficticia de lista de compras compartida. Sustituye cada línea por tus propias decisiones; marca como suposición todo lo que no hayas confirmado con una persona.
- Primer usuario y detonante
- Quienes comparten piso y nevera, justo después de que una de esas personas pague una compra del súper. Suposición: ya dividen los gastos por mensaje.
- Un trabajo
- Saber quién debe qué después de cada compra del súper sin una hoja de cálculo.
- Imprescindibles (como máximo tres)
- 1. Añadir artículos a una lista compartida desde cualquier teléfono. 2. Marcar una compra como pagada por una persona, con el total. 3. Mostrar el saldo acumulado de cada persona.
- No-objetivos de la versión 1
- Sin cuentas ni contraseñas (se comparte un enlace privado), sin pagos dentro de la app, sin notificaciones, sin escaneo de tickets, sin panel de administración.
- Datos
- Lista, artículo (nombre, añadido por), compra (pagada por, total, fecha), miembro (nombre visible). Los saldos se calculan, no se guardan.
- Pantallas
- Lista compartida; formulario para marcar como pagada; saldos. Diseño mobile first a 390px de ancho.
- Comprobaciones de aceptación
- Un artículo añadido en un teléfono aparece en el otro tras actualizar. Una compra de $42 pagada por A entre dos miembros muestra que B le debe $21 a A. Se rechazan los artículos vacíos y los totales negativos.
- Prueba con el primer usuario
- Dos personas reales que comparten piso la usan durante una compra del súper. Se supera si ambas pueden decir quién debe qué sin preguntarte. Registra lo que les confundió.
Tabla de decisión
Evalúa el PRD por lo que evita y por lo que te permite comprobar.
Un buen PRD es breve y comprobable. Estas señales te indican si está haciendo su trabajo.
Una página
Todo el PRD cabe en una pantalla o página y nombra a un usuario y un trabajo.
Suposiciones marcadas
Todo lo que no se ha confirmado con una persona real está etiquetado como suposición.
Comprobaciones superadas
Cada imprescindible tiene una comprobación que puedes hacer tú y la última versión la supera.
Alcance respetado
Nada de la lista de no-objetivos apareció en la versión, o lo eliminaste.
Trabajo completado por el primer usuario
Una persona real terminó el trabajo sin tu ayuda. Una demo para ti no cuenta.
Actualizado
Cuando cambiaste una decisión, el PRD cambió en la misma sesión.
Formato de evidencia de la investigación
Dónde lee cada herramienta el contexto de tu proyecto
Documentación consultada el 21 de octubre de 2026. Las herramientas cambian a menudo sus funciones de contexto; confirma la ubicación actual antes de confiar en ella.
El archivo de conocimiento de Lovable siempre forma parte del contexto con el que trabaja Lovable, y la documentación dice que uno bueno se lee como un brief de una página, no como una wiki. Se recomienda el modo de planificación para cualquier cosa mayor que un ajuste.
Pega el PRD de una página en el archivo de conocimiento y planifica antes de cada imprescindible.
Buenas prácticas de LovableClaude Code carga CLAUDE.md, o el AGENTS.md de un repositorio, al inicio de cada sesión como contexto, e indica que las instrucciones concretas y concisas se siguen de forma más constante.
Mantén el PRD breve y referéncialo desde CLAUDE.md o AGENTS.md para que cada sesión empiece con él.
Documentación de memoria de Claude CodeCursor admite AGENTS.md en la raíz del proyecto y en subdirectorios, y su documentación de reglas aconseja referenciar archivos en lugar de copiar su contenido.
Mantén PRD.md como un solo archivo y apunta a él desde AGENTS.md o una regla del proyecto.
Documentación de reglas de CursorSoloop construye a partir de una idea o de código existente en un sandbox y mantiene un Product Doc editable con el producto, el usuario objetivo, el problema, la ventaja y el enfoque actual. No documenta un generador de PRD.
Usa la plantilla por tu cuenta, o pide a Soloop que te ayude a redactarla en el chat antes de aprobar una tarea de Build.
Manual del producto Soloop · actualizado el 24 de septiembre de 2026Límites actuales del producto
Planifica con lo que realmente funciona hoy.
Esto es una plantilla y un flujo de trabajo, no un generador de PRD. Un PRD claro hace que las versiones sean más fáciles de comprobar; no demuestra que alguien quiera la app. El ejemplo de Splitlist es ficticio.
Plantilla
GratisCopia los ocho encabezados en cualquier archivo Markdown. No hace falta registrarse.
Redacción en el chat
ActivoDescribe la idea y pide a Soloop que cuestione tus suposiciones y redacte el PRD para que lo revises.
Product Doc
ActivoMantén el producto, el usuario objetivo, el problema y el enfoque actual en el Product Doc editable de Soloop.
Build
Activo tras aprobaciónSoloop puede construir a partir de una idea o del código proporcionado en un sandbox y devolver cambios y comprobaciones para su revisión.
Generador de PRD
No es una funciónNo hay un generador de PRD con un solo clic; las decisiones del PRD son tuyas.
Otros constructores
Tu proyectoSoloop no edita proyectos de Lovable, Cursor ni Claude Code; pega allí el PRD por tu cuenta.
Continúa el ciclo
Usa el siguiente recurso cuando cambie la decisión.
Preguntas frecuentes
Preguntas antes del siguiente paso.
¿Qué debe incluir un PRD para vibe coding?
El primer usuario y el detonante, un trabajo, como máximo tres comportamientos imprescindibles, no-objetivos, datos, pantallas, una comprobación de aceptación para cada imprescindible y una prueba con el primer usuario. Eso basta para que un constructor de IA deje de suponer y para que puedas evaluar cada versión.
¿Dónde pongo el PRD en Lovable, Cursor o Claude Code?
En Lovable, pégalo en el archivo de conocimiento del proyecto. En Claude Code, guarda PRD.md y referéncialo desde CLAUDE.md o AGENTS.md. En Cursor, referéncialo desde AGENTS.md o una regla del proyecto. Consulta la documentación actual de cada herramienta, porque estas funciones cambian.
¿Qué extensión debe tener un PRD para vibe coding?
Una página. La documentación de Lovable describe un buen archivo de conocimiento como un brief de una página, y la de Claude Code dice que las instrucciones concisas se siguen de forma más constante. Pon el detalle en las comprobaciones de aceptación, no en el contexto general.
¿Puede Soloop escribir el PRD y crear la app?
Soloop puede ayudarte a redactarlo en el chat, mantener lo esencial en su Product Doc y, después de que apruebes una tarea de Build, construir a partir de la idea en un sandbox. No tiene un generador de PRD con un solo clic y no edita proyectos dentro de otros constructores.
Trae el producto que ya tienes
Trae tu idea y una persona.
Copia este brief y reemplaza los corchetes. «Empieza con un proyecto» abre la página de inicio de Soloop; pega el brief allí. No se transfiere automáticamente. También puedes pegar el PRD terminado en cualquier otro constructor.
Quiero crear [idea de app] para [persona concreta] que [detonante]. Ayúdame a escribir un PRD de una página con: primer usuario y detonante, un trabajo, como máximo tres comportamientos imprescindibles, no-objetivos, datos, pantallas, una comprobación de aceptación para cada imprescindible y una prueba con el primer usuario. Hazme primero preguntas aclaratorias y marca como suposición todo lo que no haya confirmado. No inicies una tarea de Build hasta que apruebe el PRD.Empieza con un proyecto