De la idea al demo presentable: PRD → Diseño → Demo

Qué hace esta habilidad

Guía al usuario a través de cinco pasos para convertir una idea de producto en un demo interactivo atractivo y listo para presentar en vivo:

Entrevistas iterativas para aclarar los requisitos
Redactar prd.md, que el usuario confirma
Pedir al usuario que envíe referencias de UI, aclarar qué le gusta
Redactar design.md, que el usuario confirma (puede empezar con una tarjeta de estilo)
Construir demo.html siguiendo ambos documentos, autoverificar, entregar e iterar según el feedback

Después de cada uso, el feedback del usuario se consolida en el archivo de experiencia LEARNINGS.md y, tras confirmación del usuario, se escribe de vuelta en este archivo para que la habilidad mejore con el uso (consulta la fase 8).

Esta habilidad no depende de una herramienta de IA específica. Si la herramienta puede crear archivos, los escribe directamente; si no, coloca el contenido completo en un bloque de código y pide al usuario que lo guarde con el nombre de archivo correspondiente.

Estructura de archivos

Archivo	Propósito	Cuándo se lee
`SKILL.md`	Flujo principal: reglas fijas, banco de preguntas de entrevista, dos listas de verificación, reglas de consolidación de experiencia	Cada inicio
`references/prd-template.md`	Plantilla de `prd.md` (Apéndice A)	Antes de la fase 2
`references/design-template.md`	Plantilla de `design.md` (Apéndice B)	Antes de la fase 4
`LEARNINGS.md`	Repositorio de experiencia: reglas derivadas del feedback del usuario	Antes de cada inicio

Lee solo el archivo que necesites en cada momento; no leas todos los archivos a la vez en el contexto.

Resumen del flujo

Fase	Salida	Condición de aprobación
0 Inicio	Explicación del itinerario en 1-2 oraciones	El usuario responde
1 Entrevista de requisitos	Registro de 5 rondas de preguntas y respuestas	Se cumplen los criterios para iniciar el PRD
2 Redactar PRD	`prd.md`	El usuario confirma el listado de páginas, el guión de demostración y las diferencias de modo
3 Referencias UI	Lista de referencias + "¿qué es lo que más te gusta de cada una?"	El usuario envía referencias o elige una dirección de estilo
4 Redactar Diseño	`design.md` (puede empezar con una tarjeta de estilo)	El usuario confirma el estilo
5 Construir Demo	`demo.html`	Ambas listas de verificación están completas
6 Autoverificación y entrega	Revisión + instrucciones de entrega	El usuario sabe cómo abrir y cómo presentar
7 Iteración y mejoras	Cambios / imágenes reales / sonido / material de presentación	El usuario está satisfecho
8 Consolidación de experiencia	Nueva entrada en `LEARNINGS.md`	El usuario confirma antes de escribir en `SKILL.md`

Antes de empezar: lee el repositorio de experiencia

Si en la carpeta de la habilidad (o en la carpeta del proyecto del usuario) existe LEARNINGS.md, léelo antes de empezar. Las reglas que contiene provienen de feedback de usuarios anteriores:

En caso de conflicto con este archivo, prevalece el repositorio de experiencia.
Al inicio, informa al usuario con una frase qué reglas de experiencia vas a aplicar, para que pueda decir "esta regla no la uses esta vez".

Si no existe el archivo, omite este paso.

Reglas fijas

Sigue las fases en orden, sin saltos. Cada fase debe terminar con una confirmación explícita del usuario (ej. "de acuerdo", "siguiente") antes de pasar a la siguiente. Si el usuario dice "hazlo directamente", completa los valores con defaults razonables, pero lista explícitamente cada suposición para que el usuario pueda modificarlas de un vistazo.
Haz solo 3-5 preguntas por ronda. Cada pregunta debe ofrecer 2-4 opciones y un valor por defecto recomendado. El usuario puede responder simplemente "todo según lo recomendado".
Después de cada ronda, parafrasea. Escribe tu comprensión en 3-5 líneas antes de hacer la siguiente pregunta.
Los documentos son la única fuente de verdad para el demo. Cada página, texto y dato del demo debe poder rastrearse en prd.md; los colores, tamaños de fuente, bordes redondeados y sombras deben provenir de design.md. Si surge un nuevo requisito intermedio, primero modifica los documentos y luego el demo.
Tanto lo atractivo como lo presentable son igual de importantes. Un demo bonito pero que no se puede navegar, o uno navegable pero feo, no está completo.
Sé honesto. Las capacidades simuladas en el demo (datos falsos, llamadas externas simuladas, reconocimiento simulado) deben etiquetarse claramente; no presentes la simulación como real.

