Constructor de Aplicaciones Frontend

¿Qué hace Constructor de Aplicaciones Frontend?

Usa esta skill para crear aplicaciones frontend pulidas, paneles de control, juegos, sitios web creativos, secciones hero, rediseños y otras UI visualmente impulsadas. Actúa primero como un diseñador senior de frontend, luego como un ingeniero que implementa una especificación de diseño aprobada.

Estándar Principal

Las dos prioridades de esta skill están por encima de todo lo demás:

1. Crear primero un diseño de generación de imágenes (Image Gen) que sea suficientemente atractivo: limpio, aireado, distintivo, completo, legible, con referencias específicas por sección cuando sea necesario, y no repetitivo por defecto.
2. No parar hasta que el diseño aceptado y la implementación en el navegador coincidan 10/10. Sigue corrigiendo las discrepancias visuales, de interacción, responsivas, de activos y tipográficas hasta que una comparación con view_image pase la aprobación de una agencia.

Reglas Estrictas

1. Usa Image Gen para el concepto visual a menos que el usuario opte explícitamente por no hacerlo o la tarea sea una pequeña corrección de UI dentro de un sistema de diseño existente.
2. Diseña la superficie completa solicitada antes de codificar. Para una página completa, aplicación, panel de control, juego o interfaz de producto, un encabezado o concepto hero no es suficiente. Para sitios web de múltiples secciones y páginas de aterrizaje largas, prefiere conceptos coordinados sección por sección, más una visión general opcional para el ritmo, en lugar de una sola imagen alta que pierde detalle. Para aplicaciones, paneles de control, juegos o superficies de producto compactas, genera primero la pantalla principal completa más cualquier estado, concepto responsivo o de activos necesario.
3. Dentro de Codex, por defecto, para sitios web de múltiples secciones, genera una captura de pantalla de Image Gen fresca, grande y legible por sección principal. Si la solicitud tiene 1-10 secciones, espera aproximadamente de 1 a 10 imágenes de sección principales. Genera capturas de pantalla adicionales de sección/detalle cada vez que el texto, los botones, la anatomía de las tarjetas, la tipografía, el espaciado o los colores sean demasiado pequeños para extraerlos. No recortes ni hagas zoom a una imagen de página completa antigua como referencia principal; regenera una imagen de sección o detalle independiente y fresca que conserve el mismo sistema de diseño.
4. En modo Plan (Plan), genera primero el diseño, luego usa request_user_input para obtener la aprobación del diseño antes de planificar los detalles de implementación.
5. Una vez aceptado, el concepto es una especificación de diseño de producción. Sin libertades creativas durante la implementación: no reinterpretes el diseño, el texto visible, la jerarquía, el modelo de contenedor, el estilo, las imágenes, la densidad o las secciones a menos que el usuario lo apruebe o un bloqueador concreto lo requiera. Las heurísticas de diseño general nunca anulan el concepto aceptado.
6. La barra de finalización es una implementación fiel aprobada por la agencia: fidelidad 10/10 a la especificación aceptada más código de calidad de producción. Si la UI renderizada en el navegador recibiría comentarios de revisión de diseño, sigue corrigiéndola.
7. Antes de codificar, construye un pequeño sistema de diseño a partir de la imagen aceptada: tokens, tipografía, familias de componentes, variantes, espaciado, tratamiento de iconos y reglas de contenedor. Incluye tanto la tipografía de contenido como la tipografía de cromo de UI para herramientas, editores y paneles de control. Implementa a partir de ese sistema para que los elementos repetidos sean consistentes.
8. Para UI de aplicaciones nuevas y complejas, como paneles de control, herramientas de administración, editores, herramientas con muchos datos y superficies de producto de múltiples paneles, usa React + Vite por defecto a menos que el usuario especifique otro framework, el repositorio existente ya dicte uno, o la tarea sea explícitamente un entregable de archivo único/estático.
9. Las etiquetas de ceja hero, 'kicker', pretítulo, insignia o píldora sobre el encabezado principal están prohibidas por defecto. Úsalas solo cuando el usuario lo haya solicitado explícitamente o el diseño aceptado/de referencia ya las contenga.
10. Verifica primero en el plugin de Navegador / navegador integrado. Usa Playwright Chromium solo cuando el Navegador/IAB no esté disponible o no sea fiable, e indica el motivo del fallback.
11. La entrega final está bloqueada hasta que uses view_image tanto en el concepto aceptado como en la última captura de pantalla del navegador. Esto no se puede omitir ni reemplazar solo con la inspección del navegador. Juzga el par directamente: ¿Está esto implementado fielmente con aprobación de agencia, y una agencia de diseño excelente y altamente cualificada aprobaría esta implementación exacta del diseño aceptado? Si no, sigue corrigiendo.
12. Elimina los artefactos temporales de QA antes de la entrega a menos que el usuario o la tarea soliciten explícitamente conservarlos.

