Figma Make: 3 custom skills para aplicar o design system

Quando o Figma Make entregou um build fora da marca

O build enviado para revisão estava quase certo — justamente o tipo mais perigoso. Os botões tinham raio de 12px em um sistema fixado em 8px desde o rebranding. O destaque principal apareceu em algo próximo de #18C5DA: visualmente semelhante ao #06B6D4 do cliente, mas bastou colar o valor no seletor de cores do Figma para o desvio ficar evidente. Três frames depois, a escala tipográfica usava corpo de 18px onde o sistema especifica 16px.

O problema não estava no prompt que eu havia escrito naquela manhã, mas naquele de seis prompts atrás. O Figma Make mantém o contexto ao longo da sessão, porém as regras do design system perdem força à medida que o trabalho se distancia do ponto em que foram fornecidas. Quando você chega ao refinamento da terceira variação do hero, o modelo já começa a improvisar tokens que parecem plausíveis. As notas da versão de maio de 2026 descrevem exatamente essa lacuna como o motivo para as custom skills existirem: um conjunto empacotado e acionável de instruções que entra em qualquer prompt sem precisar ser colado outra vez. (Resumo das notas de versão do Figma, maio de 2026)

Depois de montar o pacote abaixo, rodei o mesmo briefing novamente no Make. Raio dos botões: 8px. Destaque: #06B6D4. Corpo do texto: 16px. A skill não deixou o Make mais inteligente — apenas tornou as regras impossíveis de esquecer.

O briefing: o que o design system do cliente realmente exige

O sistema citado neste artigo pertence a um cliente real. Abaixo estão os tokens, devidamente descaracterizados:

• Cor: fundo #0A0E14, primeiro plano #E6EDF3, um único destaque #06B6D4. Sem destaque secundário. Sem gradientes.
• Espaçamento: base de 8px. Escala permitida: 8 / 16 / 24 / 40. Nenhum valor intermediário nem fora dela.
• Escala tipográfica: 14 / 16 / 20 / 32 / 48. O corpo é 16. Nunca 18.
• Raio: 8px em toda superfície interativa. 0 nos cards. Sem exceções.
• Botão: um componente, três estados — padrão, hover e desabilitado. O destaque preenche o padrão; no estado desabilitado, o primeiro plano fica com 30% de opacidade.

Um prompt genérico como “siga a nossa marca” falha em todos esses pontos porque os adjetivos deixam margem para interpretação. “Frio, minimalista, com uma única cor de destaque” poderia descrever milhares de sistemas. O modelo não precisa do moodboard; precisa da tabela. O objetivo é fazer cada build criado no Make para esse cliente ser validado contra essa tabela, sem que eu tenha de redigitá-la em toda sessão.

O pacote de 3 custom skills: os arquivos .md completos

As custom skills do Figma Make são arquivos Markdown individuais que seguem a especificação Agent Skills. O frontmatter name vira o comando de barra. A instalação é feita por conta, as skills continuam disponíveis em todos os arquivos do Make que você possui e — ponto importante — cada arquivo precisa ser autossuficiente: nada de diretórios scripts/, references/ ou assets/. Tudo que o modelo deve usar fica diretamente nas instruções. (Custom skills para Figma Make, ajuda do Figma)

Três skills cobrem 90% do conteúdo que eu vivia redigitando.

/follow-ds-guidelines

A tabela literal de tokens, colada nas instruções. Sem interpretação, sem 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

Uma skill de revisão. O Make audita o frame atual com base na tabela de tokens e devolve uma lista de aprovação ou reprovação, destacando em hexadecimal e pixels os valores que causaram o problema.

---
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

