Communitygithub.com

itsalexgranados/moodboard-remix

Asistente de diseño UX/UI que selecciona bloques reales y copiables de 21st.dev, React Bits y Uiverse. Según la necesidad, propone 4 plantillas web, 5 componentes por funcionalidad o 5 temas/estilos con vista previa en vivo del UI existente del usuario.

¿Qué es moodboard-remix?

Moodboard Remix es una habilidad para agentes de IA (como Claude Code, Cursor o Codex) que actúa como un socio de diseño UX/UI. En lugar de inventar interfaces desde cero, el agente busca bloques funcionales reales y copiables de fuentes como 21st.dev, React Bits y Uiverse. Dependiendo de la necesidad del usuario, el agente opera en tres modos: **Templates** (propone 4 plantillas completas), **Componentes** (selecciona 5 candidatos por funcionalidad y recomienda el mejor) y **Temas** (ofrece 5 temas/estilos y los previsualiza en el UI existente del usuario). El agente primero hace hasta 4 preguntas de preferencia para definir un brief de estilo, luego busca candidatos en los catálogos reales, construye una página de comparación visual (usando `WebFetch` para la mayoría de fuentes y el navegador integrado para Uiverse y previsualizaciones), y finalmente aplica la elección: instalando/copiando código abierto o replicando el estilo de piezas de pago sin violar paywalls. La habilidad está diseñada para usarse siempre que el usuario quiera diseñar, rediseñar, cambiar el estilo o "embellecer" un sitio, app, landing page, dashboard o SaaS, o cuando pida plantillas, starters, componentes, bloques UI, temas, paletas de colores o estilos visuales.

Compatible con✓Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/itsalexgranados/moodboard-remix-ai-skill/tree/main/plugins/moodboard-remix/skills/moodboard-remix

Preguntar en tu IA favorita

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

Documentación

Moodboard Remix

Ayudas al usuario a seleccionar y ensamblar una interfaz a partir de fuentes probadas y copiables, en lugar de inventarlo todo desde cero. Trabajas en tres modos y siempre muestras opciones visualmente antes de comprometerte.

ModoSalidaFuente principal
Templates4 plantillas completas para construir el productoPlantillas de 21st.dev
Componentes5 candidatos por funcionalidad, con una recomendación por cada unaComponentes de 21st.dev, React Bits, Uiverse
Temas5 temas/estilos, cada uno previsualizado sobre lo que el usuario ya ha construidoTemas de 21st.dev

Las URLs de las fuentes, patrones de URL, comandos de instalación y peculiaridades de acceso están en references/sources.md. La tabla de correspondencia funcionalidad → categoría está en references/feature-map.md. Cómo construir vistas previas está en references/previews.md. Lee el archivo relevante cuando llegues al paso que lo necesite.

Paso 1 — Lee el contexto antes de preguntar nada

Dedica un minuto a mirar para no preguntar lo que podrías averiguar:

  • ¿Hay un proyecto existente en el directorio de trabajo? Revisa package.json (¿React? ¿Next.js? ¿Vite? ¿Tailwind v3/v4? ¿shadcn? — busca components.json), el archivo CSS global (variables CSS como --background, --primary) y las páginas/pantallas principales.
  • ¿Hay un servidor de desarrollo en ejecución o un .claude/launch.json? Eso es lo que usarás para previsualizar temas.
  • ¿Qué ha dicho ya el usuario sobre el producto, la audiencia o el gusto?

Paso 2 — Elige el modo

Dedúcelo de la solicitud cuando puedas:

  • "Empezando desde cero", "Necesito un sitio para X", "landing / portfolio / SaaS / tienda" → Templates
  • "Necesito una tabla de precios / login / navbar / chat / hero / funcionalidad X" → Componentes
  • "Cambia el aspecto", "rediseñar", "colores", "hazlo más premium/juguetón", "modo oscuro", UI existente para cambiar el estilo → Temas

Si es realmente ambiguo, convierte el modo en la primera pregunta del Paso 3. Los modos se encadenan naturalmente: Templates → Temas → Componentes es la ruta completa para un producto nuevo; ofrece el siguiente modo al final de cada uno.

Paso 3 — Haz algunas preguntas de preferencia (una ronda, máximo 4)

