TL;DR
/design-syncno sube tu design system, lo compila. Convierte tu librería de componentes en un bundle que el agente de Claude Design ejecuta en el navegador, lo que impone un requisito que la documentación oficial no menciona: React. Paquete de React condist/publicado, o Storybook, entran. Vue, Angular o Svelte, hoy no, y tu camino es el MCP.
Claude Design no devuelve maquetas. Construye pantallas y prototipos que funcionan, y los renderiza en vivo en el navegador ejecutando código React. De fábrica los construye con componentes genéricos. La pantalla puede quedar bonita, pero no es tuya, y traducirla a tus componentes reales cuesta más que haberla hecho a mano.
/design-sync cierra ese hueco. A partir de que lo ejecutas, cada pantalla que produce el agente está hecha con tus piezas y mapea contra código que tu equipo puede enviar a producción.
Lo que no es
Entendí dos cosas mal antes de leer el código de la skill, y creo que le pasará a mucha gente.
No es una copia de tu repo en la nube. Compila. Coge tu dist/ ya construido y produce un paquete que el agente puede cargar y ejecutar, como un plugin. Llevarse ficheros tal cual también existe, pero eso es /design export, otro camino distinto.
No sincroniza tu aplicación. Sincroniza tu librería de componentes. Que tu producto sea Nuxt, Laravel o un monolito de PHP da igual, porque la aplicación no viaja. La pregunta no es en qué está hecho tu producto, es en qué están escritos tus componentes reutilizables.
Qué sube, y para quién
Por cada componente viajan varios artefactos, y cada uno tiene un lector distinto:
- El bundle compilado de tu
dist/con sus dependencias. Lo carga el runtime del agente, que es quien monta los componentes. - El CSS, los tokens y las fuentes, alcanzables desde
styles.css. Este es el que se rompe, y le dedico un apartado más abajo. - Un
.d.tspor componente, que es el contrato de API contra el que programa el agente. - Un
.prompt.mdpor componente, que es su manual de uso con ejemplos. - Un
.htmlde preview, y este sí es para ti: es la tarjeta que ves en el selector de componentes. - Un
_ds_sync.jsoncon hashes de contenido, para que el siguiente sync salte lo que no ha cambiado.
El principio que la skill repite en su propio texto es que se sube lo que ya construiste, nunca una reimplementación. Por eso verifica visualmente cada preview antes de subirla, y por eso un primer sync puede tardar horas en un repo grande.
Quién entra y quién no
| Tus componentes | ¿Entra en /design-sync? |
|---|---|
React publicados como paquete, con dist/ |
Sí, es la forma "package" |
| React con Storybook | Sí, y las previews salen de tus propias stories |
| Vue, Angular, Svelte | No, hoy no hay camino |
| Blade, Twig o plantillas de servidor | No |
No es un capricho del comando. El renderer de Claude Design ejecuta React, y tus componentes tienen que poder montarse dentro de él. El artículo de soporte presenta /design-sync como la vía para traer tu design system y no menciona el requisito en ningún sitio.
Si tus componentes no son de React, no te quedas fuera de Claude Design: diseñas ahí, te bajas el artboard .dc.html con el MCP y le pides a Claude Code que lo implemente contra tu repo. La traducción sigue existiendo, pero la hace el agente con tus componentes delante.
Cómo lanzarlo
1. Sitúate en el repo de tu design system
No en el de tu aplicación. El comando necesita el paquete que publica los componentes.
2. Ejecuta el comando
/design-sync
Solo lo puedes lanzar tú: la skill está marcada como no invocable por el modelo, así que Claude no puede arrancarla por su cuenta ni aunque se lo pidas de otra forma.
3. Confirma lo que te avisa antes de empezar
En un primer sync te dice que es una importación de alta fidelidad, que puede llevar horas en un repo grande y te pide confirmación explícita del gasto en tokens. Puedes interrumpirlo en cualquier momento sin romper nada.
4. Aprueba la subida una sola vez
Crea un proyecto nuevo, te pide el nombre y lanza una sola aprobación, rotulada con cuántos ficheros sube y cuántos borra. Después los componentes van apareciendo según se verifican, así que puedes abrir la URL del proyecto a mitad y verlo llenarse.
Lo que se rompió en mi prueba
Sincronicé un design system de cuatro componentes con los tokens en dist/tokens.css y un styles.css que los trae con un @import hermano. El converter no llega ahí, porque tokensPkg y tokensGlob solo miran dentro de node_modules/<paquete>. La validación cantó [CSS_IMPORT_MISSING] y [TOKENS_MISSING] con 19 custom properties sin definir: el bundle habría subido sin un solo token, con las tarjetas viéndose bien.
La salida fue un fichero de una línea enganchado por extraEntries, para que esbuild inline toda la cadena de @import dentro del CSS del bundle:
// .design-sync/ds-styles-entry.mjs
import "../dist/styles.css";
El segundo tropiezo fue el navegador. La verificación visual necesita uno, y sin el de Playwright cacheado son unos 200 MB de descarga, o apuntas DS_CHROMIUM_PATH al Chrome que ya tienes instalado.
Qué te deja escrito en el repo
Al terminar, .design-sync/ tiene el config.json con el proyecto fijado, un NOTES.md con lo aprendido, una preview por componente y un conventions.md. Ese último no es documentación decorativa: se antepone al README y acaba dentro del prompt del sistema del agente de diseño, así que ahí es donde le dices cómo se compone tu librería. Todo eso se comitea, y es lo que hace que el segundo sync sea rápido y no te cree un proyecto duplicado.
Los comandos de Claude Design, y cuál depende del MCP
Ninguno de estos comandos lo trae el MCP. Los slash commands son del cliente; el MCP solo aporta herramientas.
| Comando | Qué hace | Sobre qué actúa |
|---|---|---|
/design-sync |
Compila y sube tu design system | La herramienta nativa DesignSync |
/design-login |
Autoriza el acceso de design system para /design-sync |
La herramienta nativa DesignSync |
/design-consent |
Concede a Claude acceso a tus proyectos de Design | El permiso que necesitan las herramientas del MCP |
/design-revoke |
Retira ese permiso | El permiso que necesitan las herramientas del MCP |
/design (hub) |
Enruta sync, login, consent y revoke, y añade import, export y status |
Los cuatro comandos de arriba |
/design (lienzo) |
La skill del lienzo editable, otra cosa con el mismo nombre | Un Artifact local |
Dos detalles que explican por qué cuesta tanto encontrarlos. /design-consent y /design-revoke están marcados como ocultos, así que no salen en el menú de comandos por mucho que lo mires. Y hay dos registros distintos con el nombre design, el hub y la skill del lienzo, cada uno con su propia condición de activación, así que según tu cuenta te sale uno u otro.
Dónde encaja esto
Si lo que te molesta es que las UIs salen genéricas y no tienes design system, tu herramienta es la Frontend Design Skill, que sube el suelo estético desde cero. Ese tip dice que no la uses cuando ya tienes un design system establecido, y esto es exactamente lo que ocupa ese hueco: en vez de mejorar el gusto del agente, le cambias las piezas.
Y si tu fuente de verdad es Figma en lugar de un repo, el bucle es Figma más Chrome MCP.
Documentación oficial: Get started with Claude Design
Requisitos
- Design system en React, como paquete con
dist/publicado o con Storybook - Un navegador para la verificación visual, el de Playwright o el del sistema
- Cuenta de claude.ai de primera parte (no con API key, Bedrock ni Vertex)
- Política de organización que permita Claude Design
- Probado en Claude Code v2.1.234