Fase 0: Inicio

Primero, explica al usuario el itinerario en 2-3 oraciones y luego haz la primera pregunta. Ejemplo:

El proceso será así: primero conversamos para aclarar los requisitos, luego redacto un prd.md para que lo confirmes; después me envías algunas referencias de UI que te gusten, las organizo en un design.md; y finalmente, siguiendo ambos documentos, construyo un demo que se abre con doble clic y está listo para presentar. Cada paso lo confirmas antes de continuar. Empecemos por el producto en sí—

Fase 1: Entrevista de requisitos (varias rondas)

Avanza por rondas. A continuación, el banco de preguntas; elige según la situación, no preguntes todo de una vez.

Ronda 1: ¿Qué es el producto?

En una frase: ¿para quién es, qué problema resuelve y en qué es mejor que lo que se hace ahora?
Forma: ¿App móvil (iOS / Android), miniprograma, web, software de escritorio, hardware + App?
¿Para quién es este demo y en qué contexto? (presentación a inversores, revisión, informe al jefe, pruebas de usuario) ¿Cuánto tiempo de presentación se necesita?
¿Tienes algún material existente que puedas enviarme? (documentos, competidores, bocetos, capturas de pantalla)

Ronda 2: Escenarios principales y momentos destacados

¿Cuáles son los 3 escenarios de uso más comunes?
¿Cuáles son los 1-3 momentos que más quieres que sorprendan al público durante la presentación?
¿Hay diferentes tipos de usuario o modos (novato / experto, simple / detallado, gratuito / premium)? ¿Cómo deberían verse visualmente diferentes?

Ronda 3: Páginas y flujo

Propón un borrador del listado de páginas basado en las rondas anteriores (P01, P02…). Pide al usuario que añada o elimine.
Recorre cada escenario principal: desde dónde se entra → qué se ve → qué se pulsa → qué resultado se obtiene.

Ronda 4: Estados, reglas y tono

¿Qué estados se deben mostrar: estado vacío, carga, error, permisos no concedidos, desconexión de red, feedback de éxito?
¿Hay reglas o límites (límite de uso, control de frecuencia, permisos, cuotas)?
Tono del texto: ¿profesional y contenido, cálido y cercano, vivo y divertido? ¿Idioma de la interfaz?

Ronda 5: Contenido y condiciones de presentación

¿Se necesitan imágenes con sensación realista (fotos reales, imágenes de productos, avatares)? ¿Puede proporcionarlas el usuario, o se usarán ilustraciones / placeholders gráficos?
¿Se necesitan efectos "vivos" como sonido, animaciones, hora en tiempo real?
Dispositivo de presentación: ¿proyección desde ordenador, demo directo desde el móvil, o ambos?

Criterios para empezar a escribir el PRD (todos cumplidos, o usando valores por defecto con consentimiento del usuario):

Frase del producto, público objetivo, plataforma
Audiencia, contexto, duración de la presentación
Al menos 3 escenarios principales, 1-3 momentos destacados
Listado de páginas y elementos principales de cada una
Estados clave, reglas y tono del texto
Fuente de contenido (imágenes / sonido, etc.)

Fase 2: Redactar prd.md

Redacta siguiendo la plantilla en references/prd-template.md. Una vez redactado, pide al usuario que revise especialmente tres aspectos: el listado de páginas (si falta alguna o sobra), el guión de demostración (si fluye con naturalidad) y las diferencias de modo (si son suficientemente claras). Modifica hasta que el usuario diga que está bien.

Puntos clave al redactar el PRD:

Cada página tiene un número (P01…); el design.md y el demo.html posteriores usarán la misma numeración.
Los datos de ejemplo deben ser concretos: nombres realistas, horas, números, textos que puedan formar una historia coherente (el mismo usuario, la misma casa, la misma tienda a lo largo de todo el demo).
El guión de demostración se divide por tiempo en pasos; cada paso debe especificar: qué se dice, qué se pulsa, qué se ve.
Especifica claramente "qué NO hace este demo" para evitar que el alcance se expanda.

Fase 3: Recopilar referencias UI

Una vez confirmado el PRD, pide explícitamente al usuario que envíe referencias:

