Communitygithub.com

WithZeng/design-skills

Diseña y construye sitios de marketing, páginas de aterrizaje, páginas de producto o la interfaz de usuario y páginas de autenticación de una aplicación de principio a fin, con referencias visuales, borradores aprobados, un sistema de página unificado, dirección de arte y animación, i18n y verificación de accesibilidad.

¿Qué es design-skills?

Esta skill para agentes de IA (como Claude Code, Cursor o Codex) guía el proceso completo de diseño y desarrollo de interfaces web profesionales: desde la recopilación de requisitos hasta la verificación final. Es útil para creadores de sitios web, diseñadores de UI y desarrolladores que buscan un flujo de trabajo sistemático, basado en la aprobación de borradores visuales antes de escribir código, y que garantiza consistencia visual, accesibilidad e internacionalización. La skill se compone de varios módulos: un flujo de trabajo con 'gates' (compuertas) que obligan a mostrar y aprobar borradores antes de programar; un sistema de página unificado que elimina la 'sensación de fragmentación' (割裂感) al reutilizar un mismo fondo, módulo de sección, escala tipográfica, paleta de colores y pieza de dirección de arte; dirección de arte y animación derivadas del brief del proyecto; interacción enriquecida mediante librerías de componentes y animación; y reglas duras sobre contraste, animaciones, i18n y grids. El agente usará referencias visuales (capturas de pantalla de sitios reales o generadas con image-gen) como entrada, y seguirá un proceso iterativo de borradores-código-verificación. Está diseñado para cualquier framework web moderno y se integra con herramientas como Clerk para autenticación.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/WithZeng/design-skills/tree/HEAD/skills/website-design

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Diseño de sitios web

Lecciones del rediseño del sitio Scientify (2026-10): el diseño solo funcionó después de que se mostraran y aprobaran los borradores, se aplicó un sistema de página único en cada sección y la verificación detectó errores de contraste y marcado que las librerías de animación introducen.

Flujo de trabajo y compuertas

  1. Brief. Recopila producto, audiencia, secciones, datos de muestra reales y 1–2 sitios de referencia que le gusten al usuario. Si no tiene ninguno, elige 2–3 que se ajusten al tipo de sitio de references/ui-references.md (galerías, librerías de UI de productos reales, fuentes de componentes) y muéstralos para su aprobación. Captura las referencias y guárdalas como imágenes --ref; cuando te pidan recomendaciones, muestra capturas de pantalla numeradas más 2 o 3 combinaciones para elegir (método: ui-references, "Capturing references").
  2. Borradores antes del código. Nunca edites código para un cambio visual hasta que el usuario apruebe un borrador. Usa la skill image-gen. Orden:
    1. Si la dirección está abierta, una imagen general por dirección (normalmente 2); el usuario elige una antes de cualquier trabajo detallado. Luego una imagen de página completa larga (1024x1536) para fijar el sistema de página.
    2. Una imagen detallada por sección/panel a resolución completa.
    3. Subpáginas y luego storyboards de interacción (3–4 fotogramas por interacción) para movimiento. Muestra cada lote, recopila comentarios, itera. Plantillas de prompt: references/draft-prompts.md.
  3. Construye solo los borradores aprobados, detrás de una ruta de vista previa hasta que el usuario diga que reemplace la página en vivo. Patrones: references/build-patterns.md.
  4. Verifica antes de cualquier commit/PR: references/verification.md.
  5. Guarda los borradores y capturas de pantalla en la carpeta scratch ignorada por git del proyecto (ej. tmp/design/vN/), una carpeta por ronda, prompts guardados junto a las imágenes.

Sistema de página (lo que eliminó la "sensación de fragmentación")

Una página se siente como una sola pieza cuando cada sección reutiliza el mismo sistema. Decide los valores del sistema a partir de los borradores aprobados, luego escríbelos en cada prompt y en los tokens del código:

  • Un único tratamiento de fondo para toda la página; evita secciones que inventen sus propias bandas o degradados.
  • Un módulo de sección (contenedor, radio, relleno, borde, padding, ancho) y un pequeño conjunto de diseños dentro de él, reutilizados sección tras sección.
  • Una escala tipográfica: el mismo tamaño y peso para cada título de sección, un estilo de cuerpo, espaciado consistente.
  • Una pieza emblemática que lleva la dirección de arte (normalmente en el héroe); todo lo demás se mantiene más tranquilo en el diseño pero aún responde a la interacción. De qué es esa pieza proviene del brief, no de una plantilla: ver "Dirección de arte" más abajo.
  • Toda la UI del producto mostrada es la MISMA aplicación (misma navegación, tema, datos), para que la página se lea como un solo producto.
  • Una paleta lo suficientemente restringida para mantener el sistema coherente (un sitio usó monocromo puro); el logotipo conserva sus colores originales. Usa el logotipo real de la marca en todas partes, nunca un placeholder de letra en un cuadrado.
  • Contenido: datos realistas del dominio del producto (nombres, números y tiempos plausibles) y una convención de nomenclatura para archivos y objetos, decidida por proyecto; sin lorem, sin testimonios o estadísticas falsas, sin eslóganes de moda.

