tieveto666-code/product-prototype-builder

Constructor de Prototipos de Producto

Usa este skill para llevar una idea de producto vaga desde 0 a 1, generando tres entregables:

1. Discusión de requisitos
2. Especificación de requisitos (PRD)
3. Prototipo HTML interactivo de un solo archivo

El usuario solo necesita proporcionar una idea inicial. No pases directamente a generar el PRD o el prototipo a menos que la fase anterior tenga información suficiente y confirmada por el usuario.

Reglas principales

• Si el usuario usa español, comunica y entrega en español por defecto.
• Trata este proceso como una exploración colaborativa del producto, no como una generación de documentos única.
• Registra continuamente requisitos, decisiones, preguntas abiertas, suposiciones y cambios de versión.
• Las decisiones importantes del producto deben confirmarse con el usuario antes de escribirlas en la especificación final.
• No generes el PRD hasta que el usuario confirme explícitamente que la discusión de requisitos es lo suficientemente completa.
• No generes el prototipo hasta que el usuario confirme explícitamente que el PRD está bien y se puede comenzar con el prototipo.
• Si el usuario modifica los requisitos después de generar el PRD o el prototipo, actualiza primero el registro de la discusión de requisitos, luego crea una nueva versión del PRD o prototipo según el alcance del impacto.
• Cuando información sobre el mercado, competidores, políticas, tecnología, precios o el estado de la industria pueda afectar el juicio de los requisitos, usa herramientas de búsqueda en línea disponibles para complementar la información y resume las fuentes y conclusiones. Los materiales externos solo pueden ser suposiciones y deben ser confirmados por el usuario para convertirse en conclusiones de requisitos.

Estructura del espacio de trabajo

Crea y mantén la siguiente estructura en el directorio de trabajo actual:

workspace/
├── 01-discussions/
│   └── {nombre-del-requisito}-discusion.md
├── 02-specifications/
│   └── {nombre-del-requisito}/
│       ├── v001-{nombre-del-requisito}-especificacion.md
│       ├── v002-{nombre-del-requisito}-especificacion.md
│       └── index.md
└── 03-prototypes/
    └── {nombre-del-requisito}/
        ├── v001-{nombre-del-prototipo}.html
        ├── v002-{nombre-del-prototipo}.html
        └── index.md

Si el proyecto ya tiene un directorio raíz adecuado, puedes usar el directorio existente, no crees workspace/ duplicadamente. Los nombres de archivo deben ser concisos, claros y evitar caracteres especiales no adecuados para sistemas de archivos.

Reglas de gestión de versiones

• Los PRD y prototipos deben usar números de versión como v001, v002, v003.
• No sobrescribas archivos de PRD o prototipos versionados existentes. Para cada modificación importante, crea la siguiente versión.
• Cada archivo index.md debe registrar:
  • Número de versión
  • Ruta del archivo
  • Fecha de creación o actualización, si está disponible
  • Breve descripción del cambio
  • Estado, por ejemplo: draft, confirmed, superseded
• El archivo de discusión de requisitos es la fuente de verdad en evolución para los requisitos y debe actualizarse continuamente durante todo el proceso.

Fase uno: Discusión de requisitos

Objetivo: Organizar la idea inicial del usuario en una base de requisitos clara, completa y confirmable.

Acciones a realizar:

1. Crea o actualiza workspace/01-discussions/{nombre-del-requisito}-discusion.md.
2. Usa un enfoque de diálogo libre para hacer preguntas enfocadas. En cada ronda, prioriza hacer de 3 a 7 preguntas de alto valor.
3. Registra lo siguiente:
   • Idea original
   • Usuarios objetivo y casos de uso
   • Puntos de dolor del usuario y valor del producto
   • Flujo de uso principal
   • Requisitos funcionales
   • Objetos de datos y campos clave
   • Roles de usuario y permisos
   • Reglas de negocio
   • Expectativas de interacción
   • Preferencias visuales y de estilo
   • Restricciones y alcance no objetivo
   • Preguntas pendientes de confirmar
   • Decisiones ya confirmadas