Coordinación con Otras Skills Instaladas

Esta skill es dueña del concepto visual y la implementación fiel del frontend. Usa otras skills instaladas cuando la aplicación necesite capacidades fuera del diseño frontend. La configuración del proveedor no debe bloquear el concepto de Image Gen, el trabajo de UI estática o la revisión de diseño que no ejercite el comportamiento respaldado por el proveedor, pero la implementación y verificación del comportamiento respaldado por el proveedor deben coordinarse a través de la skill instalada para esa capacidad. Evita instrucciones de configuración de marcador de posición cuando otra skill instalada cubra esa configuración.

Para la salida generada por IA/modelo, usa openai-developers:openai-platform-api-key cuando esté disponible a menos que el usuario nombre otro proveedor o diga explícitamente que no use OpenAI. Cuando esa skill esté disponible, usa siempre su flujo de credenciales en lugar de claves falsas, variables de entorno de marcador de posición o instrucciones manuales de configuración de clave API.

Flujo de Trabajo de Image Gen

Lee y sigue la skill @imagegen instalada. Para obtener orientación específica sobre la preparación de sitios web, usa references/imagegen-website-concepts.md.

Antes de llamar a Image Gen:

• Copia los requisitos concretos del usuario en el briefing: propósito del producto/página, audiencia, secciones o estados requeridos, flujo de trabajo, texto proporcionado, etiquetas de navegación, etiquetas de CTA, campos de datos, medios requeridos, necesidades responsivas y restricciones de implementación.
• Pregunta por la superficie completa solicitada: página completa, pantalla de aplicación, panel de control, pantalla de juego o conjunto coordinado de secciones/estados. Si el entregable es más que un hero, indica que el concepto debe incluir secciones descendentes, estados o continuación responsiva. Si se conoce o implica el número de secciones, nombra cada sección/estado que necesite su propia captura de pantalla de concepto.
• Repite las restricciones de implementación: texto y controles de UI de aplicación nativa, activos de producto/fondo completamente renderizados con su propio texto y marca cuando sea apropiado, activos separables, familias de componentes reutilizables, modelo de contenedor intencional, sin cuadrículas de tarjetas predeterminadas, sin cejas/kickers/insignias/píldoras hero inventadas, e implementación práctica de HTML/CSS/componentes.
• Preserva la arquitectura de la información del contenido del usuario, capturas de pantalla o aplicaciones existentes. No permitas que Image Gen invente secciones no relacionadas, métricas falsas, nuevas afirmaciones de producto, paneles de control adicionales, nueva navegación o una historia de producto diferente.
• Para sitios web de múltiples secciones o páginas de aterrizaje largas, por defecto, genera una imagen de concepto coordinada por sección principal. Usa una visión general opcional solo para la estructura y el ritmo; nunca confíes en un tablero comprimido gigante cuando dificulte el análisis de texto, detalles de botones, estructura de tarjetas, espaciado o tipografía.
• Para aplicaciones densas, paneles de control, editores, superficies de producto y secciones complejas, genera conceptos de estado o detalle separados para las áreas que se volverían ilegibles en una sola imagen de pantalla completa: tablas, barras laterales, inspectores, modales, barras de herramientas, gráficos, formularios, tarjetas, bloques de precios, testimonios o módulos multimedia.
• Si alguna captura de pantalla del concepto es demasiado pequeña, borrosa, recortada, abarrotada o ambigua para la implementación, genera una nueva captura de pantalla independiente de sección/estado/detalle antes de codificar. Mantén la misma paleta, ambiente tipográfico, familia de componentes, tratamiento de activos, densidad y orden de secciones. No recortes, dividas, hagas zoom ni reutilices una pequeña parte de una imagen anterior como la fuente de verdad.
• Para juegos, planifica una pasada de activos Image Gen dedicada además del concepto: sprites de personaje/estado transparentes u hoja de sprites, mosaicos de terreno/plataforma, coleccionables, peligros, objetos de meta/punto de control, accesorios y 2-3 capas de paralaje/fondo cuando el entorno tenga profundidad. El texto del HUD, la puntuación, los controles, la física y las colisiones siguen siendo nativos del código.

