Ir a la guía de uso
Web Design Engineerpor ConardLi

Web Design Engineer Skill.

Define el contrato visual antes de ampliar la interfaz.

  • Diseño frontend
  • Prototipado
  • Sistemas de diseño
Revisión de la fuente · Web Design EngineerSKILL.md
Tarea Diseño frontend Produce • Un artefacto visual HTML/CSS/JavaScript o React • Una evaluación documentada de la dirección visual y de las decisiones sobre tokens de diseño • Un borrador inicial visible, seguido de estados e interacciones completos Antes de empezar Requiere un agente capaz de programar y un entorno frontend que se pueda renderizar en el navegador. Algunos patrones pueden usar React, Babel, gráficos u otras bibliotecas; la aceptación en navegador requiere una herramienta de navegador adecuada.
Resumen editorial · fuente revisada 2026-10-07 · no es un ejemplo generado

01 Qué hace

Web Design Engineer

Un método de ingeniería de diseño que parte del contexto, con requisitos de recursos, calibración del diseño, borradores iniciales, modos de preservación y vías distintas de crítica y control de calidad en navegador.

Flujo basado en la fuenteNo es una prueba de rendimiento de ejecución

El enfoque de trabajo

Web Design Engineer es un flujo de trabajo de artefactos de navegador para páginas, paneles, prototipos, presentaciones y visualizaciones. En lugar de tratar cada petición como una nueva landing page, primero identifica el artefacto, la audiencia y el modo de trabajo sobre lo existente. Ampliar un producto, preservar los contratos de un rediseño y reconstruir una dirección visual son tareas distintas con permisos distintos.

Su evaluación de diseño usa cinco dimensiones ajustables: variación, movimiento, densidad de información, dependencia de recursos y fidelidad de marca. Estas alimentan un sistema declarado y un borrador inicial visible antes de la implementación detallada. En trabajos de marca, los logotipos reales, las fotografías de producto y las capturas de la interfaz importan más que una paleta por sí sola. El skill también separa una autocomprobación ligera de la aceptación ejecutable en navegador, que su fuente reserva para una petición explícita de QA.

Entregables previstos

  • Un artefacto visual HTML/CSS/JavaScript o React
  • Una evaluación documentada de la dirección visual y de las decisiones sobre tokens de diseño
  • Un borrador inicial visible, seguido de estados e interacciones completos
Ver el brief de ejemplo

Del brief a la revisión

  1. 01
    Lee el contexto existente

    Inspecciona el código fuente, las capturas, los recursos de marca y las restricciones proporcionados. Clasifica el trabajo como una extensión, un rediseño que preserva lo existente o una renovación más amplia.

  2. 02
    Declara el contrato de diseño

    Explica la dirección visual, la audiencia, la densidad, el movimiento y los recursos; después especifica tipografía, espaciado, paleta, superficies y tratamiento de la interacción. Espera a que el usuario apruebe este sistema de diseño antes de escribir el primer código.

  3. 03
    Muestra un borrador visible

    Usa maquetaciones clave y marcadores de posición honestos para probar la dirección. Espera una aprobación independiente de este borrador inicial antes de completar todos los componentes o estados de interacción.

  4. 04
    Construye y revisa

    Completa las interacciones y los estados aprobados. Realiza la autocomprobación de la fuente; cuando se solicite la aceptación en navegador, recopila por separado evidencias reales de viewport e interacción.

02 Cuándo usarlo

Cuándo usarlo

Requiere un agente capaz de programar y un entorno frontend que se pueda renderizar en el navegador. Algunos patrones pueden usar React, Babel, gráficos u otras bibliotecas; la aceptación en navegador requiere una herramienta de navegador adecuada.

Buen encaje

  • Extensiones de productos existentesÚtil cuando una pantalla nueva debe parecer parte del producto y respetar las rutas, formularios y expectativas de interacción de su entorno.
  • Exploración de dirección de diseñoSirve para un brief visual vago que necesita direcciones realmente distintas o variantes ajustables antes de que el equipo se comprometa con una composición.

Límites que conviene comprobar

  • Alcance de frontend visualLas API de backend, las herramientas de línea de comandos y el procesamiento de datos quedan fuera del resultado previsto del skill. Los flujos dedicados a artículos y a presentaciones guiadas por narración también se tratan aparte.
  • La calidad no es un resultado de pruebasUna crítica de diseño o una inspección de la fuente no demuestra el comportamiento responsive en un navegador en ejecución. Solicita una aceptación ejecutable cuando necesites esa evidencia.

