mingdui/AI-Product-Skills

Skill de Prototipado de Alta Fidelidad para Frontend (Product Manager)

1. Objetivo

Crear prototipos de alta fidelidad, cliqueables y aislados de la funcionalidad real, directamente sobre el código fuente de un proyecto frontend existente, para que el gerente de producto pueda visualizar, demostrar y discutir propuestas de producto rápidamente.

Priorizar:

• Coherencia visual con el proyecto existente.
• Que la página se vea como un producto real, no como un demo temporal.
• Uso de datos simulados que se ajusten al negocio.
• Que el flujo principal sea cliqueable.
• Que la interacción pueda servir para la revisión de requisitos.
• Que la página sea fácil de modificar posteriormente.
• Que se pueda ejecutar y previsualizar localmente de inmediato.
• Que, por defecto, no afecte las páginas y rutas de negocio en uso.

A menos que el usuario lo solicite explícitamente, no abordar la tarea como una reimplementación completa del sistema desde cero.

Cuando el objetivo es un prototipo de alta fidelidad, no priorizar el desarrollo de interfaces de backend, cadenas de datos de producción o arquitecturas complejas.

Convenio de aislamiento por defecto: Reutilizar primero el código fuente, el layout, los componentes y las reglas visuales del proyecto existente, y luego implementar el prototipo en páginas, rutas o directorios funcionales independientes. No modificar por defecto las páginas de negocio en uso, las entradas de producción o las llamadas a APIs existentes; solo se debe hacer si el usuario solicita explícitamente "demostrar directamente en la página original" o "superponer el prototipo sobre la página existente".

---

2. Escenarios de Aplicación

Usar esta Skill cuando el usuario solicite:

• Crear páginas o rutas de prototipo independientes basadas en el código fuente de un proyecto React, Vue, HTML u otro frontend existente.
• Demostrar interacciones del prototipo en páginas de producto existentes (si el usuario lo solicita explícitamente).
• Agregar páginas de administración, CRM, SaaS, panel de operaciones o estaciones de trabajo.
• Convertir páginas estáticas en prototipos cliqueables.
• Añadir datos simulados y estados de interacción realistas.
• Añadir u optimizar tablas, formularios, filtros, pestañas, drawers, modales, gráficos, páginas de detalle o flujos de negocio.
• Extender nuevas funcionalidades siguiendo el estilo del proyecto existente.
• Completar un demo de alta fidelidad para revisión sin desarrollar backend.
• Optimizar la jerarquía visual, la densidad de información, el diseño responsivo o la retroalimentación interactiva.

Expresiones comunes:

• Añadir una página de lista de clientes en el panel de administración existente.
• Añadir un panel de indicadores de negocio según el estilo del proyecto actual.
• Añadir un módulo de registro de seguimiento en una página de detalle existente.
• Completar esta página para que sea un prototipo cliqueable.
• Añadir interacciones de búsqueda, filtrado, cambio de estado, drawer y modal.
• Optimizar esta página existente sin cambiar el estilo general del sistema.

---

3. Escenarios No Aplicables

No usar esta Skill por defecto en los siguientes casos:

• El usuario desea crear un producto completamente nuevo desde un directorio vacío.
• El usuario solo necesita un sitio web de marketing o una landing page.
• El usuario solicita desarrollar interfaces de backend, bases de datos o servicios de producción.
• El usuario necesita documentación de arquitectura técnica, no un prototipo.
• El usuario solo solicita generar imágenes visuales o capturas de pantalla estáticas.
• La tarea actual es principalmente análisis de requisitos o redacción de un PRD.

Si el directorio actual está vacío, se debe explicar que esta Skill está orientada a proyectos existentes y priorizar el uso de la "Skill de Prototipado de Alta Fidelidad desde HTML en Blanco".

---

4. Principios Fundamentales

4.1. Revisar el Proyecto Antes de Comenzar el Diseño

No escribir código inmediatamente después de recibir el requisito.