A skill de dados de exemplo insere textos provisórios já aprovados pelo cliente. Assim, os builds de revisão deixam de chegar com lorem ipsum ou nomes de empresas inventados pelo modelo que mais tarde chamam a atenção do jurídico. (Resumo das notas de versão de maio 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.

Três arquivos. Cada um substitui algo que eu costumava colar de novo.

Como conectar o Notion para a skill ler o design system atualizado

A estratégia de tokens estáticos em /follow-ds-guidelines funciona para um sistema congelado. Assim que o cliente atualiza um token — e isso vai acontecer — a tabela embutida fica defasada. A solução é combinar a skill com um conector para que o Make consulte a fonte atualizada. (Conectores no Figma Make, ajuda do Figma)

No arquivo usado por esse cliente, o padrão é o seguinte: o design system fica em uma única página do Notion, com os mesmos títulos da skill (Color, Spacing, Type ramp, Radius, Button). Eu aciono a skill e o conector no mesmo 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.

O mesmo prompt pode buscar um PRD no Drive no mesmo formato — @Drive "Halcyon pricing PRD" —, e o Make reúne o contexto do design system e da especificação de uma só vez. (Resumo das notas de versão de maio de 2026)

Minha escolha varia por cliente: tokens embutidos para sistemas que não mudam há um trimestre; conector para os que ainda estão evoluindo. O arquivo .md da skill é o mesmo nos dois casos — quem muda é o prompt. É intencional. Em vez de acumular uma skill para cada cliente, prefiro ter uma única skill que sabe aceitar substituições.

Vale diferenciar: a skill /prototype-to-figma do servidor MCP do Figma pertence a outra camada. Ela já vem instalada para o fluxo de ida e volta entre código e canvas, e não é criada por você. As custom skills do Make fazem o inverso: você as escreve, elas vivem dentro do Make e não interagem com a camada MCP.

Onde o processo falhou: não determinismo e custo de compartilhamento

O anúncio deixou três pontos de fora.

A compatibilidade com modelos é mais restrita do que a documentação sugere. No momento, as custom skills funcionam apenas com o modelo padrão do Figma Make e com Claude Opus 4.7. Se a equipe padronizou outro modelo no Make, a skill não é aplicada e não há um erro explícito — as regras simplesmente deixam de ser seguidas. (Custom skills para Figma Make, ajuda do Figma) Em um build de equipe, essa é a primeira coisa que verifico antes de investigar por que o raio voltou a ficar errado.

Os resultados são consistentes “very often”, não idênticos. É assim que a própria documentação do Figma descreve o comportamento. Como o modelo é não determinístico, às vezes /design-crit deixa passar um desvio em um frame complexo ou sinaliza algo que foi intencional. (Custom skills para Figma Make, ajuda do Figma) Para mim, a skill de crítica é uma primeira revisão rápida, não a aprovação final.

O custo de compartilhamento é o problema operacional. Hoje, as custom skills pertencem a cada conta. Para disponibilizar o pacote a outra pessoa da equipe, você exporta os arquivos .md, e ela precisa enviá-los para a própria conta. Não existe publicação no nível da organização. (Custom skills para Figma Make, ajuda do Figma) Para um estúdio que opera vários sistemas de clientes, esse atrito pesa: cada pessoa nova exige uma instalação manual de todas as skills ativas, e cada atualização pede uma nova exportação. A solução é pouco sofisticada, mas funciona: versionar os arquivos .md no repositório do cliente — mantemos os nossos ao lado dos tokens de design, no mesmo monorepo —, criar tags para os releases e transformar o upload em um processo com uma única fonte confiável, não em uma mensagem perdida no Slack.

Esse custo por licença aparece em outras plataformas usadas por designers. Escrevi sobre a matemática dos planos premium do Webflow pela mesma razão: as ferramentas cobram pela superfície; o custo real vem do atrito de integração por baixo dela.

Figma Make e design system: o que vira skill e o que continua humano

Depois de algumas semanas trabalhando assim na DVNC.studio, cheguei a uma regra: tudo que precisei redigitar mais de duas vezes vira uma skill. Tabelas de tokens, checklists de revisão, convenções para dados de exemplo e a estrutura padrão das anotações de acessibilidade. Nada disso é criativo. Tudo isso era custo operacional.

O que continua humano é a decisão. /design-crit sinaliza um valor fora do sistema, mas não determina se aquilo é um erro ou uma exceção deliberada para uma peça isolada de marketing. A skill lida bem com “este raio é 12; o esperado é 8”. Ela não sabe interpretar “este raio é 12 porque o conceito da campanha pedia um card mais suave e nós combinamos isso na terça-feira”. Esse julgamento é o trabalho.

Na próxima terça-feira, faça o seguinte: escolha o sistema de cliente que você mais usa. Abra um arquivo .md. Cole a tabela de tokens como fiz com a Halcyon acima. Salve como follow-ds-guidelines.md, envie como custom skill, rode um build real com ela e depois execute /design-crit no resultado, comparando-o manualmente com a tabela de tokens. Se a skill identificar o que você também identificaria, ela eliminou uma hora de novos prompts por cliente, por semana. Se deixar passar algo óbvio, a correção está no arquivo .md, não no histórico de prompts.