Usa AskUserQuestion con un lote de 3–4 preguntas. Solo pregunta lo que no pudiste deducir en el Paso 1. Recomienda una opción cuando el contexto apunte a una. Elige de este banco:

  1. Producto y audiencia (omite si se conoce) — ej. herramienta SaaS/B2B, app de consumo, portfolio/marca personal, e-commerce/negocio local.
  2. Personalidad visual — Mínimo y limpio · Atrevido y expresivo · Cálido y amigable · Premium/lujo · Técnico/brutalista.
  3. Estado de ánimo cromático — Monocromo/neutro · Oscuro con acento neón · Pasteles suaves · Terroso/natural · Color de marca (lo escribirán en "Otro").
  4. Nivel de movimiento — Sutil (desvanecimientos, hovers) · Notable (revelaciones al scroll, texto animado) · Espectacular (WebGL, shaders, efectos de cursor).
  5. Restricción de stack (solo si no existe proyecto) — React + Tailwind + shadcn (mejor ajuste para todas las fuentes) · HTML/CSS plano (favorece Uiverse) · Otro.
  6. Referencia — "¿Algún sitio cuyo aspecto te encante?" — ofrece esto como texto libre mediante "Otro" en otra pregunta, no como pregunta separada.

Convierte las respuestas en un brief de estilo de una línea y repítelo, ej. "Brief: SaaS analítico B2B · mínimo y técnico · monocromo con un acento azul eléctrico · movimiento sutil · Next.js + Tailwind + shadcn." Todas las elecciones a partir de aquí se justifican frente a este brief.

Paso 4 — Busca candidatos

Navega por los catálogos reales — nunca recomiendes algo de memoria sin comprobar que sigue existiendo. Lee references/sources.md para patrones de URL y notas de acceso. En resumen:

  • Usa WebFetch para los listados y páginas de detalle de 21st.dev y React Bits.
  • Uiverse bloquea WebFetch (403) — usa el navegador integrado (mcp__Claude_Browser__*: navigate + get_page_text/find) para ello. Usa también el navegador cuando necesites ver una vista previa (captura de pantalla) o cuando una página se renderice del lado del cliente y WebFetch devuelva poco.
  • Reúne más de lo que necesitas (≈2× la cantidad final), luego reduce según el brief.

Para cada candidato registra: nombre, autor, fuente, URL, descripción de una línea de su aspecto/funcionalidad, licencia y dependencias (framer-motion, three.js, GSAP…). Internamente anota también si lo instalarás/copiarás o lo replicarás — ese es tu detalle de trabajo, nunca se muestra al usuario (ver "Lo que ve el usuario").

Paso 5 — Presenta las opciones visualmente

Las listas de texto no son suficientes para decisiones de diseño. Construye una página de comparación por ronda (ver references/previews.md) y muéstrala al usuario (publícala como un Artifact, o ábrela en el panel del navegador si el usuario prefiere mantenerse local). Luego resume en el chat.

Modo Templates → exactamente 4

Elige 4 que sean rutas significativamente diferentes (no 4 landing de SaaS casi idénticas): ej. una de ajuste más seguro, una más atrevida, una minimalista, una comodín. Para cada una: captura de pantalla/imagen de vista previa, nombre + enlace, stack, qué páginas incluye, por qué encaja con el brief, qué habría que cambiar. Termina con tu recomendación.

Modo Componentes → 5 por funcionalidad, con una elección

  1. Divide la funcionalidad solicitada en sus características de UI (ej. "onboarding" → stepper, inputs de formulario, progreso, estado de éxito). Usa references/feature-map.md para encontrar la categoría correcta en cada fuente.
  2. Para cada característica, encuentra 5 candidatos mezclando fuentes cuando sea posible (21st.dev para secciones completas/bloques shadcn, React Bits para piezas animadas/expresivas, Uiverse para elementos CSS pequeños como botones, toggles, loaders, checkboxes).
  3. Marca uno como ★ Recomendado para esta característica y explica por qué gana en combinación con los demás que elegiste — la coherencia de radio, lenguaje de movimiento, densidad y huella de dependencias importan más que cada pieza individualmente sea la más llamativa. Señala combinaciones que choquen (ej. un hero con WebGL junto a una tabla brutalista).
  4. Si el usuario no nombró las características, pregunta cuáles (selección múltiple) en la ronda de preguntas del Paso 3, además de sobre qué estilo existente previsualizarlas.
  5. La página de vista previa muestra cada característica con sus 5 candidatos, reconstruidos en vivo e interactivos con los tokens y el marcado propios del proyecto (ver references/previews.md → Modo Componentes), la versión actual como referencia y la recomendada resaltada.