Primero, buscar en docs/product/ la línea base de experiencia de producto correspondiente al proyecto y al frontend actual (c-end/ o admin/). Si existe, leer la terminología de producto, la navegación, los patrones de página y las reglas visuales e interactivas; complementa las convenciones técnicas del código fuente del proyecto, pero no reemplaza la biblioteca de componentes, el enrutamiento ni la arquitectura de datos.

Si el usuario está iniciando la primera versión de los requisitos, o si la funcionalidad actual expone reglas de producto que se repiten en varias páginas pero que aún no están definidas, se recomienda usar product-experience-foundation. Los prototipos de una sola funcionalidad no deben crear ni reescribir líneas base globales de producto sin autorización.

Revisar en el proyecto existente:

• Páginas adyacentes.
• Framework de layout de página.
• Estructura de rutas.
• Directorio de componentes.
• Hooks y funciones de utilidad públicas.
• Variables CSS.
• Archivos de tema.
• Tokens de diseño.
• Forma de uso de iconos.
• Estilos de tablas.
• Estilos de formularios.
• Estilos de modales y drawers.
• Estilos de mensajes y notificaciones.
• Método actual de gestión de estado.

Es necesario comprender del proyecto existente:

• Densidad de información.
• Espaciado entre páginas.
• Jerarquía tipográfica.
• Tamaño de los bordes redondeados.
• Forma de uso de colores.
• Estructura de navegación.
• Forma de invocación de componentes.
• Estrategia de diseño responsivo.

El contenido nuevo debe parecer una extensión natural del sistema existente, no un sistema completamente nuevo.

4.2. Priorizar la Reutilización, No Reinventar la Rueda

Reutilizar prioritariamente lo que ya existe en el proyecto:

• Botones.
• Tablas.
• Formularios.
• Selectores desplegables.
• Selectores de fecha.
• Pestañas.
• Modales.
• Drawers.
• Paginación.
• Etiquetas de estado.
• Mensajes de notificación.
• Componentes de layout de página.
• Iconos.
• Funciones de utilidad.
• Hooks.
• Tokens de diseño.

Si el proyecto existente ya tiene las capacidades correspondientes, no crear un segundo sistema de componentes.

4.3. Aislar la Entrada del Prototipo por Defecto

El prototipo debe implementarse basándose en el código fuente existente, no copiando un sitio web estático que esté fuera del proyecto; al mismo tiempo, debe estar aislado de la entrada de negocio real por defecto.

Priorizar una de las siguientes formas que el proyecto existente ya soporte:

• Rutas de prototipo independientes, por ejemplo /__prototype/<funcionalidad> o la convención de rutas demo existente en el proyecto.
• Páginas de prototipo independientes o directorios funcionales, exponiendo la entrada solo en el entorno de desarrollo/previsualización.
• Entradas de prototipo explícitas que no alteren el comportamiento predeterminado de la página original, como parámetros de consulta, menús de desarrollo o elementos de navegación temporales.

La entrada del prototipo debe poder reutilizar el shell de página real y los componentes, pero por defecto no debe reemplazar la entrada en línea, modificar los datos comerciales existentes ni afectar otras funcionalidades. Si el proyecto ya tiene convenciones de prototipado, se deben seguir prioritariamente; si no las hay, elegir la forma que tenga el menor impacto en el código de producción y que sea fácil de eliminar, e indicar la ubicación de la entrada en la respuesta final.

4.4. Tratar la Tarea como un Prototipo de Producto, No como una Reestructuración Real

Priorizar:

• Revisión de producto.
• Demostración de negocio.
• Discusión de requisitos.
• Alineación entre diseño y desarrollo.
• Iteración rápida.

Usar formas de implementación directas y fáciles de modificar.

A menos que el proyecto existente ya utilice los patrones correspondientes, no introducir:

• Reestructuraciones globales a gran escala.
• Nuevas capas de arquitectura.
• Dependencias pesadas.
• Abstracciones excesivas.
• Máquinas de estado complejas.

4.5. Usar Datos Simulados, No Apresurarse a Desarrollar el Backend