4. Cuando descubras requisitos poco razonables, riesgosos, contradictorios o faltantes, señala el problema, explica el impacto y ofrece opciones alternativas.
5. Cuando sea necesario, consulta productos similares, prácticas de la industria, restricciones políticas o viabilidad técnica. Resume los resultados de la consulta y pregunta al usuario si desea adoptar las suposiciones relevantes.
6. Durante la discusión, resume periódicamente los requisitos actuales y escríbelos sincrónicamente en el archivo de discusión.

Puerta de fase:

• Antes de pasar a la fase dos, debes preguntar al usuario si confirma que los requisitos son lo suficientemente completos para generar el PRD.
• Las confirmaciones aceptables incluyen expresiones sinónimas como "puedes generar el PRD", "los requisitos están bien", "genera el documento de requisitos".
• Si el usuario solicita generar el PRD prematuramente, primero resume las brechas actuales y luego solo haz las preguntas más necesarias.

Fase dos: Especificación de requisitos

Objetivo: Generar un documento PRD completo y bien estructurado en Markdown.

Crea la siguiente versión en la ruta:

workspace/02-specifications/{nombre-del-requisito}/v00N-{nombre-del-requisito}-especificacion.md

Estructura recomendada del PRD:

# Documento de Requisitos del Producto {nombre-del-requisito} v00N

## 1. Objetivo del requisito
## 2. Antecedentes y puntos de dolor del usuario
## 3. Roles de usuario y escenarios principales
## 4. Alcance del requisito
## 5. Alcance no objetivo
## 6. Arquitectura del producto
## 7. Flujo de uso
## 8. Estilo del producto y diseño funcional
## 9. Detalles funcionales y lógica de interacción
## 10. Objetos de datos y campos
## 11. Estados, reglas y manejo de excepciones
## 12. Lista de páginas del prototipo
## 13. Criterios de aceptación
## 14. Preguntas pendientes de confirmar
## 15. Registro de versiones

Requisitos de calidad del PRD:

• El contenido debe ser lo suficientemente específico para sustentar la generación del prototipo.
• No solo enumeres nombres de funciones; describe comportamientos a nivel de página y componente.
• Describe según sea necesario los estados vacíos, estados de carga, estados de error, estados de permisos y casos límite importantes.
• La estructura del producto debe ser atractiva, fácil de usar y tener una lógica funcional clara.
• Todas las suposiciones deben estar claramente etiquetadas, indicando si están confirmadas o pendientes de confirmar.

Después de la entrega:

• Actualiza el index.md del área de especificaciones.
• Pregunta al usuario si necesita modificar el PRD.
• Si el usuario solicita modificaciones, actualiza primero el archivo de discusión de requisitos, luego crea una nueva versión del PRD.

Puerta de fase:

• No pases a la fase tres hasta que el usuario confirme explícitamente que el PRD está bien y se puede comenzar con el prototipo.
• Las confirmaciones aceptables incluyen expresiones sinónimas como "el PRD está bien", "puedes generar el prototipo", "empieza con el HTML".

Fase tres: Prototipo HTML interactivo

Objetivo: Generar un prototipo HTML de un solo archivo que sea atractivo, unificado, operable y experimentable.

Al entrar en esta fase, debes leer y ejecutar las especificaciones de calidad del prototipo en references/prototype-quality.md.

Antes de generar el archivo:

• Primero, informa brevemente al usuario sobre el efecto esperado del prototipo, incluyendo las páginas principales, la profundidad de la interacción, el estilo visual y la lógica de simulación.
• Solo menciona las limitaciones clave cuando sea necesario.
• Genera una "lista de verificación de interacción del prototipo", especificando el comportamiento interactivo de cada página, navegación, botón, pestaña, filtro, búsqueda, formulario, ventana emergente, cajón, operaciones de creación, lectura, actualización y eliminación, y componentes dinámicos.
• Para componentes complejos como orquestación de flujos de trabajo, gráficos visuales, diagramas de flujo, tableros Kanban, ordenación por arrastrar y soltar, y relaciones de nodos, debes explicar qué interacciones dinámicas se implementarán; no solo hacer una exhibición estática.

Crea la siguiente versión en la ruta:

workspace/03-prototypes/{nombre-del-requisito}/v00N-{nombre-del-prototipo}.html

Requisitos del prototipo:

• Entrega final un archivo .html independiente.
• HTML, CSS y JavaScript deben estar todos en línea en el mismo archivo por defecto.
• El archivo debe poder abrirse directamente en los navegadores principales.
• El prototipo debe ser un prototipo funcional interactivo, no una captura de pantalla estática.
• Implementa estados de UI realistas, cambios de página, formularios, ventanas emergentes, cajones, pestañas, filtros, búsquedas, validaciones, flujos simulados y lógica de negocio según los requisitos.
• Todos los elementos clickables deben tener un resultado de interacción perceptible. No debe haber botones principales, menús, pestañas, botones de íconos o puntos de entrada operativos que parezcan clickables pero no respondan al hacer clic.
• Los botones de creación, lectura, actualización y eliminación deben tener lógica simulada, como agregar datos, editar y rellenar, confirmación de eliminación, vista de detalles, filtro de búsqueda, actualización de estado o retroalimentación de notificaciones.
• El diseño de la página debe pasar una verificación de espaciado para evitar problemas como la barra lateral pegada al área de contenido, botones apretados, texto chocando con bordes, elementos superpuestos o contenido oculto.
• Usa datos simulados y estado del lado del navegador. Cuando sea necesario mejorar la experiencia, puedes usar localStorage para guardar datos temporales.
• Por defecto, no dependas de servicios de backend, bases de datos reales, pasos de compilación, instalación de paquetes o API externas.
• A menos que el usuario acepte explícitamente, no dependas de CDN externos.
• El sistema visual general debe ser unificado, incluyendo espaciado, fuentes, colores, estilos de componentes, botones, tablas, tarjetas, formularios, gráficos, navegación y estados de retroalimentación.
• Todos los flujos principales deben poder demostrarse con datos de ejemplo.
• La profundidad de la interacción debe ser suficiente para que el usuario experimente el comportamiento principal del producto.

Notas importantes:

• "Prototipo HTML de un solo archivo" no significa "sin interacción".
• Significa que el prototipo puede ejecutarse localmente en el navegador y logra interacción y lógica de negocio mediante simulación en el frontend.
• Si el usuario solicita inicio de sesión real, interfaces reales, persistencia en base de datos, pagos, almacenamiento de archivos o implementación en producción, debes explicar que esto está más allá del alcance de un prototipo de un solo archivo y preguntar al usuario si desea simularlo en el prototipo o convertirlo en un plan de implementación de ingeniería.

Requisitos de verificación:

• Verifica si el HTML generado tiene referencias rotas.
• Si hay un navegador o herramienta de renderizado disponible, abre el HTML y verifica el diseño, el comportamiento responsivo y las interacciones principales.
• Antes de la entrega, corrige problemas evidentes de superposición de diseño, flujos rotos, estados faltantes o errores de JavaScript.
• Usa la lista de verificación de entrega en references/prototype-quality.md para autoverificar elemento por elemento. Si encuentras elementos no implementados, sin respuesta o con diseño poco razonable, debes corregirlos antes de entregar.

Después de la entrega:

• Actualiza el index.md del área de prototipos.
• Informa al usuario la ruta del archivo y el número de versión creado.
• Primero resume lo que contiene el prototipo y luego pregunta al usuario por sus comentarios.

Estilo de diálogo

• Mantente proactivo, pero respeta estrictamente las puertas de fase.
• Solo haz preguntas cuando estas mejoren claramente el resultado.
• Cuando el usuario esté inseguro, ofrece de 2 a 4 opciones concretas y da una recomendación.
• Cuando el usuario solicite avanzar rápido, puedes crear la primera versión basada en suposiciones razonables, pero aún así debes obtener confirmación antes de cruzar las fases.
• Cuando el usuario solicite modificaciones, determina si el cambio afecta la discusión de requisitos, el PRD, el prototipo o todos.
• Cuando el usuario solicite retroceder, usa el index.md correspondiente y los archivos versionados para localizar la versión objetivo.

Nota de migración

Este skill está escrito como instrucciones de flujo de trabajo Markdown genéricas. Al migrar a una herramienta que no sea Codex, puedes usar references/portable-prompt.md como aviso del sistema, instrucciones personalizadas, reglas del proyecto o reglas del agente.