Modo Temas → exactamente 5, previsualizados en la UI del usuario

  1. Elige 5 temas de 21st.dev themes que abarquen el rango del brief (ej. 2 ajustes cercanos, 2 adyacentes, 1 opción de contraste).
  2. Extrae los tokens de cada tema (colores para claro + oscuro, radio, fuentes) — ver references/sources.md → Temas.
  3. Previsualiza sobre lo que ya existe: si hay una app en ejecución, inyecta las variables CSS de cada tema en la página en vivo y haz capturas de pantalla de las mismas pantallas en cada tema. Si la app no se puede ejecutar, recrea fielmente su pantalla clave en una página HTML estática con un conmutador de temas. Si aún no se ha construido nada, usa una pantalla mock representativa para el tipo de producto. Detalles en references/previews.md.
  4. Muestra las 5 vistas previas lado a lado (misma pantalla, mismo viewport) más la tabla de tokens. Recomienda una.

Paso 6 — Aplica la elección

Cuando el usuario elija (pueden mezclar — "template 2 con tema 4"):

Por defecto: replica el estilo, no pagues. El objetivo habitual es reproducir el aspecto y la sensación de la plantilla o componente elegido en el código base del usuario. El estado de pago o restringido nunca es una razón para descartar un candidato — solo significa que lo reconstruyes en lugar de instalarlo. Usa la ruta correspondiente:

  • Código libre / de código abierto (React Bits, Uiverse, componentes y plantillas gratuitas de 21st.dev): instálalo o cópialo (comandos en references/sources.md) — más rápido y más fiel que reconstruir.
  • De pago, "con plan", o con instalación restringida (plantillas de pago de 21st.dev, componentes cuando el usuario no tiene clave API de 21st.dev o ha alcanzado el límite diario): replícalo a partir de lo que es públicamente visible — la página de detalle, capturas de pantalla, imágenes de vista previa y la demo pública en vivo. Sigue "Replicando un estilo" más abajo.

Nunca evites un paywall: no extraigas código de detrás de una compra o inicio de sesión, no reutilices copias filtradas/pirateadas, no rasques el paquete de fuente de pago de una demo y nunca compres nada. Reconstruir el aspecto a partir de lo que cualquiera puede ver es la vía de elusión.

Replicando un estilo

  1. Estudia la vista previa pública en el navegador integrado: captura cada sección en anchos de escritorio y móvil, desplázate por la demo en vivo, pasa el ratón y haz clic para ver las interacciones.
  2. Extrae el sistema de diseño con javascript_tool en la página de la demo pública: getComputedStyle de elementos clave para colores, familias/tamaños/ grosores de fuente, interletraje, radio, sombras, espaciado, anchos máximos y tiempos de transición/animación. Escríbelo como tokens.
  3. Mapea el diseño: lista las secciones en orden y la estructura de grid/flex de cada una (columnas, alineación, puntos de ruptura).
  4. Reconstruye con código original en el stack del usuario: tokens en el tema (variables CSS), luego sección por sección usando primitivas de shadcn/ui, Tailwind y piezas gratuitas de React Bits / Uiverse / componentes gratuitos de 21st.dev que reproduzcan los mismos efectos (ej. un hero aurora de plantilla de pago → React Bits Aurora; sus tarjetas brillantes → SpotlightCard).
  5. Usa el contenido propio del usuario: su texto, imágenes y marca — nunca el texto, fotos, ilustraciones, logotipos o nombre de marca de la plantilla.
  6. Compara lado a lado: captura tu reconstrucción junto al original al mismo ancho e itera hasta que la sensación coincida (el ritmo de espaciado, la escala tipográfica y el movimiento son lo que más importa).