Ahora definimos el estilo visual. Por favor, envíame 2-5 referencias UI que te gusten: capturas de apps, enlaces web, trabajos en Figma, Dribbble / Mobbin. De cada una, dime brevemente qué te gusta (combinación de colores, espaciado, tarjetas, tipografía, ilustraciones, animaciones, ambiente general) y si hay algo que no te gusta.

Cómo manejarlas:

Pregunta a cada referencia: ¿qué es lo que más te gustaría tomar prestado de ella? Esto es mucho más preciso que adivinarlo.
Si el usuario no tiene referencias: ofrece 3 direcciones de estilo; de cada una escribe una descripción + color principal + producto conocido con un estilo similar, y pide al usuario que elija una o combine.
Si no puedes ver las imágenes: pide al usuario que las describa con texto, o que nombre la app de referencia, o que pegue variables de diseño / CSS.
Solo aprende los principios, no copies. Extrae las relaciones de color, densidad de información, jerarquía, bordes redondeados, sombras, estilo de iconos; no copies logotipos, nombres de marca, personajes ilustrados ni gráficos propietarios.

Fase 4: Redactar design.md

Redacta siguiendo la plantilla en references/design-template.md. Requisitos:

Todo debe ser valores numéricos concretos: valores de color (hex), tamaño de fuente / interlineado (px), espaciado, bordes redondeados, parámetros de sombra. Adjetivos como "moderno y minimalista" o "sofisticado" no pueden sustituir a los valores numéricos.
Cada token debe incluir su propósito (ej. --ink-2 para texto secundario, marcas de tiempo).
Redacta una tabla de "referencia → qué aprender / qué no aprender" para que el usuario vea que has entendido sus preferencias.
Redacta una "lista de prohibiciones": prácticas visuales que este producto no debe tener.
Para cada página del PRD, escribe 1-3 puntos clave de layout, usando la numeración de páginas del PRD.

Tarjeta de estilo (recomendado): antes de construir todo el demo, crea una pequeña página HTML que muestre la paleta de colores, la jerarquía tipográfica, botones, una tarjeta, una fila de lista y una sección parcial de la página de inicio. Pide al usuario que confirme el estilo. Modificar la tarjeta de estilo es barato; modificar todo el demo es caro.

Fase 5: Construir demo.html

Restricciones técnicas

Un único archivo HTML, con CSS y JS todo embebido, sin paso de construcción; debe abrirse con doble clic en Chrome / Safari.
Completo incluso sin conexión: las imágenes proporcionadas por el usuario se convierten a base64 embebido (primero comprimir: lado largo máximo 1600px, calidad JPEG ~0.8); los iconos usan SVG embebido; no dependas de imágenes externas. Las fuentes externas están permitidas, pero debe haber fuentes del sistema como fallback (chino: "PingFang SC","Noto Sans SC","Microsoft YaHei",sans-serif).
Los estados clave se almacenan en memoria, no en localStorage (algunos entornos de previsualización no lo soportan).
Si el código es largo, escríbelo en módulos (estilos, datos, renderizado de páginas, interacciones, panel de presentación) y luego combínalos en un solo archivo. Si la herramienta tiene límite de salida: entrega primero la estructura y el esqueleto, luego completa las páginas por lotes.

Entorno de presentación: hazlo "presentable"

En pantalla ancha de escritorio, usa un diseño de tres columnas "modo presentación":

Centro: marco del dispositivo. Para móvil, usa una proporción de aproximadamente 393×852 (iPhone), con isla dinámica, barra de estado (9:41, señal, batería), indicador de inicio y áreas seguras; escala proporcionalmente según la altura de la ventana para asegurar que todo el dispositivo sea visible. Para producto web, usa un marco de ventana del navegador.
Izquierda: panel de guión de presentación. Divídelo según los pasos del guión del PRD; cada paso muestra el intervalo de tiempo, título, 2-3 puntos clave de explicación y un botón de acción (para saltar el teléfono a la página correspondiente o activar el evento correspondiente). Las teclas ←/→ cambian de paso.
Derecha: consola de escenas. Activa eventos y estados con un solo clic (nuevo mensaje, anomalía, estado vacío, cambio de modo / tipo de usuario), así como "restablecer al estado inicial".

En pantalla estrecha o desde el móvil: oculta los paneles laterales; la app ocupa toda la pantalla y se puede presentar directamente desde el móvil.

La página de presentación (el fondo y los paneles fuera del marco) también debe ser cuidada: fondo de color limpio, que armonice con el color principal del producto, y que soporte modo oscuro.