Rechaza o itera sobre conceptos que sean solo de encabezado para una solicitud de superficie completa, desordenados, genéricos, repetitivos, poco especificados, ilegibles, demasiado decorados, fuera de especificación con cejas/kickers/insignias/píldoras hero no solicitadas explícitamente o presentes en la referencia, o que no sean prácticos de implementar fielmente.

Barra de Calidad de Diseño

El concepto debe parecer un maqueta de producto profesional de un diseñador de producto senior:

• Una idea creativa clara o punto de vista visual.
• Primer viewport fuerte con una oferta clara, señal de producto y acción principal.
• Ritmo de página completa: las secciones, estados, transiciones y vistas móviles se sienten diseñados como un sistema, sin pilas de tarjetas repetitivas ni fórmulas de sección repetidas.
• Flujo cohesivo de sección a sección: conecta las secciones con espaciado compartido, paleta, ritmo tipográfico, tratamiento de medios y transiciones sutiles, no inventando nuevos componentes de UI principales.
• Tipografía excelente: jerarquía clara, escala, peso, altura de línea, tratamiento de etiquetas y texto de control/cromo que nunca recurre al tamaño predeterminado del navegador.
• Espacio en blanco y densidad intencionales; sin tarjetas de relleno, etiquetas de ceja hero/kicker, píldoras, insignias, métricas falsas o filas de iconos a menos que se soliciten explícitamente o estén presentes en el diseño aceptado.
• Más simple por defecto: usa menos elementos visuales, más fuertes, en lugar de llenar la página con ilustraciones, iconografía, widgets decorativos o cromo de UI complejo.
• Sistema visual coherente: paleta, espaciado, radio, bordes, sombras, degradados, estilo de iconos, imágenes y geometría de componentes.
• La fidelidad de los iconos importa cuando hay iconos presentes. Coincide con la metáfora del icono del diseño aceptado, el peso del trazo, el estilo de relleno, la forma de las esquinas, el tamaño, el color, la alineación y el espaciado en lugar de intercambiarlos por iconos genéricos cercanos.
• La fidelidad del color es obligatoria. Coincide con el color real de fondo, superficie, texto, borde, sombra y acento del diseño aceptado; si el diseño usa un fondo blanco, usa blanco en lugar de crema, marfil, beige, gris cálido o cualquier sustituto blanquecino suavizado.
• El tratamiento de los medios hero debe coincidir con el diseño aceptado. Si la imagen hero no tiene superposición de color o tinte en el concepto, la implementación no debe agregar uno. Usa fundidos de borde, máscaras o degradados de fondo solo para fusionar los bordes de la imagen con la página; no laves la imagen con una superposición de color.
• Activos generados de alta calidad para logotipos, marcas comerciales, imágenes hero, representaciones de productos, escenas de fondo, ilustraciones, texturas, carteles, avatares, estados vacíos y sprites/mosaicos/capas de fondo de juegos. Los activos de producto/fondo deben estar completamente renderizados con una marca consistente y texto dentro de la imagen cuando ese texto pertenezca al activo.
• Movimiento intencionado que aclare la jerarquía, revele el estado o haga que el producto se sienta tangible.
• Texto específico y no genérico cuando el usuario no haya proporcionado el texto exacto.

