Figma Make: pack de 3 skills para sistemas de diseño

La versión que salió sin respetar la marca

La versión de revisión estaba casi bien. Y justo ahí estaba el peligro. Los botones tenían un radio de 12px, aunque el sistema está fijado en 8px desde el rebranding. El acento principal aparecía con un tono parecido a #18C5DA: visualmente cercano al #06B6D4 del cliente, pero la diferencia saltaba a la vista al pegarlo en el selector de color de Figma. Apenas tres frames después, la escala tipográfica ya usaba 18px para el cuerpo cuando el sistema establece 16px.

El prompt que había escrito esa mañana no tenía nada de malo. El problema estaba en el que había escrito seis prompts antes. Figma Make conserva el contexto durante la sesión, pero las reglas del sistema de diseño pierden peso cuanto más se aleja el modelo del punto en que se introdujeron. Para cuando estaba afinando la tercera variante del hero, ya improvisaba valores de tokens que parecían razonables. Las notas de la versión de mayo de 2026 señalan precisamente esa brecha como el problema que resuelven las skills personalizadas: un conjunto empaquetado de instrucciones, disponible bajo demanda, que se incorpora a cada prompt sin volver a pegarlo. (Resumen de notas de la versión de Figma, mayo de 2026)

Después de crear el pack que aparece a continuación, volví a ejecutar el mismo brief en Make. Radio del botón: 8px. Acento: #06B6D4. Cuerpo: 16px. La skill no volvió más inteligente a Make; hizo que las reglas fueran imposibles de olvidar.

El brief: lo que exige realmente el sistema de diseño del cliente

El sistema al que se refiere este artículo pertenece a un cliente real. Estos son sus tokens, con los datos sensibles eliminados:

• Color: fondo #0A0E14, primer plano #E6EDF3 y un único acento #06B6D4. Sin acento secundario. Sin degradados.
• Espaciado: base de 8px. Escala permitida: 8 / 16 / 24 / 40. Ningún valor intermedio ni fuera de ese rango.
• Escala tipográfica: 14 / 16 / 20 / 32 / 48. El cuerpo es 16. Nunca 18.
• Radio: 8px en todas las superficies interactivas. 0 en tarjetas. Sin excepciones.
• Botón: un componente, tres estados: default, hover y disabled. El acento rellena el estado default; disabled usa el color de primer plano con una opacidad del 30%.

Un prompt genérico como «respeta nuestra marca» falla en todos esos puntos porque los adjetivos dejan demasiado margen. «Fresco, minimalista y con un solo acento» podría describir mil sistemas. El modelo no necesita un moodboard; necesita la tabla. El objetivo es que cada diseño creado en Make para este cliente se valide contra ella sin tener que volver a escribirla en cada sesión.

El pack de 3 skills para Figma Make: los archivos .md

Las skills personalizadas de Figma Make son archivos Markdown individuales que siguen la especificación Agent Skills. El campo name del frontmatter se convierte en el comando con barra. Se instalan por cuenta, permanecen disponibles en todos los archivos de Make de esa cuenta y, un detalle importante, deben ser autocontenidas: no admiten directorios scripts/, references/ ni assets/. Todo lo que el modelo deba utilizar tiene que estar incluido en las propias instrucciones. (Skills personalizadas para Figma Make, ayuda de Figma)

Tres skills cubren el 90% de lo que antes tenía que volver a escribir.

/follow-ds-guidelines

Es la tabla literal de tokens convertida en instrucciones. Sin interpretaciones ni adjetivos.

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

Es una skill de revisión. Make audita el frame actual contra la tabla de tokens y devuelve una lista de resultados aprobados o fallidos, identificando cada valor problemático por su código hexadecimal y sus píxeles.

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

La skill de datos de muestra inserta textos provisionales aprobados por el cliente. Así, las versiones de revisión dejan de llegar con lorem ipsum o con nombres de empresas inventados por el modelo que más tarde termina cuestionando el equipo legal. (Notas de la versión de mayo de 2026)

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

Tres archivos. Cada uno reemplaza algo que antes copiaba una y otra vez.

Cómo conectar Notion para que la skill lea el sistema actualizado

El enfoque de tokens estáticos de /follow-ds-guidelines funciona mientras el sistema no cambia. En cuanto el cliente actualiza un token —y ocurrirá—, la tabla incluida queda obsoleta. La solución es combinar la skill con un conector para que Make consulte la fuente actualizada. (Conectores en Figma Make, ayuda de Figma)