UI de la aplicación y páginas de autenticación

Las mismas compuertas se aplican dentro de un producto, con diferentes referencias y tokens:

  • Las referencias provienen de UI de productos reales (ej. Refero, capturas de pantalla de productos comparables en sus sitios web, documentación de componentes para pantallas de chat/agente), no de galerías de landing pages.
  • Reutiliza los tokens y componentes propios de la aplicación; no importes la paleta del sitio de marketing. Primero fija un pequeño conjunto de primitivas compartidas (panel, anchos de contenedor de página, anchos de diálogo, control segmentado), luego rediseña las pantallas con ellas.
  • Inicio de sesión / registro con un widget de autenticación alojado (ej. Clerk): estilízalo a través de su API de apariencia y localización, y revisa las trampas en build-patterns ("Auth pages").

Dirección de arte (dimensión y movimiento)

Diseña las partes dimensionales y en movimiento a partir de los requisitos propios del sitio, luego dibújalas como cualquier otro visual. No reutilices la receta o los valores fijos de un sitio anterior.

  1. Derívalo del brief. ¿Cuál es la única idea que un visitante debe captar (el producto en acción, una transformación, escala, precisión, calma)? ¿Quién es la audiencia, cuál es el tono de la marca, qué dispositivos y presupuesto de rendimiento? La pieza emblemática debe mostrar esa idea, idealmente con el producto real.
  2. Explora 2–3 opciones que se ajusten al sistema de página y al tono, p. ej., una ventana de producto en perspectiva, profundidad en capas con parallax, una escena impulsada por scroll que cuenta el flujo de trabajo, una ilustración u objeto 3D, una metáfora visual/de datos, o una página plana y tranquila con microinteracciones ricas. Dibuja cada una como una imagen y, para movimiento, como un storyboard; el usuario elige.
  3. Especifica, luego construye. Escribe para la opción elegida: qué se mueve, qué lo desencadena (carga, scroll, puntero, tiempo, clic), el estado de reposo, la versión de movimiento reducido y la versión móvil. Ajusta ángulos, tiempos e intensidades contra los borradores aprobados en el navegador, no desde una plantilla.
  4. Comprueba el costo. No debe perjudicar la legibilidad, el contraste, la estabilidad del diseño ni el tiempo de carga; debe degradarse correctamente sin JS y con movimiento reducido.

Interacción enriquecida, desde librerías

Las páginas estáticas se sienten baratas. Usa librerías de componentes y animación activamente para que cada interacción se sienta viva:

  • Cada estado recibe retroalimentación: hover, presión, foco, carga/ejecución, éxito/error, aparecer/desaparecer, cambio de diseño. Planifica estos en los storyboards de interacción, no como una idea tardía.
  • Prefiere un componente prefabricado bien construido sobre un efecto escrito a mano. Asigna cada interacción a un patrón, luego elige el componente de las librerías seleccionadas para este proyecto (references/ui-references.md, "Patrones de interacción").
  • Las demostraciones de producto se mueven: tareas reales progresando, resultados llegando, números cambiando, escenas cambiando.
  • Mantenlo con propósito: el movimiento explica el estado o dirige la atención a lo que cambió. Los efectos decorativos pesados pertenecen a las páginas de marketing, no a las pantallas de trabajo. Respeta el movimiento reducido en todas partes.

Elección de librerías

Elige librerías de componentes y animación para el proyecto; ninguna es obligatoria.

  • Proyecto existente: usa lo que ya tiene; añade una librería solo para cubrir una carencia, y nunca una que se superponga con una existente.
  • Proyecto nuevo: elige según el tipo de proyecto, framework y necesidades (criterios y candidatos en references/build-patterns.md, "Elección de librerías"). Mantén un sistema base de componentes y una librería principal de animación a menos que haya una razón clara.
  • Prefiere fuentes que se instalen como código fuente editable en el proyecto (registro/CLI o copia) sobre paquetes opacos, para que los componentes sigan los tokens del proyecto.

Reglas ganadas con esfuerzo (detalles en build-patterns)

  • Cada tono de texto debe pasar 4.5:1 sobre la superficie en la que se asienta; comprueba el token más tenue sobre el relleno del panel, no solo sobre el fondo de la página.
  • Sin desvanecimiento de opacidad en las entradas above-the-fold y sin atenuación de opacidad para estados "inactivos" — las auditorías de axe durante la animación lo marcan como problema de contraste. Usa entradas solo de transformación y cambios de color.
  • Los envoltorios de animación no deben colocarse entre <ul>/<ol> y <li>; anima dentro del <li>.
  • Píldoras deslizantes: coloca la etiqueta en un span relative sobre una píldora absoluta; no uses -z-10 + isolate.
  • Los contadores renderizan el valor final en el servidor y animan solo cuando están en la vista.
  • En sitios multilingües, cada cadena visible pasa por i18n, incluida la UI de demostración dentro de ventanas simuladas y sesiones reproducidas.
  • Las cuadrículas necesitan una columna única explícita / pistas minmax(0,1fr) y la raíz de la página necesita desbordamiento horizontal oculto para evitar desbordamiento en móviles.

Skills relacionados