A menos que el usuario lo solicite explícitamente, no:

• Conectar a APIs reales.
• Diseñar APIs de backend.
• Crear capas de servicio.
• Manejar cadenas de datos de producción.

Los datos simulados deben colocarse lo más cerca posible de la página o funcionalidad actual para que el gerente de producto pueda ajustarlos fácilmente.

Usar estado local para simular:

• Creación.
• Edición.
• Eliminación.
• Búsqueda.
• Filtrado.
• Ordenación.
• Cambio de pestañas.
• Selección.
• Cambio de estado.
• Apertura de drawer.
• Apertura de modal.
• Envío de formulario.
• Confirmación secundaria.
• Mensaje de éxito.
• Mensaje de error.

4.6. El Prototipo Debe Ser Cliqueable

Además del flujo principal, también se deben complementar, según los requisitos, los estados que el gerente de producto necesita revisar:

• Búsqueda.
• Filtrado.
• Pestañas.
• Selección.
• Vista de detalle.
• Estado vacío.
• Estado de carga.
• Validación de formulario.
• Estado deshabilitado.
• Confirmación secundaria.
• Retroalimentación de éxito.
• Retroalimentación de error.
• Ruta de retorno.
• Navegación de varios pasos.

Si el requisito incluye varios pasos, el flujo debe poder navegarse completamente, no dejar varias páginas estáticas no relacionadas.

4.7. No Convertir un Sistema de Negocio en un Sitio Web de Marketing

Cuando el usuario necesita una aplicación, herramienta, panel de administración, CRM, sistema de operaciones o estación de trabajo:

• No crear un titular enorme en la primera pantalla.
• No priorizar una composición visual de marketing.
• No usar grandes cantidades de degradados decorativos y fondos como elemento visual principal.
• No reducir significativamente la densidad de información por el bien de la apariencia.
• No reemplazar los controles de negocio reales con tarjetas de marketing.

---

5. Análisis a Realizar Antes de Codificar

Antes de comenzar a escribir código, extraer de los requisitos y del proyecto:

• Objetivo del producto.
• Usuarios o roles objetivo.
• Tareas principales que el usuario necesita completar.
• Páginas a añadir o modificar.
• Páginas similares existentes.
• Entrada de la página.
• Flujo principal del usuario.
• Campos necesarios.
• Estados necesarios.
• Diferencias de permisos entre roles.
• Interacciones que deben implementarse.
• Necesidades de datos simulados.
• Suposiciones de producto.
• Reglas de negocio aún no definidas.

No preguntar repetidamente información que el usuario ya ha proporcionado.

Si solo faltan detalles de la capa de presentación, se pueden usar suposiciones razonables.

No se deben añadir, sin autorización, reglas de negocio principales que cambien el alcance del producto.

---

6. Proceso de Revisión del Proyecto

Paso 1: Identificar la Pila Tecnológica

Confirmar:

• Framework frontend.
• Herramienta de compilación.
• Método de enrutamiento.
• Biblioteca de componentes UI.
• Biblioteca de iconos.
• Esquema de estilos.
• Método de gestión de estado.
• Convenciones de solicitud de datos.
• Método de prueba o previsualización.

Paso 2: Buscar Páginas Similares

Buscar prioritariamente:

• Páginas de lista del mismo tipo.
• Páginas de detalle del mismo tipo.
• Formularios del mismo tipo.
• Paneles de datos del mismo tipo.
• Modales o drawers del mismo tipo.
• Flujos de negocio del mismo tipo.
• Estados vacíos, de carga y de error del mismo tipo.

Usar estas páginas como referencia para la implementación de la nueva página.

Paso 3: Identificar Contenido Reutilizable

Listar lo que se debe reutilizar en esta ocasión:

• Componentes.
• Hooks.
• Tokens de diseño.
• Funciones de utilidad.
• Layout de página.
• Formas de interacción.

Evitar reimplementar capacidades ya existentes.

Paso 4: Comprender el Sistema Visual Existente

