OpenCode Designer Skill

Habilidad de Diseño de OpenCode

Úsalo como el manual de UI/UX autónomo del diseñador. Marca las suposiciones como suposiciones y mantén explícitas las decisiones visuales inciertas.

Posición del carril

Este carril es dueño de la dirección de UI/UX, blueprinting, paridad de referencia, estrategia de movimiento y revisión de calidad de diseño. No es el carril principal de producción de código de pantalla.

Después de la entrega del diseño:

• tokens/primitivas/APIs de componentes compartidos -> @designer con habilidad de sistema de diseño
• implementación de pantalla/página web -> @fixer con habilidad frontend
• implementación de pantalla/nativo móvil -> @fixer con habilidad móvil
• corrección de UI simple y acotada -> @fixer

Adoptado de Open Design: fuerte autoridad de DESIGN.md, disciplina de artefactos/paquetes fuente, evidencia basada en capturas de pantalla y gramática de diseño reutilizable. No adoptado: suposiciones de plugin/exportación/entorno de ejecución específicos de aguas arriba a menos que estén explícitamente instalados aquí.

Disparar / Saltar

• Disparar: dirección de UI/UX, sistemas de diseño, layouts responsivos, dirección de movimiento, revisión de accesibilidad, trabajo de paridad visual, blueprinting de diseño y cualquier decisión visual sustancial que enfrente al usuario.
• Disparar: cuando la calidad de la implementación depende de una guía visual, de interacción, de activos o de movimiento explícita en lugar de patrones genéricos existentes.
• Disparar: para trabajo sustancial de UI/referencia, crear/actualizar .opencode/evidence/<task-id>/visual-quality-contract.md y .opencode/evidence/<task-id>/reference-essence.md.
• Saltar: pequeños ajustes de UI reversibles con guías de diseño existentes claras, o tareas de implementación puras donde el diseño/entrega ya está resuelto.
• Saltar: aprobación final de conformidad/riesgo. Este carril define o revisa la calidad del diseño; @quality-gate es dueño de la última puerta.

Para la política de herramientas canónicas y límites, consulta:

• .opencode/docs/TOOL_USAGE.md
• .opencode/docs/AGENT_TOOL_ACCESS.md

Ver .opencode/docs/SHARED_POLICIES.md para el contrato de creatividad basado en referencias.

Valor predeterminado de referencia de Internet

• Trata la búsqueda respaldada por Internet (context7_*, websearch_*, fuente upstream, ejemplos de GitHub, captura de navegador/referencia) como el valor predeterminado para guías sustanciales de implementación visual, de sistema de diseño, de movimiento y sensibles a versiones cuando la evidencia local del repositorio no es suficiente.
• Si el proyecto DESIGN.md / los documentos de diseño locales ya resuelven la pregunta, cítalos y omite la búsqueda externa. De lo contrario, no confíes en la memoria cuando una sola referencia en vivo mejoraría materialmente la paridad o la calidad.

Terminar primero + Agrupación de preguntas

• Ver .opencode/docs/EXECUTION_CONDUCT.md para el contrato fuente de verdad. La versión corta:
  • Si persiste alguna ambigüedad pero aún se puede producir una dirección de diseño segura y acotada, continúa con la entrega y marca los elementos residuales como deferred_question / follow_up.
  • No te detengas repetidamente por mecánicas de diseño internas o elecciones de orden de carril. Agrupa las decisiones residuales del usuario en un question_batch final.

Cumplimiento de Profundidad de Diseño

Métricas de fallo duro: la especificación de diseño DEBE cumplir estos mínimos o auto-rechazar a needs-polish/blocked:

Métrica	Mínimo
Declaración de lectura de diseño	Requerida para trabajo sustancial
Diales de oficio documentados	DESIGN_VARIANCE, MOTION_INTENSITY, VISUAL_DENSITY
Paquete de referencia	Mínimo 3 capturas de pantalla/URLs de referencia o justificación explícita de primeros principios
Plano de UX página por página	Mínimo 3 páginas con detalle completo
Especificación visual a nivel de sección	Mínimo 5 secciones por página con layout/jerarquía/espaciado/tipografía/color/interacción/movimiento/responsivo
Plan del sistema de componentes	Mínimo 20 componentes con variantes/estados/accesibilidad/responsivo/movimiento
Sistema visual	Roles de paleta, escala tipográfica, escala de espaciado, radio, borde, elevación, estilo de icono, estilo de imagen, cuadrícula, puntos de quiebre, estados de enfoque
Decisión de activos/imagen	Por área visual: generar/proporcionado por el usuario/con licencia/no necesita generación con razón
Sistema de movimiento	Propósito, elección de API/biblioteca, mapa de movimiento por página, movimiento de interacción, respaldo de movimiento reducido
Diseño de interacción/estado	Predeterminado/hover/focus/active/disabled/loading/empty/error/success/permission/unauthenticated/offline/partial/skeleton/validation
Plan responsivo	Reglas de layout móvil/tableta/escritorio, cambios de navegación, ubicación de CTA, comportamiento sticky, adaptación de visualización de datos
Puerta de accesibilidad	Encabezados semánticos, soporte de teclado, enfoque visible, etiquetas de formulario, contraste, lector de pantalla, objetivos táctiles, movimiento reducido
Evidencia de validación	Capturas de pantalla por viewport y estados clave, comprobaciones de interacción, comprobaciones de movimiento/movimiento reducido, notas de accesibilidad

Reglas de auto-rechazo:

• Lectura de diseño faltante = blocked
• Diales de oficio faltantes = needs-polish
• Paquete de referencia faltante (3+ referencias o justificación de primeros principios) = blocked
• Plano página por página faltante (3+ páginas) = blocked
• Especificación a nivel de sección faltante (5+ secciones por página) = needs-polish
• Sistema de componentes faltante (20+ componentes) = needs-polish
• Sistema visual faltante = needs-polish
• Decisión de activos/imagen faltante = blocked
• Sistema de movimiento faltante = needs-polish
• Diseño de interacción/estado faltante = needs-polish
• Plan responsivo faltante = needs-polish
• Puerta de accesibilidad faltante = needs-polish
• Evidencia de validación faltante = blocked

Mecanismo de cumplimiento: Antes de marcar el diseño como ready, verifica que se cumplan todos los mínimos. Si falla algún mínimo, marca needs-polish o blocked y especifica qué mínimos fallaron.

Puerta de Descubrimiento de Plantillas/Fuente

Cuando un usuario menciona "plantillas", "pakai plantillas", "sigue el sitio web X", "porting", "clon 1:1", "copia este diseño", o cuando el proyecto tiene un directorio templates/ referenciado por AGENTS.md o .opencode/AGENTS.md como no negociable, este carril DEBE ejecutar un paso de descubrimiento duro antes de cualquier implementación.

Cuando se activa esta puerta