En el archivo de este cliente, el patrón es sencillo: el sistema de diseño vive en una única página de Notion con los mismos encabezados que la skill (Color, Spacing, Type ramp, Radius, Button). Invoco la skill y el conector desde el mismo prompt.

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

El mismo prompt puede obtener un PRD de Drive con la misma estructura —@Drive "Halcyon pricing PRD"— para que Make reúna en una sola operación el contexto del sistema de diseño y el de la especificación. (Resumen de notas de la versión de mayo de 2026)

Mi criterio con cada cliente es este: tokens incluidos en la skill si el sistema no se ha movido en un trimestre; datos obtenidos mediante el conector si todavía está evolucionando. El archivo .md de la skill no cambia entre ambos casos; cambia el prompt. Es intencional. No quiero acumular una skill distinta por cliente, sino una sola que sepa cuándo aceptar valores que la sustituyen.

Conviene distinguirlo de la skill /prototype-to-figma del servidor MCP de Figma. Esa viene preinstalada para los recorridos de código a lienzo y no la escribe el usuario. Las skills personalizadas de Make funcionan al revés: las crea el usuario, viven dentro de Make y no intervienen en la capa MCP.

Lo que falló: falta de determinismo y coste de compartir

El anuncio dejó fuera tres aspectos.

La compatibilidad con modelos es más limitada de lo que sugieren los documentos. Por ahora, las skills personalizadas solo funcionan con el modelo predeterminado de Figma Make y Claude Opus 4.7. Si el equipo ha estandarizado otro modelo en Make, la skill no se aplica y tampoco aparece un error claro: simplemente deja de hacer cumplir las reglas. (Skills personalizadas para Figma Make, ayuda de Figma) En un proyecto de equipo, es lo primero que compruebo antes de investigar por qué el radio vuelve a estar mal.

Los resultados son consistentes «very often» (“muy a menudo”), no idénticos. Así lo expresa la propia documentación de Figma. Como el modelo no es determinista, /design-crit puede pasar por alto alguna desviación en un frame complejo o marcar como error una decisión intencional. (Skills personalizadas para Figma Make, ayuda de Figma) Uso la skill de crítica como primera revisión rápida, no como aprobación final.

El coste de compartirlas es el verdadero problema operativo. Hoy las skills personalizadas pertenecen a cada cuenta. Para instalar el pack en la cuenta de otra persona hay que exportar los archivos .md y esa persona debe subirlos por su cuenta. No existe una publicación a nivel de organización. (Skills personalizadas para Figma Make, ayuda de Figma) En un estudio que gestiona varios sistemas de clientes, esta fricción es real: cada incorporación exige instalar manualmente todas las skills activas y cada actualización obliga a exportarlas de nuevo. La solución es poco emocionante, pero funciona: versionar los archivos .md en el repositorio del cliente —nosotros los guardamos junto a los tokens de diseño en el mismo monorepo—, etiquetar las versiones y convertir el paso de subida en un proceso con una única fuente de verdad, no en un mensaje de Slack.

Para quienes gestionan estudios de diseño sobre plataformas con este tipo de coste por usuario, ya expliqué cómo calcular el precio del plan premium de Webflow por el mismo motivo: las herramientas cobran por la superficie visible; el equipo paga por la fricción de integración que queda debajo.

La conclusión: qué pertenece a una skill y qué debe seguir en manos humanas

Después de varias semanas aplicándolo en DVNC.studio, mi regla es simple: todo lo que he escrito más de dos veces va a una skill. Tablas de tokens, listas de control para críticas, convenciones de datos de muestra y textos estándar para anotaciones de accesibilidad. Nada de eso es creativo. Todo era trabajo repetitivo.

Lo que sigue siendo humano es la decisión. /design-crit detecta un valor que se sale del sistema, pero no decide si es un error o una excepción deliberada para una pieza de marketing puntual. La skill sabe decir «este radio es 12 y debería ser 8». No sabe concluir «este radio es 12 porque el concepto de campaña necesitaba una tarjeta más suave y lo acordamos el martes». Ese criterio sí es el trabajo.

La acción para el próximo martes: elige el sistema de cliente que más utilizas y abre un archivo .md. Pega la tabla de tokens igual que hice con la de Halcyon. Guárdalo como follow-ds-guidelines.md, súbelo como skill personalizada, ejecuta un proyecto real con ella y después aplica /design-crit al resultado para compararlo manualmente con la tabla de tokens. Si la skill detecta lo mismo que detectarías tú, habrás eliminado una hora semanal de repetición de prompts por cliente. Si se le escapa algo evidente, la corrección está en el archivo .md, no en el historial de prompts.