Revisar:

• Ancho de página.
• Relleno interior de la zona de contenido.
• Espaciado entre módulos.
• Jerarquía tipográfica.
• Estilo de botones.
• Densidad de formularios.
• Densidad de tablas.
• Colores de estado.
• Estilo de bordes.
• Uso de sombras.
• Puntos de interrupción responsivos.

Paso 5: Determinar el Alcance del Prototipo

Definir:

• Dónde se colocará la entrada del prototipo y cómo estará aislada de la entrada de negocio real.
• Páginas o módulos de prototipo que deben añadirse.
• Si el usuario ha solicitado explícitamente modificar páginas de negocio existentes.
• Qué interacciones deben ser cliqueables.
• Qué datos se simularán.
• Qué estados deben estar representados.
• Qué suposiciones de producto son necesarias.
• Qué patrones de página a nivel de producto reutiliza la funcionalidad actual.
• Qué nuevos patrones están limitados solo a la funcionalidad actual y cuáles podrían ser candidatos para una estandarización futura.

---

7. Estándar de Datos Simulados

Los datos simulados deben usar lenguaje de negocio real.

Evitar el uso de:

• Test User.
• Lorem ipsum.
• Company A.
• Sample Data.
• User 001.

Los datos simulados deben cubrir, en la medida de lo posible:

• Diferentes estados.
• Texto largo.
• Valores faltantes.
• Mensajes de advertencia.
• Datos límite.
• Diferentes decisiones de usuario.
• Diferentes etapas del negocio.
• Resultados vacíos.
• Acciones deshabilitadas.

El propósito de los datos simulados no es llenar la página, sino ayudar al gerente de producto a descubrir problemas en la página y en la interacción.

---

8. Reglas para Suposiciones de Producto

La IA puede complementar razonablemente los detalles de la capa de presentación, por ejemplo:

• Nombres de ejemplo.
• Fechas de ejemplo.
• Datos de lista de ejemplo.
• Texto de estado vacío.
• Mensajes de éxito y error.
• Condiciones de filtro comunes.
• Formas de interacción acordes con los hábitos del proyecto existente.

La IA no debe complementar, sin decirlo, la siguiente lógica de negocio principal:

• Nuevos estados de negocio.
• Nuevos roles y permisos.
• Nuevas reglas de aprobación.
• Nuevos métodos de cálculo de negocio.
• Nuevos módulos de gestión.
• Nuevo alcance del producto.
• Nuevas dependencias de sistemas externos.

Si es necesario hacer suposiciones para la demostración, se deben indicar explícitamente en la respuesta final.

Si la nueva interacción entra en conflicto con la línea base de experiencia de producto, no se debe sobrescribir silenciosamente. Se debe seguir la línea base confirmada, o listar la razón del desvío y si es necesario "reescribir la línea base" como elementos a confirmar.

---

9. Estándares de UI e Interacción

9.1. Arquitectura de la Información

Priorizar:

• Jerarquía clara.
• Agrupación lógica.
• Selección de campos efectiva.
• Acciones principales visibles.
• Densidad de información estable.
• Página fácil de escanear.

9.2. Selección de Controles

Usar preferentemente controles familiares para el usuario:

• Acciones de herramientas con botones de icono.
• Cambio de modo con control segmentado.
• Configuración binaria con interruptor o casilla de verificación.
• Configuración numérica con campo de entrada, deslizador o stepper.
• Opciones múltiples con menú o desplegable.
• Vistas del mismo nivel con pestañas.
• Tareas secundarias con drawer o modal.

9.3. Uso de Tarjetas

No anidar tarjetas dentro de tarjetas.

Las tarjetas son adecuadas para:

• Elementos de lista repetidos.
• Modales.
• Drawers.
• Herramientas independientes.
• Grupos de datos que necesitan un marco definido.

No envolver cada bloque de la página en una tarjeta.

9.4. Control de Decoración

Evitar:

• Degradados decorativos con halos de luz.
• Círculos flotantes.
• Efectos de bokeh.
• Decoraciones SVG sin significado.
• Fondos puramente ambientales.
• Pantallas de inicio al estilo marketing.
• Páginas llenas de un solo tono de color.

Después de implementar, revisar el CSS. Si la página se reduce casi a una sola gama de colores, ajustar adecuadamente.

Poner especial atención en evitar:

• Grandes áreas de degradado púrpura o azul-púrpura.
• Grandes áreas de color beige o arena.
• Grandes áreas de azul oscuro o gris-azul.
• Grandes áreas de marrón o naranja.

9.5. Estabilidad del Texto y el Layout

Asegurar que el texto se adapte a:

• Botones.
• Celdas de tabla.
• Tarjetas.
• Barra lateral.
• Drawers.
• Modales.
• Contenedores móviles.

Usar según sea necesario:

• Ajuste de línea automático.
• Truncamiento de texto.
• Anchos mínimos y máximos.
• Cuadrícula estable.
• aspect-ratio.
• Dimensiones relativas al contenedor.

No escalar dinámicamente la fuente según el ancho de la ventana.

A menos que el sistema de diseño existente lo requiera, mantener el espaciado entre letras en 0.

9.6. No Explicar el Prototipo Dentro de la Interfaz de Producto

No mostrar las siguientes explicaciones en la página:

• Cómo se hizo este prototipo.
• Qué soluciones temporales se utilizaron.
• Cómo debe entender el revisor la página.
• Qué interacciones son simuladas.

Agregar explicaciones dentro de la interfaz solo si el producto en sí mismo necesita contenido de ayuda.

---

10. Alcance del Diseño Responsivo

Sistemas de Administración de Escritorio

Si el proyecto es claramente un sistema de administración de escritorio:

• Priorizar que la versión de escritorio esté bien hecha.
• Mantener una densidad de información estable.
• Asegurar que no se rompa por completo en pantallas pequeñas.
• Evitar que las operaciones clave sean inaccesibles.
• Evitar el desplazamiento horizontal innecesario en la medida de lo posible.

Móvil o Productos de Consumo

Si el producto está orientado al consumidor, es mobile-first, o el usuario solicita explícitamente versión móvil:

• Diseñar con el mismo cuidado el layout y la interacción móvil.
• Revisar el tamaño de las áreas de clic.
• Revisar el recorte de controles.
• Revisar elementos con posicionamiento fijo.
• Revisar los espacios de seguridad.
• Revisar el comportamiento del teclado y los formularios según sea necesario.

Todas las Páginas Deben Revisar

• Superposición de texto.
• Recorte de controles.
• Entrada de acciones oculta.
• Puntos de quiebre en la navegación de la página.
• Desbordamiento horizontal.
• Tablas ilegibles.
• Drawers o modales inutilizables.

---

11. Proceso de Implementación

Paso 1: Leer el Proyecto Existente

Revisar la estructura del proyecto relevante y las páginas similares.

Paso 2: Definir la Entrada y el Alcance del Prototipo

Organizar:

• Ubicación de la página, ruta o directorio funcional del prototipo.
• Forma de aislamiento de la entrada de negocio real.
• Páginas o módulos existentes que se modificarán solo si el usuario lo solicita explícitamente.
• Flujo principal del usuario.
• Interacciones que deben implementarse.
• Estados de datos simulados.
• Componentes reutilizables.

Paso 3: Implementar el Prototipo Independiente Siguiendo las Formas del Proyecto Existente

Mantener la:

• Pila tecnológica.
• Sistema de componentes.
• Forma de estilos.
• Forma de enrutamiento.
• Iconos.
• Funciones de utilidad.
• Hábitos de gestión de estado.

Paso 4: Añadir Datos Simulados e Interacciones

Usar estado local para implementar el flujo completo necesario para esta revisión.

Paso 5: Complementar los Estados Necesarios

Añadir solo los estados relevantes para la funcionalidad actual:

• Estado vacío.
• Estado de carga.
• Estado de validación.
• Estado deshabilitado.
• Estado de éxito.
• Estado de error.
• Confirmación secundaria.
• Estado sin permisos.
• Estado de datos no disponibles.

Paso 6: Ejecutar el Proyecto Realmente

Iniciar el servicio de desarrollo local existente cuando sea necesario.

No declarar la tarea como completada antes de que el proyecto se pueda previsualizar.

Paso 7: Realizar una Revisión Visual y de Interacción

Revisar:

• La página no está en blanco.
• Los estilos se cargan correctamente.
• Los iconos y recursos se muestran correctamente.
• El texto no tiene desbordamientos evidentes.
• El layout no tiene saltos anormales.
• Las interacciones principales funcionan.
• La navegación no tiene callejones sin salida.
• El comportamiento responsivo es aceptable.

Si es posible, usar la inspección del navegador o capturas de pantalla para verificar.

---

12. Entregables Finales

Según la situación real de la tarea, el resultado final debe incluir:

• Código fuente frontend añadido o modificado.
• Página, directorio funcional o ruta de prototipo independiente, con instrucciones de entrada.
• Páginas de negocio existentes modificadas solo si el usuario lo solicitó explícitamente.
• Componentes públicos reutilizados.
• Datos simulados locales.
• Interacciones principales cliqueables.
• Estados relevantes de vacío, carga, validación, deshabilitado, éxito y error.
• Navegación de página que funcione correctamente.
• Instrucciones para ejecutar o previsualizar el proyecto.
• Explicación de las suposiciones de producto.
• Lista de reglas de negocio aún no definidas.
• Si se crea un demo.md, registrar las conclusiones de la revisión y los elementos pendientes de confirmar; sirve solo como marcador de transferencia, no reemplaza los artefactos de ingeniería del proyecto.

No crear documentación o archivos de arquitectura adicionales a menos que sean útiles para la ejecución o la revisión.

---

13. Criterios de Finalización

El prototipo se considera completo cuando se cumplan las siguientes condiciones:

• La página o módulo del prototipo ya existe en el proyecto actual y está aislado de la entrada de negocio real (a menos que el usuario haya solicitado explícitamente reemplazar la entrada original).
• El estilo visual es coherente con el proyecto existente.
• Se han reutilizado correctamente los componentes y tokens de diseño existentes.
• El flujo principal del usuario se puede recorrer de principio a fin.
• Cada operación principal tiene una retroalimentación clara.
• La navegación de la página no tiene callejones sin salida.
• Los datos simulados se actualizan después de las operaciones clave.
• Los estados de página relevantes están representados.
• El texto no tiene desbordamientos evidentes.
• El proyecto se ejecuta localmente sin errores bloqueantes.
• No se ha ampliado el alcance del producto ya confirmado sin autorización.
• La respuesta final explica claramente las suposiciones de producto y las reglas pendientes de confirmar.

---

14. Requisitos de la Respuesta Final

Después de completar, explicar de manera que el gerente de producto pueda entender fácilmente:

• Qué páginas, módulos y flujos se han añadido o modificado.
• La ubicación de la entrada del prototipo y cómo está aislada de la entrada de negocio real.
• Qué interacciones son cliqueables.
• Qué datos simulados y estados de página se han añadido.
• Qué componentes y normas del proyecto existentes se han reutilizado.
• Qué suposiciones de producto se han hecho.
• Qué reglas de negocio aún están pendientes de confirmar.
• Cómo ejecutar o previsualizar el prototipo.
• Qué revisiones visuales y de interacción se han completado.
• Qué líneas base de experiencia de producto se han reutilizado; si aparece un nuevo patrón repetido, explicar si es solo un candidato y, mientras no se confirme, no se debe extraer como regla global.
• Después de la revisión, el desarrollo implementará según el prototipo; no se deben falsificar artefactos de ingeniería en la fase de prototipo ni implementar código de producción sin autorización.

La respuesta final debe ser concisa y centrarse en lo que el gerente de producto necesita revisar.