Aporta estos datos

  • Artefacto y audienciaIndica la pantalla o experiencia que se va a producir, quién la usa y los tamaños de visualización o las condiciones de presentación importantes.
  • Contratos existentesProporciona el código, las referencias del sistema de diseño y los comportamientos protegidos. Indica qué partes pueden cambiar y cuáles deben seguir siendo reconocibles.
  • Contenido y recursos realesAporta textos aprobados, imágenes de producto auténticas, logotipos y datos. Marca lo que aún falte en lugar de inventar testimonios o métricas.

03 Decisiones importantes

Decisiones que importan

  1. La preservación como decisión de diseño

    El modo de trabajo explícito ayuda a evitar que un rediseño atractivo cambie sin avisar convenciones útiles del producto o sustituya decisiones de marca válidas.

  2. Variantes más allá del cambio de color

    Su marco de calibración permite variar de forma independiente la densidad, la organización y la interacción, en lugar de mostrar varias versiones cosméticas de la misma maquetación.

04 Ejemplo de brief

Prueba un brief concreto

El brief de ejemplo siguiente no se ha probado. Revisa la configuración del skill antes de usarlo.

Revisa la configuración

Usa la carpeta completa del skill de Garden para disponer de sus recetas de diseño, su protocolo de preservación y las referencias opcionales de aceptación.

Archivo de la fuente original
https://github.com/ConardLi/garden-skills/blob/aaf9a82f5efd73e87cc0998edc398e75bfc35901/skills/web-design-engineer/SKILL.md

Requiere un agente capaz de programar y un entorno frontend que se pueda renderizar en el navegador. Algunos patrones pueden usar React, Babel, gráficos u otras bibliotecas; la aceptación en navegador requiere una herramienta de navegador adecuada.

Empieza con un solo entregable

Adapta el alcance, el material de origen y las restricciones de este brief antes de ejecutar el skill.

Brief de ejemplo
Usa Web Design Engineer para ampliar nuestra interfaz de analítica existente con una pantalla de informes guardados. Conserva su navegación, sus tokens de espaciado y las convenciones de sus tablas. Lee los componentes y las capturas proporcionados, propón el sistema de diseño y espera mi aprobación antes de programar. Después muestra un borrador visible con planes para los estados de carga y vacío. Cuando yo apruebe ese borrador, completa la implementación y ejecuta la aceptación en navegador en los tamaños de escritorio y móvil indicados. No inventes estadísticas de uso de los informes.

Inspecciona el resultado

Comprueba el resultado real con estos criterios observables.

  • El modo de trabajo documentado coincide con los cambios realmente hechos en la interfaz existente.
  • La vista completada incluye los estados de interacción relevantes para el brief.
  • Toda afirmación de aceptación en navegador va acompañada de los viewports probados y los resultados reales.

OpenDesign ofrece un espacio de trabajo de diseño local para agentes de programación. Este listado no significa que el skill incluya sus herramientas externas, credenciales o dependencias de software.

05 Fuente y licencia

Fuente y licencia

Esta página describe la revisión fijada de la fuente enlazada abajo. El comportamiento y los requisitos originales pueden cambiar.

Propietario de la fuente
ConardLi
Licencia
MIT
Versión revisada
2026-10-07 · aaf9a82f5efd
Resumen editorial de la fuente
Un método de ingeniería de diseño que parte del contexto, con requisitos de recursos, calibración del diseño, borradores iniciales, modos de preservación y vías distintas de crítica y control de calidad en navegador.

Resumen original de OpenDesign, basado en la fuente enlazada. Las estrellas del repositorio son una señal de popularidad con fecha, no una medida de uso del skill ni una puntuación de calidad.

06 Preguntas antes de empezar

Preguntas antes de empezar

¿Siempre produce un proyecto React?

No. HTML es el medio de salida, pero la fuente abarca tanto HTML/CSS/JavaScript simple como prototipos y artefactos visuales orientados a React.

¿Sustituirá un sistema de diseño existente?

No automáticamente. El flujo distingue entre extensión, rediseño que preserva y renovación; esa elección debe resolverse antes de editar.

¿Toda compilación incluye pruebas automáticas en navegador?

La fuente exige una autocomprobación ligera en todo trabajo, pero su sistema de aceptación ejecutable se activa con una petición explícita de navegador, responsive o QA.

OpenDesign

Deja espacio para la próxima iteración del diseño.

Mantén tu brief, el material de origen y el trabajo de diseño juntos en un espacio de trabajo local. Revisa la configuración propia del skill antes de añadirlo a tu flujo de trabajo.

Archivo de la fuente original
https://github.com/ConardLi/garden-skills/blob/aaf9a82f5efd73e87cc0998edc398e75bfc35901/skills/web-design-engineer/SKILL.md