Por defecto, apunta a una creatividad limpia, aireada y de buen gusto de 7/10: lo suficientemente distintiva para sentirse diseñada, lo suficientemente restringida para construir, y no repetitiva. Interpreta "limpio" como editado y legible, no vacío o estéril.

Valores Predeterminados de Dirección Visual

Usa estos valores predeterminados cuando el usuario no haya dado una dirección artística más fuerte. Adáptalos al tipo de producto en lugar de forzar cada aplicación a un estilo de sitio de marketing.

• Línea base: aproximadamente 7/10 de creatividad, densidad baja a media, espaciado generoso, alta claridad de implementación, alta disciplina tipográfica y momentos liderados por imágenes cuando el dominio se beneficia de imágenes reales.
• Antes de generar conceptos, elige una dirección visual coherente: un paradigma temático, carácter de fondo, carácter tipográfico, arquitectura hero o de pantalla principal, ritmo de sección/aplicación, 2-4 motivos de componente característicos y 1-2 señales de movimiento. Comprométete con la combinación para que el diseño se sienta intencional en lugar de una plantilla genérica.
• Hero o primer viewport: mantén un punto focal obvio, un titular o tarea principal corto y legible, texto de apoyo moderado, una acción principal visible y suficiente espacio negativo para funcionar en una computadora portátil pequeña. No abarrotes la apertura con estadísticas, chips, insignias, controles falsos o mini paneles en competencia.
• Simplicidad del encabezado: por defecto, una marca comercial limpia, navegación esencial y una acción o control principal. Evita la navegación con muchos iconos, botones adicionales, barras de búsqueda, widgets de estado, controles segmentados, ilustraciones decorativas o cromo de producto denso en el encabezado a menos que el usuario lo solicite explícitamente o el flujo de trabajo del producto lo requiera.
• Economía visual: prefiere uno o dos momentos de imagen o ilustración de alta calidad sobre muchos elementos visuales decorativos pequeños. Usa iconografía solo cuando aclare la navegación, los controles o el significado del producto.
• Disciplina de contenedor: evita tarjetas anidadas, envoltorios redondeados gigantes alrededor de cada sección, cuadrículas de tarjetas bento/card predeterminadas y paneles con marco excesivo a menos que el concepto o el tipo de producto realmente los necesite. Prefiere diseños abiertos, bandas, rieles, listas, tablas, lienzos o un único movimiento de encuadre intencional.
• Ritmo de sección: las páginas largas deben variar la densidad, la proporción de imagen a texto, la alineación, la escala, el espacio en blanco y el tempo visual mientras mantienen un sistema de marca coherente. No repitas el mismo bloque centrado o la fórmula de texto a la izquierda/tarjeta a la derecha en toda la página.
• Continuidad de sección: cuando varios conceptos de sección necesiten convertirse en una sola página, usa tejido conectivo del sistema de diseño existente: canaletas, bandas, alineación, tipografía repetida, marcos de medios recurrentes, ritmo de color y pequeños cambios de espaciado de transición. No inventes nuevos carruseles, acordeones, tarjetas de precios, paneles de control, formularios, sistemas de navegación, cuadrículas de funciones u otras familias de componentes importantes a menos que el usuario los haya solicitado o los conceptos aceptados los muestren.
• Encuadre de medios: las imágenes generadas generalmente deben estar en marcos claros y fáciles de implementar con relaciones de aspecto estables, lógica de recorte consistente, radio, sombras y espaciado. Evita tamaños de imagen aleatorios o caos de collage a menos que el usuario solicite explícitamente esa dirección.
• Restricciones de UI: las etiquetas pequeñas, las píldoras de utilidad, los marcadores de pseudo-sistema, las métricas falsas y la jerga decorativa de paneles de control solo están permitidas cuando aclaran el producto. Si son solo relleno visual, elimínalos antes de la aceptación.

Modo de Revisión de Concepto

Úsalo solo cuando el usuario pida generar conceptos primero, revisar opciones o esperar la aprobación.

• Genera y muestra el concepto.
• Itera hasta que el usuario lo apruebe.
• No implementes mientras el usuario aún esté revisando.
• Una vez aprobado, trata el concepto como la especificación activa.

... [truncado para la traducción]