Instalación: dos comandos
Anthropic distribuye la capacidad de diseño frontend dentro del plugin frontend-design, disponible a través del marketplace oficial de plugins de Claude Code (verificado por Anthropic, con más de un millón de instalaciones). Los nombres pueden generar confusión: el *plugin* es la unidad de instalación; la *capacidad* (skill) es lo que contiene y lo que se activa al realizar trabajo de UI. La instalación requiere dos comandos de barra dentro de una sesión de Claude Code:
- 1
Añadir el marketplace oficial
Configuración única; registra el catálogo de plugins de Anthropic.
/plugin marketplace add anthropics/claude-code - 2
Instalar el plugin
A partir de entonces, la capacidad se carga automáticamente siempre que su solicitud sea trabajo de frontend; no es necesario invocarla.
/plugin install frontend-design@claude-code-plugins
Lo que obtiene no son scripts ni componentes: todo el contenido del plugin es un archivo SKILL.md de 55 líneas en el repositorio público de Anthropic. Lo hemos analizado para que el resto de esta página describa el archivo real y no el resumen publicitario.
Qué cambia realmente la capacidad
Una capacidad es un conjunto de instrucciones que se carga cuando es relevante en lugar de en cada solicitud: la parte bajo demanda del stack de archivos del agente. Esta se carga cuando su solicitud es trabajo de UI (su descripción cubre "construir una nueva UI o remodelar una existente") y sitúa al modelo en un rol específico: el de un director de diseño en un estudio pequeño cuyo cliente ya ha rechazado propuestas basadas en plantillas. Las instrucciones siguientes son inusualmente concretas:
- Identifica los valores predeterminados de la IA y los prohíbe. El archivo describe los tres estilos en los que el diseño de la IA suele "agruparse": crema cálido cercano al
#F4F1EAcon tipografía serif y acento terracota; casi negro con un acento verde ácido o bermellón; y estilo periódico de líneas finas con radio cero. Se le indica al modelo que trate estos estilos como predeterminados, no como opciones. Es el propio equipo de Anthropic confirmando por qué los sitios web de IA se ven iguales. - Obliga a planificar antes de codificar. Dos pasos: primero, idear un sistema de tokens compacto (de 4 a 6 valores hexadecimales con nombre, dos o más roles tipográficos, un concepto de diseño y un "elemento firma" por el cual se recordará la página); luego, criticar ese plan frente al brief, preguntándose si el mismo resultado aparecería para cualquier prompt similar, y solo entonces, construir.
- Trata la tipografía y la estructura como significado. La combinación tipográfica debe transmitir la personalidad de la página, y los recursos estructurales como la numeración 01 / 02 / 03 solo están permitidos cuando el contenido es realmente una secuencia.
- Establece un suelo de calidad. Diseño responsive hasta móvil, foco de teclado visible, respeto a la reducción de movimiento y una sección completa sobre redacción de interfaces (voz activa, "Guardar cambios" en lugar de "Enviar", errores que expliquen qué sucedió).
Se trata de un brief de diseño genuinamente bueno, y es la razón por la cual vale la pena instalar el plugin. Sin embargo, observe lo que produce el proceso: un sistema de tokens nuevo, inventado según el brief. Ese es el límite del alcance, y el propio archivo lo insinúa: "Los creadores humanos tienen memoria y siempre intentan hacer algo nuevo". La capacidad no tiene memoria. La suya debe residir en otro lugar.
La brecha: el criterio no es lo mismo que los valores
Una capacidad define *cómo decidir*. No define *qué se decidió*. Esta distinción parece académica hasta que se comparan dos sesiones lado a lado.
Lea de nuevo el proceso de dos pasos: la capacidad instruye al modelo para *inventar* un sistema de tokens de 4 a 6 colores y un elemento firma para cada brief, y a rechazar cualquier plan que se parezca a lo que produciría para un prompt similar. Por sesión, es exactamente la instrucción correcta; es lo que hace que las pantallas individuales sean distintivas. Entre sesiones, es un motor de divergencia: la capacidad no tiene forma de saber que su color primario es oklch(0.55 0.19 45), porque nunca se lo dijo y no hay ningún lugar en el archivo para que ese dato resida, y su propio proceso empuja cada nueva sesión hacia un sistema nuevo, defendible y diferente.
Dos sesiones, dos botones buenos, dos azules diferentes. Ninguno es un error. Juntos, son un problema de marca.
| Capacidad de diseño | DESIGN.md + tokens | |
|---|---|---|
| Suministros | Criterio: cómo decidir | Valores: qué se ha decidido |
| Espaciado | Utiliza una escala | Define qué escala |
| Color | Elige algo con buen contraste | Nombra su rampa exacta |
| Persiste en una nueva sesión | Sí, como comportamiento | Sí, como los mismos valores |
| Dos pantallas coinciden | Solo por coincidencia | Por construcción |
Reprodúzcalo usted mismo
No se fíe de palabra. La prueba es corta y el resultado es inequívoco.
- 1
Solicite una tarjeta de precios en una sesión nueva
Con la habilidad activa y sin un sistema de diseño presente. Guarde el resultado.
- 2
Inicie una sesión genuinamente nueva
No un mensaje nuevo: una sesión nueva, para que no se arrastre nada.
claude - 3
Solicite un panel de ajustes para el mismo producto
Misma redacción sobre el producto, sin referencia al primer componente.
- 4
Compare las diferencias entre ambos
Compare el color primario, el radio del borde, el tamaño de fuente base y el espacio vertical entre la etiqueta y el control.
- 5
Analice el resultado con honestidad
Ambos parecerán competentes. En nuestras ejecuciones, tres o cuatro de esos cuatro valores difieren, y cada uno es, individualmente, una elección razonable.
Si sus dos resultados coinciden estrechamente, compruebe si hay algo más suministrando constantes: un archivo de tema existente, una librería de componentes ya presente en el repo o una sesión prolongada. Ese es el punto: que el resultado coincida significa que los valores provienen de algún lugar duradero, no de la habilidad.
Cerrando la brecha
Conserve la habilidad. Está realizando una tarea que nada más hace. Añada la capa que no puede contener: un set de tokens más un archivo DESIGN.md en el repo, que el agente lea al inicio de cada sesión.
La división del trabajo es clara una vez que ambos están implementados. El archivo responde a *qué* azul, *qué* radio, *qué* escala tipográfica. La habilidad responde a cómo componerlos en una pantalla que se lea bien. Ninguno sustituye al otro, y el error común es asumir que la habilidad hace que el archivo sea innecesario.
- 1
Instale un kit en el repo
Esto escribe el archivo DESIGN.md más los archivos de tokens que leerá su agente.
npx --yes identityforge@latest install --client claude-code - 2
Aplique el kit que desee
Los kits gratuitos no requieren cuenta.
identityforge apply ambient-sage - 3
Vincule AGENTS.md hacia él
Una sola línea, para que el contrato de diseño sea descubrible en lugar de incidental.
Never hardcode theme colors. Use the semantic tokens in DESIGN.md. - 4
Repita la prueba de las dos sesiones
Mismo procedimiento que el anterior. Los valores ahora deberían coincidir exactamente, ya que se leen en lugar de volver a decidirse.
Déle a la habilidad algo sobre lo cual ser consistente
Un kit instala los tokens y el archivo DESIGN.md que la habilidad de diseño no tiene forma de transportar. La habilidad aporta la ejecución técnica; el archivo aporta su marca.
¿Respetará una base de código y un tema existentes, o hará lo que quiera?
Esta es la pregunta que la gente realmente hace sobre las habilidades de diseño, y casi nada de lo escrito al respecto la responde. La respuesta honesta: una habilidad respeta su tema solo en la medida en que dicho tema exista como valores que pueda leer. Una habilidad es un conjunto de instrucciones sobre cómo trabajar. No es una fuente de sus valores.
Esa distinción decide el resultado en una base de código existente:
| El tema existe como tokens + DESIGN.md | El tema existe en Figma y en la cabeza de las personas | |
|---|---|---|
| Lo que la habilidad lee | Sus valores reales | Nada. No tiene fuente |
| Lo que produce | Componentes de su sistema | Componentes plausibles basados en los valores predeterminados de la librería |
| A través de las sesiones | Estable: se vuelve a leer cada vez | Diverge, y sigue divergiendo |
| Qué solucionar primero | Nada | Los valores ausentes, no la habilidad |
Una habilidad no puede proporcionar valores que nunca se le dieron
Si una habilidad produce resultados fuera de marca en una base de código con tema, la causa habitual es que el tema no es legible desde el repositorio. Añadir una habilidad mejor no soluciona esto. Añadir los valores, sí.
Hay una versión medible de esto. Analizamos 299 archivos DESIGN.md públicos y descubrimos que, de los 72 que describían un sistema visual, el 86% no utilizaba nombres de roles de color semánticos: enumeraban códigos hex o nombraban los colores por su tono. Una habilidad a la que se le asigna --primary puede aplicar su sistema a un componente que nadie describió. Una habilidad a la que se le da una tabla de códigos hex solo puede copiar, y es en el copiado donde empieza a adivinar.
- 1
Compruebe si su tema es legible
Busque un DESIGN.md o un archivo de tokens en la raíz del repositorio. Si la única fuente es Figma, la habilidad no tiene base sobre la cual trabajar.
- 2
Haga que los valores sean semánticos
Use roles en lugar de tonos, para que la habilidad pueda ubicarlos correctamente en casos que usted nunca haya documentado.
- 3
Referéncielos desde AGENTS.md como una prohibición
Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md. - 4
Ejecute la misma compilación en una sesión nueva
Si el color primario y el radio son los mismos, significa que está leyendo. Los fallos leves indican que está recordando, y la memoria se degrada.
¿Habilidad, plugin o un anuncio en un marketplace?
La mayoría de los artículos sobre esto son resúmenes, y los resúmenes usan estos tres términos indistintamente. No son lo mismo, y la diferencia determina si lo que ha instalado puede siquiera cargarse.
| Qué es | Cómo llega al modelo | |
|---|---|---|
| Una habilidad | Un directorio con un archivo SKILL.md: una descripción más instrucciones | El modelo la carga cuando la descripción coincide con lo que usted ha solicitado |
| Un plugin | Un paquete que puede agrupar habilidades, comandos, subagentes y hooks | Se instala una sola vez; todo lo que agrupe queda disponible |
| Un anuncio de marketplace | Una entrada de índice que apunta a un plugin publicado por alguien | Desde un anuncio no se carga nada. Es una página de catálogo |
La consecuencia práctica es la condición de carga. El modelo selecciona una habilidad basándose en su descripción, por lo que solo interviene cuando su solicitud parece un trabajo de diseño. Si pide "una página de ajustes", se activa. Si pide "corregir el padding en la línea 40", puede que no lo haga, porque eso parece una edición y no una tarea de diseño, y obtendrá una edición ordinaria sin la calidad técnica por la que instaló la habilidad.
Forma sencilla de saber si se ha activado
Ejecute la misma solicitud dos veces en sesiones nuevas: una redactada como tarea de diseño y otra como edición mecánica. Si los resultados difieren en el ritmo del espaciado y la cobertura de estados, y no solo en la redacción, está viendo cómo la habilidad se activa y desactiva. Ese es el fallo que la gente reporta como "a veces funciona".
Cuando la habilidad y su archivo DESIGN.md no coinciden
Esta es la pregunta que los resúmenes comparativos omiten por completo, y es la que importa una vez que tiene ambos. Entran en conflicto porque están escritos por personas diferentes para propósitos diferentes. Su archivo dice que el primario es oklch(0.55 0.19 45). El criterio de la habilidad dice que un color primario debe superar un umbral de contraste respecto a la superficie sobre la que se asienta. En una tarjeta clara, coinciden. En su superficie oscura elevada, puede que no.
Ninguna de las dos capas está mal y no hay un árbitro integrado: el modelo lo resuelve y, por defecto, prioriza la instrucción que sea más específica y se haya leído más recientemente. Por eso la resolución debe quedar escrita en lugar de darse por sentada:
- Los valores no son negociables; la composición sí. Indíquelo así en
AGENTS.md. El hex, el radio y la escala tipográfica provienen del archivo. Cómo se organizan en una pantalla es decisión de la habilidad. - Dé al archivo la salida de emergencia que la habilidad necesita. El conflicto anterior solo existe porque el sistema tiene un único color primario. Implemente un primario que también sea legible en sus superficies oscuras, o un par documentado, y el desacuerdo desaparecerá en lugar de ser juzgado sesión a sesión.
- Escriba prohibiciones, no preferencias. "Preferir design tokens semánticos" pierde ante un argumento de contraste específico. "Nunca hardcodear colores del tema" no pierde, porque no deja nada que ponderar.
- Espere silencio en caso de conflicto. El modelo no le avisará de que ha anulado su token. La única detección fiable es buscar mediante grep en el diff los valores literales de color y espaciado.
# the only conflict detector that actually fires: literals in the diff
git diff | grep -nE '#[0-9a-fA-F]{3,8}|oklch\(|rgb\(|[0-9]+px'Ejecute esto en cada diff generado por un agente. Un resultado limpio significa que los valores fueron leídos. Cualquier coincidencia es un lugar donde el criterio ha sustituido silenciosamente una decisión que usted ya había tomado; es la misma deriva que en la prueba de las dos sesiones, solo que llega por una puerta diferente.
¿Vale la pena instalar la habilidad?
Sí. Mejora mediblemente la calidad de las pantallas individuales y no cuesta nada probarla. El argumento aquí es contra el hecho de tratarla como una solución completa, no contra la habilidad en sí.
¿Hace que un sistema de diseño que la habilidad sea redundante?
No, y este es el error simétrico. Los tokens le dicen a un agente qué valores usar; no dicen nada sobre cómo componer una pantalla que se lea bien. Los proyectos con un sistema sólido pero sin guía de diseño producen diseños alineados con la marca pero con una jerarquía débil.
¿Solucionará un prompt más largo la inconsistencia entre sesiones?
Solo dentro de una sesión, y cada vez menos a medida que la sesión crece. Una sesión nueva comienza de cero, por lo que cualquier cosa que quiera que perdure debe vivir en un archivo.
Si solo pudiera elegir uno, ¿la habilidad de diseño o un DESIGN.md?
El archivo, sin ninguna duda. Sin él, cada sesión redefine su marca y el resultado diverge permanentemente. Sin la habilidad, obtiene pantallas alineadas con la marca pero con una jerarquía más débil, lo cual es un techo de calidad y no un problema acumulativo. Solucione primero el problema acumulativo.
¿Se aplica esto también a Cursor y otros agentes?
La habilidad específica es de Claude Code, pero la naturaleza del problema no lo es. Cualquier mecanismo que aporte criterio de diseño sin valores de diseño produce la misma inconsistencia entre sesiones.