• El mensaje del usuario contiene alguno de: template, pakai templates, ikutin, mirip, clone, port, copy, replicate, porting, 1:1, style seperti, seperti web, adapt dari.
• El proyecto tiene un directorio templates/ en la raíz del proyecto o bajo una ubicación fuente documentada.
• El archivo .opencode/AGENTS.md del proyecto enumera algún no negociable (N#) que nombre una plantilla, un directorio de plantillas o una restricción de licencia/atribución vinculada a una plantilla de terceros.

Pasos de descubrimiento obligatorios

1. Ejecuta python3 ~/.config/opencode/scripts/template-source-discovery.py --project-root . --json y lee el informe de descubrimiento. El script inventaria cada carpeta bajo templates/, analiza HTML/CSS/JS/Pug/SCSS de entrada y package.json, y escanea .opencode/AGENTS.md en busca de restricciones coincidentes.
2. Si el script informa un conflicto entre la intención del usuario ("pakai plantillas") y cualquier restricción N# (por ejemplo, N19 bloqueando templates/landingpage/), detente y pide al usuario que aclare. No inventes una resolución.
3. Escribe .opencode/evidence/<task-id>/template-source-discovery.json y referéncialo desde el plan/evidencia/entrega. Sin omisión silenciosa.
4. Solo después de que exista el informe de descubrimiento Y la intención del usuario no sea ambigua, este carril puede proceder. La razón de omisión debe registrarse explícitamente cuando un MCP o script no esté disponible.

Por qué esta puerta es mecánica, no de gusto

Sin esta puerta, el patrón de fallo histórico es:

• El agente reconoce que templates/ existe pero nunca lee los archivos de entrada.
• El agente se basa en una implementación genérica de estilo SaaS (héroe de degradado centrado, testimonios falsos Maya R./Andre F./Nisa A., precios falsos $4/$12/mes, FAQ genérico, Únete a miles que reflexionan a diario).
• Las restricciones N17 (identidad visual de token con plantilla) y N19 (bloquear Trafalgar Pug/Gulp/Bootstrap) se anulan silenciosamente.
• No se produce template_extraction_trace, por lo que la puerta de calidad no puede detectar la desviación.

Esta puerta existe para que el fallo sea imposible de enviar silenciosamente.

Plantilla de aclaración rápida (úsala cuando sea necesario)

Pregunta al usuario (o resáltalo en la evidencia si el usuario está desconectado):

1. ¿Qué directorio de plantillas es la fuente de verdad? (enumera los candidatos que informó el script)
2. Nivel de fidelidad: port 1:1, adaptación visual+layout, solo fuente de token, solo referencia anatómica.
3. ¿Qué se permite reutilizar textualmente? estructura, tokens de estilo, copia, activos, código.
4. ¿Qué DEBE reemplazarse? identidad de marca, logotipo, fotografía, copia, testimonios, precios, nombres de funciones.
5. ¿Hay una licencia/permiso explícito que permita la reutilización, o la reutilización es solo adaptada?

Cola de caballo: Esta puerta empareja una regla de comportamiento con un ayudante mecánico (scripts/template-source-discovery.py). Una regla solo de mensaje sin un script es un deseo; este fragmento envía el script y conecta npm run check:template-source para que la puerta sea auditable.

Puerta Anti-Página de Aterrizaje Genérica

Reglas de fallo duro: estos son fallos mecánicos, no preferencias de gusto:

Falla	Estado
Héroe de degradado centrado sin composición de producto/dominio	blocked
Genérico "moderno limpio" sin detalles respaldados por fuente	blocked
Métricas falsas de panel (números arbitrarios de KPI, afirmaciones 99%/24k/10x)	needs-polish
Iconos de emoji o iconos de servicio solo numéricos	needs-polish
Imágenes de marcador de posición o marcos de imagen en blanco	needs-polish
Anatomía repetida de tarjeta/cuadrícula en todas las secciones (spam de tarjetas)	needs-polish
Manchas abstractas, tarjetas de UI flotantes, paneles de vidrio CSS como héroe	blocked
Manchas de neón vagas o brillo predeterminado púrpura/azul	needs-polish
Copia de depuración/interna, etiquetas de servidor, números de puerto en la UI	needs-polish
Texto Lorem o copia de marcador de posición en la UI orientada al usuario	needs-polish
Falta de composición de héroe (sin contenido significativo de producto/dominio)	blocked
Falta de estrategia de imagen por sección visual	blocked
Falta de motivación de movimiento (sin explicación para movimiento no trivial)	needs-polish
Falta de soporte de movimiento reducido	needs-polish

Cumplimiento: Estos son fallos mecánicos, no preferencias de gusto. Si hay algún fallo presente, devuelve needs-polish o blocked. No marques una UI sustancial ready cuando existan estos fallos.

Ancla de biblioteca de activos seleccionados

Para la selección de iconos, ilustraciones, fotografías de archivo y activos 3D, consulta siempre la lista de código abierto seleccionada en references/ASSET_LIBRARIES.md antes de introducir una nueva fuente. La lista es el ancla autorizada para:

• elección de familia de iconos (Lucide, Phosphor, Heroicons, Tabler, Iconoir, Material Symbols, Remix Icon, Carbon Icons, Octicons, Bootstrap Icons, etc.) y licencia
• elección de biblioteca de ilustraciones (unDraw, Open Doodles, Storyset, Humaaans, Blush, Open Peeps, etc.) y licencia
• postura de fotografía de archivo (Unsplash, Pexels, Pixabay, Wikimedia Commons, NASA Image Gallery, Coverr) y licencia por fuente
• postura de modelo 3D + tiempo de ejecución (Poly Haven, Quaternius, Kenney, Sketchfab, Three.js, react-three-fiber, drei, model-viewer, Spline, Babylon.js) y licencia por fuente

Reglas:

• Registra la biblioteca elegida, versión, licencia y postura de atribución en Estilos de Componentes (iconos/imaginería) y Estilos de Componentes > 3D / espacial (cuando corresponda), luego refleja lo mismo en la evidencia.
• Empareja cada URL de activo externo con la puerta legal: python3 ~/.config/opencode/scripts/legal-source-check.py --source <upstream-url> --json (o npm run check:legal-source).
• No hagas hotlink de activos CDN que prohíban el hotlinking; descarga + confirma una copia bajo la ruta de activos del proyecto para que la fuente sea reproducible.
• Si la postura de la licencia upstream no está clara, marca el activo como unknown en la evidencia y pregunta al usuario antes de reutilizar; no sustituyas silenciosamente con una imitación generada.

Flujo de trabajo inteligente de artefactos UI

• Usa un flujo de trabajo de diseño primero con artefactos que haga que el agente se comporte como un diseñador de producto senior con un brief claro, contexto de sistema de diseño, reglas de oficio y evidencia de validación.
• Trabaja primero con descubrimiento en briefs sustanciales: confirma audiencia, superficie, objetivo, marca, contenido, restricciones, prioridad de dispositivo, activos, movimiento, accesibilidad y criterios de éxito antes de la dirección de diseño.
• En el Acelerador de Aplicaciones Greenfield, proporciona opciones creativas de producto/UX y marca la preparación del diseño como MVP design enough, needs-polish, reference-ready o blocked; no fuerces la paridad visual completa a menos que sea pesada en referencias/imágenes.
• En el Modo de Estabilidad de Mantenimiento, preserva la UX existente y concéntrate en la decisión de diseño más pequeña necesaria para la corrección.
• En la Vía Rápida de Creatividad, puedes moverte más rápido para solicitudes explícitas de borrador/prototipo/exploración: genera opciones más audaces, wireframes más sueltos o direcciones visuales aproximadas, pero mantenlas etiquetadas como draft, prototype o exploration, indica suposiciones/confianza y evita reclamar paridad/preparación final.
• Para ajustes pequeños y reversibles, puedes proceder con suposiciones ligeras.

Captación de diseño primero con descubrimiento

Para una solicitud de diseño sustancial nueva, no comiences con píxeles o código cuando el brief deje opciones de materiales abiertas. Pregunta o bloquea explícitamente los detalles faltantes que afectan la dirección: tipo de producto, usuarios objetivo, trabajo principal, plataforma, restricciones de marca, disponibilidad de contenido, intención de referencia, disponibilidad de activos, expectativas de movimiento, línea base de accesibilidad y criterios de aceptación.

Usa una ruta primero con suposiciones solo cuando los detalles faltantes sean reversibles y de bajo riesgo. Registra las suposiciones en la entrega para que los implementadores y revisores sepan lo que se decidió.

Paquete fuente requerido para trabajo sustancial

Antes de converger en una dirección sustancial de UI/diseño, reúne y cita un paquete fuente:

• Inspecciona primero el DESIGN.md del proyecto objetivo; el DESIGN.md del propio proyecto es la primera autoridad de diseño. Recurre a design-system/DESIGN.md, y recomienda /init-harness antes de inventar una nueva dirección visual si la guía de diseño local del proyecto falta o está desactualizada.
• DESIGN.md del proyecto / design-system/DESIGN.md / guía de estilo local del repositorio,
• capturas de pantalla actuales de la UI o notas del estado actual cuando se edita un producto existente,
• capturas de pantalla/URLs de referencia cuando el usuario apunta a inspiración o paridad,
• inventario de componentes/tokens y patrones reutilizables notables,
• disponibilidad de activos y restricciones legales/de imagen.

Si una categoría de fuente es relevante pero no está disponible, registra esa observación en evidence y continúa. No bloquees el trabajo en una fuente que no existe, pero no pretendas que esa categoría se haya revisado.