Prototipo UIUX
Diseña interfaces de producto en torno a tareas reales. Entrega HTML revisable antes de la implementación de la aplicación. Trabaja en el idioma del usuario; por defecto usa explicaciones en español con términos técnicos en inglés cuando sea necesario. Esta habilidad es autónoma: las habilidades ascendentes y los servicios de referencia pagos son opcionales, no dependencias.
1. Establecer el producto y preservar su línea base
Primero lee los archivos AGENTS.md, HANDOFF.md, DESIGN.md existentes y los archivos de prototipo actuales. Identifica los usuarios, el escenario, la entrada, la tarea principal, el resultado, el valor empresarial, las superficies solicitadas y lo que está fuera de esta versión. Preserva las decisiones de marca existentes y las ediciones de otras personas. Resuelve los detalles rutinarios por ti mismo; pregunta solo por la información faltante que cambie materialmente el diseño.
Acuerda un inventario acotado de pantallas/flujos a partir del resumen, no un número arbitrario de páginas. Cubre cada superficie solicitada (web, miniprograma, móvil, escritorio); no inventes una aplicación irrelevante. Si el alcance de la superficie es desconocido y el proyecto no puede establecerlo, pregunta una vez antes de proceder. Una interfaz heredada recibe una auditoría y una versión que no sobrescribe, no un rediseño no solicitado.
Lee las secciones relevantes de reglas de decisión (§1–7) en source-synthesis.md; usa su mapa de código fuente (§8–10) cuando una compensación necesite explicación. Integra los siete repositorios fuente. La claridad de la tarea del producto, los contratos de diseño existentes y las elecciones del usuario tienen prioridad sobre las convenciones de página de aterrizaje, las prohibiciones de estilo y los temas aleatorios.
2. Investigar referencias, luego DETENERSE para una decisión de estilo
Lee reference-research.md. Comienza con Dribbble; usa 即时设计 y Behance como alternativas o complementos. Busca por la categoría del producto, la tarea del usuario y la plataforma relevante, no solo “UI bonita”. Utiliza las herramientas de búsqueda/navegador disponibles; registra qué páginas e imágenes se inspeccionaron realmente. No llames a un fragmento de búsqueda una revisión visual. Respeta las restricciones de acceso; si no se pueden ver los casos reales, repórtalo y pide referencias proporcionadas o una exención explícita de la investigación.
Crea una nueva versión en docs/prototype/versions/vX.Y.Z/ (o en la raíz de prototipo establecida del proyecto). Usa el siguiente CLI para comenzar de forma segura. Escribe primero style-reference.html: normalmente de 2 a 3 direcciones diferenciadas y apropiadas para la tarea, enlaces/creadores de casos reales, evidencia observada frente a tu interpretación, muestras de tokens y un estudio de UI pequeño original de la MISMA tarea para comparar. Incluye la adecuación a la plataforma, las limitaciones y tu recomendación. Preserva las elecciones de marca conocidas; cuando el usuario ya haya proporcionado una dirección, valídala en lugar de forzar alternativas.
Entrega el HTML de referencia de estilo real y pide al usuario que lo elija o lo revise. Detente aquí. No crees las pantallas completas de la aplicación, design-system.html ni el DESIGN.md final hasta que el usuario apruebe explícitamente una dirección nombrada (o delegue esa elección exacta en la tarea actual). Un radio/tarjeta seleccionada localmente, una recomendación preferida, el tiempo transcurrido o un registro CLI no son autorización del usuario. Mantén la evidencia de aprobación con el SHA-256 del HTML aprobado; un cambio material en ese tablero necesita una nueva decisión. No trates esta puerta como permiso para preguntar nuevamente sobre trabajo no relacionado y ya autorizado.
3. Construir el prototipo HTML completo después de la aprobación
Lee prototype-contract.md y solo las secciones relevantes de platforms-and-quality.md. Registra la decisión real del usuario; el ayudante registra la evidencia, no puede verificar quién la dio. Luego prepara y reemplaza los esqueletos generados con artefactos diseñados y funcionales:
index.html: prototipo de inicio/navegación con versión, entradas de superficie, flujos principales, referencia de estilo y enlaces a la especificación visual. Cada aplicación también tiene su propio inicio orientado a tareas. Mantén los detalles de implementación/estado en este centro de revisión, no en el marco del producto.design-system.html: especificación visual completa para los componentes usados en esta versión: colores semánticos, tipografía, espaciado, diseño/densidad, iconos, superficies, estados de componentes aplicables, interacción/movimiento y diferencias de plataforma/responsive. Muestra ejemplos renderizados reales, no solo tablas de nombres.DESIGN.md: decisiones canónicas, valores de tokens, inventario de pantallas/flujos, interacciones, anulaciones de plataforma, accesibilidad, procedencia y limitaciones conocidas del prototipo. El DESIGN.md por superficie explica solo las variaciones relevantes.- Las pantallas HTML de cada superficie solicitada: rutas críticas acordadas completas, datos sintéticos etiquetados plausibles, navegación y cambios de estado significativos. Tokens semánticos compartidos; interacción apropiada para la plataforma, no una captura de pantalla de escritorio reducida.
Usa HTML semántico, variables CSS y pequeños scripts locales por defecto. Reutiliza el framework/componentes existentes cuando reduzca la complejidad; sin React, Tailwind, shadcn o dependencia de red obligatorios. Un prototipo HTML estático debe abrirse a través de un servidor HTTP local y debe seguir siendo navegable con URLs de archivo cuando sea posible. Los activos necesarios para revisar el prototipo deben ser locales y tener licencia. Mantén el prototipo separado del código fuente de la aplicación.
4. Verificar, versionar y transferir
Usa platforms-and-quality.md para revisar el resultado renderizado en ventanas estrechas y anchas, foco de teclado, zoom y movimiento reducido; inspecciona el comportamiento aplicable del dispositivo/plataforma. Prueba las rutas principales reales más los estados vacío/carga/error/éxito y de contenido extremo que importen. No afirmes la aceptación del dispositivo o SDK nativo a partir de la simulación del navegador. Corrige los problemas observados y vuelve a verificar las rutas afectadas.
Ejecuta la validación estructural, luego registra la evidencia del navegador, los tamaños de ventana, los flujos probados y los problemas no resueltos en QA.md. La validación estructural no puede probar la calidad visual, la integridad empresarial, la aplicación de permisos, la integración externa ni la preparación para producción. Informa explícitamente los elementos no probados. Para el trabajo de implementación, mide los costos relevantes de carga/ejecución/recursos en lugar de informar solo verificaciones funcionales; los prototipos locales ordinarios no requieren un conjunto de pruebas de referencia de producción.
Mantén las versiones anteriores intactas. Lee versioning.md para la invalidación de aprobaciones, revisiones, instantáneas selladas, registro de cambios y navegación a la última versión. Entrega enlaces a los archivos reales, cómo abrirlos, qué se verificó y qué sigue siendo simulado.
Ayudante (Python 3, biblioteca estándar)
Resuelve <skill-dir> al directorio de esta habilidad instalada. Los comandos operan solo en el proyecto especificado; no publican ni cambian el código fuente de la aplicación.
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# Edita style-reference.html con investigación real; obtén la decisión del usuario.
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "Decisión exacta del usuario de esta conversación"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# Reemplaza cada esqueleto pendiente, implementa los flujos acordados y renderiza/revisa.
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "Alcance revisado y cambios materiales"
record-approval almacena un registro de flujo de trabajo, no una identidad o límite de seguridad. Nunca fabriques su evidencia. prepare produce esqueletos, no un prototipo terminado. seal registra hashes de archivos; no es una aprobación visual ni un almacenamiento inmutable. Usa el manifiesto y la evidencia de QA juntos.