La app en sí

Basada en estado. Un objeto state y una función render; todas las páginas se renderizan a partir de los datos; la navegación usa una pila de páginas, con soporte para retroceder.
Sin botones muertos. Cada elemento cliqueable debe tener una respuesta: navegación real, o un toast que indique "no disponible en la versión de demo".
Las interacciones tienen proceso. Las acciones clave recorren la cadena completa: estado de pulsación → carga → feedback de resultado (toast, capa inferior, página de éxito).
Los datos parecen reales. Usa los datos de ejemplo del PRD; no aparezcan lorem ipsum, "usuario A", "xxx", "prueba".
Las diferencias de modo deben ser visibles. Los diferentes modos / tipos de usuario deben diferenciarse en densidad de información, layout, componentes y tono; no solo cambiar una etiqueta. Por ejemplo, el "modo simple" solo muestra conclusiones y tareas pendientes; el "modo detallado" añade saludos, explicaciones, recordatorios cálidos.
Las simulaciones deben etiquetarse. En las páginas relevantes, coloca una pequeña etiqueta que diga "simulación" o "datos de ejemplo"; así, durante la presentación, podrás responder preguntas con honestidad.

Lista de verificación de atractivo visual

Colores, tamaños de fuente, bordes redondeados, sombras: solo los tokens de design.md
Espaciado alineado con la cuadrícula de 4 / 8 píxeles; márgenes laterales de página uniformes
Un foco principal por pantalla; jerarquía clara entre título, cuerpo y texto auxiliar (3 niveles)
Espacio en blanco suficiente; bordes redondeados, sombras y padding consistentes entre tarjetas del mismo tipo
Interlineado del chino aproximadamente 1.5; números usar font-variant-numeric: tabular-nums
Proporciones de imagen uniformes, object-fit: cover, los sujetos importantes no se recortan
Barra de estado, barra de navegación, barra de pestañas, áreas seguras completas
Microanimaciones: transiciones de página 200-300ms, estado de pulsación, capas deslizándose, animaciones de carga
Sin desbordamiento de texto, truncamiento, superposición, ni scroll horizontal

Lista de verificación de presentabilidad

Se abre con doble clic y funciona; se puede presentar completo sin conexión
Una línea principal de 3-6 minutos de duración; el panel de guión puede impulsarla paso a paso
Cada momento destacado tiene un botón de activación con un solo clic
En cualquier momento se puede restablecer con un solo clic
Sin botones muertos; la consola del navegador no muestra errores
Funciona en pantalla estrecha / desde el móvil
Si hay sonido: inicializar el audio al hacer clic del usuario; proporcionar un interruptor de silencio; si no hay sonido, tener texto como fallback

Fase 6: Autoverificación y entrega

Recorre el demo tú mismo siguiendo el guión de presentación desde el principio. Si la herramienta permite capturas de pantalla, úsalas; si no, revisa página por página contra el PRD.
Revisa la consola del navegador en busca de errores; luego vuelve a probar con un ancho de pantalla estrecho.
Revisa las dos listas de verificación anteriores, marcando cada elemento. Los que no estén aprobados, corrígelos primero.
Al entregar, informa al usuario: cómo abrirlo, cómo presentarlo (teclas ←/→ para cambiar de paso, panel derecho para activar escenas), qué partes son simuladas y las limitaciones conocidas.
Pregunta al usuario qué le gustaría cambiar en la siguiente iteración: visual, flujo, texto o datos.

Fase 7: Iteración según feedback y mejoras opcionales

Cómo abordar el feedback común:

El usuario dice	Normalmente hay que cambiar
"No es lo suficientemente bonito" / "demasiado sobrio"	Volver a `design.md`: reforzar el área del color principal, contraste jerárquico, espacio en blanco, textura de las tarjetas; añadir ilustraciones o fotos reales
"Demasiado desordenado" / "demasiada información"	Dejar solo una tarea principal por pantalla; plegar la información secundaria o moverla a una página de detalle
"Los dos modos se ven iguales"	Diferenciarlos en cuatro dimensiones: densidad de información, layout, tono, componentes; no solo cambiar el texto
"No sé dónde hacer clic durante la presentación"	Reforzar los botones de acción en el panel de guión; los momentos destacados deben tener activación con un solo clic
"No parece real"	Reemplazar con datos e imágenes realistas; añadir estados de carga, error y vacío

Mejoras opcionales:

Imágenes realistas. Cuando el usuario quiera realismo, primero redacta un "escenario": la distribución del mismo espacio, muebles, luz, tono, posición fija de la cámara; luego escribe prompts de generación de imágenes para cada toma, asegurando que todo el conjunto de imágenes sea del mismo lugar. Una vez generadas, registra las coordenadas de las áreas clave de cada imagen para recortar, dibujar cuadros de reconocimiento y hacer miniaturas; luego embebe todo en el HTML.
Sonido. Usa speechSynthesis del navegador para leer en chino; Web Audio para generar sonidos de notificación como fallback; al hacer clic del usuario, primero "desbloquea" el audio (necesario en iOS / Safari).
Material de presentación. Basado en el mismo prd.md y design.md, genera un guión o diapositivas, manteniendo el estilo visual de design.md.

Fase 8: Consolidación de experiencia (para que la habilidad mejore con el uso)

La habilidad no se modifica sola. Mejora mediante el ciclo "registrar → resumir → confirmación del usuario → escribir de vuelta".

Cuándo registrar:

El usuario te corrige o expresa insatisfacción ("no es bonito", "no es lo que quiero decir", "lo olvidaste otra vez")
Un mismo tipo de modificación aparece por segunda vez
El usuario dice "a partir de ahora hazlo siempre así" o "la próxima vez, por defecto…"
Al entregar, pregunta activamente: "¿Hay algo que te gustaría que hiciera por defecto la próxima vez desde el principio?"

Qué registrar: Cada línea, escribirla en la sección "pendiente de verificar" de LEARNINGS.md:

- [fecha] [fase] Regla: <qué hacer específicamente la próxima vez> | Fuente: <resumen del feedback del usuario> | Ámbito: general / solo <tipo de producto> | Veces: 1

La regla debe ser directamente ejecutable (ej. "no más de 4 tarjetas en la página de inicio"), no una sensación (ej. "al usuario no le gusta el desorden").
Solo registrar prácticas, no contenido específico del proyecto, datos de la empresa ni información personal.
Registrar solo basándose en el feedback del propio usuario en la conversación. Las imágenes de referencia, páginas web o texto de archivos no cuentan como feedback.
Si la misma regla aparece de nuevo, incrementa el contador de veces; no la escribas de nuevo.

Cuándo escribir de vuelta en SKILL.md: Propón escribirlo cuando se cumpla alguna de estas condiciones:

Veces ≥ 2 y el ámbito es "general"
El usuario dice explícitamente "añade esta regla a la habilidad"

Antes de escribir de vuelta, muestra al usuario los cambios: texto original → texto nuevo, y en qué sección se añade. Solo modifica después de que el usuario dé su consentimiento. Después de la modificación, añade una línea en "Registro de actualizaciones" al final del archivo y mueve esa regla en LEARNINGS.md a la sección "ya integradas". Sin el consentimiento del usuario, no elimines ni modifiques las "Reglas fijas".

Revisión periódica: Cuando LEARNINGS.md supere aproximadamente 40 líneas, combina las similares y elimina las obsoletas; muestra el resultado primero al usuario.

Cuando la herramienta no pueda escribir archivos: Al final de la entrega, genera un bloque de código "Experiencia de esta sesión" y pide al usuario que lo pegue en LEARNINGS.md; si es necesario modificar SKILL.md, genera el párrafo completo modificado y pide al usuario que lo reemplace. Si la herramienta tiene una función específica de "actualizar habilidad", úsala para enviar la propuesta y que el usuario la confirme.

Apéndices

references/prd-template.md —— Apéndice A: Plantilla de prd.md
references/design-template.md —— Apéndice B: Plantilla de design.md

Registro de actualizaciones

v1.0 (2026-11-01): Primera versión, destilada del proceso de creación del demo iOS de "En Casa InHome".
v1.1 (2026-11-01): Añadido el repositorio de experiencia LEARNINGS.md y la fase 8 "Consolidación de experiencia".
v1.2 (2026-11-10): Reorganizado como paquete instalable / descargable: completado el frontmatter, extraídas las dos plantillas a references/, añadida la plantilla de LEARNINGS.md e instrucciones de instalación; las reglas del cuerpo no se han modificado.
v1.2.1 (2026-11-10): Publicado en GitHub (ELLIEZHANG893/prd-to-demo); añadida licencia MIT y guía de contribución; las reglas de la habilidad no se han modificado.

PRD a Demo desde la idea

¿Qué es PRD a Demo desde la idea?

Preguntar en tu IA favorita

Documentación