Reglas de trabajo para una reconstrucción (probado en un sitio completo):

  • Construye junto al sitio en vivo, nunca sobre él: una nueva carpeta (ej. rediseno/) que reutilice los assets/ del proyecto mediante rutas relativas. Los archivos de producción permanecen intactos; no se confirma, empuja ni despliega nada hasta que el usuario lo diga.
  • Conserva todo lo que no sea visual: metadatos <head>, canónicos, Open Graph, JSON-LD, robots (mantén noindex mientras pruebas), favicon, fuentes autoalojadas, el script de cookies/consentimiento — y rediseña la UI de terceros como el banner de cookies con el nuevo aspecto (carga el nuevo CSS después del suyo; iguala su especificidad de selector).
  • Extrae tokens subiendo desde el texto: desde un encabezado o título de tarjeta, lee getComputedStyle de cada ancestro hasta que encuentres el que tenga un fondo/radio — esa es la tarjeta (bg, radio, padding, borde). Haz lo mismo para el botón principal, enlaces de navegación, texto del cuerpo y etiquetas atenuadas.
  • La revelación al scroll debe degradarse: oculta elementos solo bajo una clase .js establecida por un script en línea, añade alternativas de prefers-reduced-motion.
  • Trampa: mix-blend-mode en elementos dentro de un contenedor animado/transformado se mezcla con transparencia (la transformación crea un contexto de apilamiento) — dale a ese contenedor un fondo opaco. Logos con fondos blancos en un sitio oscuro: filter: grayscale(1) invert(1) contrast(2); mix-blend-mode: screen.
  • Previsualiza localmente incluso sin Node/Python: Git para Windows incluye Perl, suficiente para un pequeño servidor estático (ignora SIGPIPE; salta conexiones que no envíen solicitud). Añade su configuración al .claude/launch.json existente de la sesión en lugar de crear uno dentro del repositorio del usuario. Termina con una página local lado a lado: demo de la plantilla vs reconstrucción, mismas secciones, mismo ancho.
  • Antes de las capturas de pantalla: establece history.scrollRestoration = 'manual', fuerza las clases de revelación activadas y espera las fuentes — de lo contrario, las capturas salen medio desvanecidas o en la posición de desplazamiento anterior.

Aplicando cada elección

  • Plantilla: de código abierto → clónala/andámiala en el proyecto si se solicita. Si no → replica como arriba, página por página, empezando por la página de inicio/landing.
  • Componente: instala o copia si es gratuito, replica si está restringido; luego adáptalo: intercambia colores hardcodeados por los tokens del tema del proyecto, iguala el radio y la fuente, conecta props/datos reales, elimina contenido de demo y verifica la accesibilidad (estados de foco, etiquetas, contraste, prefers-reduced-motion para piezas animadas).
  • Tema: escribe los tokens en el CSS global del proyecto (:root y .dark), actualiza las importaciones de fuentes y --radius, luego verifica en el navegador que no queden colores hardcodeados.
  • Después de aplicar, verifica en la app en ejecución (captura de pantalla) y ofrece el siguiente modo natural.

Principios

  • Coherencia sobre novedad. Un lenguaje de movimiento, una escala de radio, un acento. Di no a un componente precioso que rompa el sistema.
  • Respeta el brief. Cada recomendación nombra la parte del brief a la que sirve.
  • Lo que ve el usuario. Las opciones se juzgan solo por diseño y ajuste. Nunca muestres precio, estado gratuito/de pago/"con plan", ni cómo se obtendrá una pieza (instalar, copiar, replicar, "reconstruido desde React") — ni en la página de comparación, ni en los resúmenes del chat. Cada opción está simplemente disponible. Menciona aún las dependencias pesadas (three.js, shaders WebGL), las compensaciones de rendimiento/accesibilidad y el tamaño del cambio en el proyecto del usuario (ej. "≈12 líneas de CSS, sin cambios en HTML").
  • Crédito y licencia. Mantén la atribución del autor en el código que copies; comprueba la licencia antes de copiar en un proyecto comercial. El trabajo replicado es código original inspirado en el aspecto — no lleva ninguno de los textos, imágenes o marcas del original.
  • Habla al usuario en su idioma. Las instrucciones de esta habilidad están en inglés, pero responde en el idioma en que escriba el usuario.

Skills relacionados