Como criar um plugin no Figma usando Claude Code (sem saber JavaScript)

Como criar plugins do Figma sem saber programar, usando Claude Code para resolver problemas reais de Design Systems

Vou contar uma coisa que talvez te surpreenda: semana passada eu criei um plugin pro Figma. Do zero. Em uma tarde. E eu não sou dev.

Não estou falando de arrastar blocos no-code. Estou falando de um plugin real, que roda no Figma Desktop, que o time inteiro pode usar, e que resolve um problema que me incomodava há meses: verificar se os componentes de uma tela estão usando os tokens certos do nosso Design System.

O segredo? Claude Code.

O problema que me levou até aqui

Se você trabalha com Design System (em qualquer empresa grande), sabe que a adoção nunca é 100%. Sempre tem alguém usando cor hardcoded, tipografia fora da escala, espaçamento “no olho”. E a gente, como designer que cuida do sistema, descobre isso tarde, geralmente no code review, quando já virou código.

Eu queria algo que avisasse antes. Direto no Figma. Tipo um linter, mas para design.

Procurei plugins na Community. Achei coisas genéricas. Nenhum entendia nossos tokens, nossas convenções, nosso contexto. E aí pensei: e se eu criar o meu?

A barreira que não existe mais

Antes de IA, a jornada seria mais ou menos assim:

• – Aprender JavaScript, uma jornada de aprendizado longa – cerca de algumas semanas;

• – Estudar a Figma Plugin API, algo que levaria alguns dias;

• – Configurar TypeScript, webpack, build tools, horas de frustração em relação à todas as etapas necessárias;

• – Escrever o código, jornada de mais algumas semanas;

• – Debugar, tarefa movida a muito café e longas horas;

Eu desisti dessa jornada pelo menos três vezes nos últimos dois anos. Com Claude Code, a jornada virou outra:

• – Descrever o que eu quero em português;

• – Claude Code gera a estrutura completa;

• – Testar no Figma Desktop Iterar com o Claude: “ajusta isso, muda aquilo” (quantas vezes quiser);

• – Publicar – etapa final quando estiver satisfeito;

A diferença não é só de velocidade. É de quem pode fazer e estrutura o problema e algumas partes – além de ir executando pouco a pouco de forma organizada e em etapas.

Anatomia de um plugin do Figma

Antes de entrar no processo, vale entender o que compõe um plugin. É simples:

meu-plugin/
manifest.json → identidade e permissões
code.ts → lógica principal (TypeScript)
ui.html → interface do plugin (opcional)
package.json → dependências
tsconfig.json → configuração do TypeScript

O manifest.json é tipo o RG do plugin, diz o nome, o que ele pode fazer, e quais arquivos usar. O code.ts é onde mora a lógica. O ui.html é a interface que aparece pro usuário quando ele abre o plugin.

A API do Figma dá acesso a praticamente tudo: layers, propriedades, cores, textos, componentes, variáveis. Tudo que você vê no painel de propriedades, o plugin consegue ler e modificar.

O processo: do prompt ao plugin

Vou mostrar como fiz passo a passo. Não precisa segui-lo exatamente, o principal objetivo é mostrar o método e a estruturação do problema dividida em partes para a execução:

Passo 1: Começar o projeto

Aqui você tem dois caminhos, escolhe o que fizer mais sentido pra você:

Caminho A: Começar pelo Figma (mais visual)

Abre o Figma Desktop, vai em Plugins → Development → New Plugin, escolhe um template (recomendo “Custom UI” pra ter interface) e o Figma gera a pasta com todos os arquivos iniciais. Depois é só abrir essa pasta no VS Code com Claude Code e começar a iterar de lá. Esse caminho é bom porque o Figma já cria o manifest.json com um ID válido e a estrutura certinha, você não precisa se preocupar com configuração.

Caminho B: Começar pelo Claude Code (mais direto)

Abre o Claude Code no terminal e descreve o que quer:

“Cria um plugin pro Figma que verifica se as cores, tipografias e espaçamentos de uma tela estão usando tokens do Design System.

O plugin deve:
– Escanear todos os nodes da página atual;
– Verificar se as cores são tokens válidos;
– Verificar se os tamanhos de fonte seguem a escala tipográfica;
– Verificar se os espaçamentos são múltiplos de 4;
– Mostrar os erros numa lista lateral com nome do layer e o problema;
– Ao clicar num erro, selecionar o node no canvas.”

Isso. Em português, descrevendo o comportamento que eu queria como designer.

Nos dois caminhos, o ponto de chegada é o mesmo: uma pasta com os arquivos do plugin aberta no Claude Code, pronta para iterar.

Passo 2: Claude Code gera tudo

Em menos de 2 minutos, o Claude gerou:

• – O manifest.json configurado;

• – O code.ts com toda a lógica de validação;

• – O ui.html com a lista de erros e interação de clique;

• – O tsconfig.json e package.json corretos.

Não precisei escrever uma linha de JavaScript. Algo que acelerou processos, por exemplo, jornada de aprendizagem da stack e conteúdos de programação.

Passo 3: Testar no Figma

Abri o Figma Desktop, fui em Plugins → Development → Import plugin from manifest, selecionei o manifest.json que o Claude gerou, e rodei.

Na primeira tentativa já funcionou parcialmente. A verificação de cores rodou, mas os erros não estavam mostrando o nome correto dos layers.

Passo 4: Iterar

Voltei pro Claude Code e escrevi:

“Os nomes dos layers estão aparecendo como ‘undefined’. Ajusta pra mostrar o node.name de cada layer com erro.”

Dois segundos depois, corrigido. Testei de novo. Funcionou.

Fiz mais umas cinco iterações: ajustei as cores da UI, adicionei um filtro por tipo de erro, mudei o layout da lista. Cada iteração levou menos de um minuto.

Passo 5: Personalizar com contexto do DS

A parte mais legal foi quando eu passei os tokens reais do IFDS – o Ifood Design System pro Claude:

“Aqui estão os tokens de cor do nosso DS (exemplo):
– surface-primary: #FFFFFF
– surface-secondary: #F5F5F5
– text-default: #1A1A2E
– action-primary: #EA1D2C
[…]
Atualiza a validação pra usar esses tokens como referência.”

Em vez de um linter genérico, agora eu tinha um linter que entende o nosso Design System. Que sabe que #EA1D2C é action-primary e que #EA1D2D (um caractere de diferença) é um erro.

Um trecho do código gerado

Pra quem tem curiosidade, aqui vai um pedaço da função que verifica cores:

function checkColors(node: SceneNode) {
if (‘fills’ in node && Array.isArray(node.fills)) {
for (const fill of node.fills) {
if (fill.type === ‘SOLID’) {
const hex = rgbToHex(fill.color);
if (!isValidToken(hex, colorTokens)) {
errors.push({
nodeId: node.id,
nodeName: node.name,
issue: ‘Cor fora do DS’,
found: hex,
suggestion: findClosestToken(hex, colorTokens)
});
}
}
}
}
}

Eu não escrevi isso. Mas eu entendo o que faz. E o mais importante: eu consigo explicar para o meu time o que cada parte faz, porque o Claude gera código limpo e comentado, e também posso perguntar o que aquilo quer dizer a qualquer momento.

O ponto não é “designer virando dev”. É designer resolvendo seu próprio problema com a ferramenta certa.

Ideias de plugins que qualquer designer pode criar

Se você está pensando “legal, mas o que EU criaria?”, aqui vão algumas ideias que me ocorreram durante o processo:

• – Design Lint: valida cores, fontes e spacing contra os tokens do DS (o que eu fiz);

• – Auto Namer: renomeia layers automaticamente seguindo a convenção do time. Acabou o “Frame 247”;

• – Token Sync: importa tokens de um arquivo JSON e cria variáveis no Figma automaticamente;

• – A11y Checker: verifica contraste de cores e tamanho mínimo de fonte. WCAG no Figma;

• – Spec Export: gera um documento de specs em Markdown a partir da seleção. Handoff sem Notion;

• – Icon Inserter: busca e insere ícones do DS direto no canvas, sem precisar abrir a biblioteca.

Cada um desses dá pra criar em uma tarde com Claude Code. E cada um resolve um problema real que a gente enfrenta todo dia.

Aplicações avançadas: quando a criatividade encontra a IA

Plugins não precisam ser só utilitários simples. Com IA, as possibilidades se expandem:

• – Plugin + API externa: conecta o Figma a qualquer serviço. Puxa dados reais de uma API, popula mockups com conteúdo de verdade.

• – Plugin + IA generativa: gera variações de copy, sugere paletas de cor baseadas em referências, cria conteúdo contextual;

• – Plugin + Design Tokens: sincronização bidirecional entre tokens no código e variáveis no Figma. O DS sempre atualizado;

• – Plugin + Analytics: mede quais componentes do DS estão sendo mais usados, identifica padrões de adoção;

• – Plugin + Figma MCP: agentes que editam o design por você. O Figma como canvas programável.

O que eu aprendi no processo

Algumas coisas que me surpreenderam:

1 – A API do Figma é mais acessível do que parece. O modelo mental é simples: tudo é um node numa árvore. Cores, textos, posições, tudo é propriedade de um node. Se você entende layers no Figma, entende a API.

2 – Claude Code erra, mas erra rápido. Na primeira tentativa o código nem sempre funciona perfeitamente. Mas o ciclo de feedback é tão rápido que isso não importa. Descreve o erro, o Claude corrige, testa de novo. Três minutos.

3 – O maior valor não é o código, é a autonomia. Eu não preciso mais abrir uma issue, esperar um dev ter tempo, explicar o contexto, revisar, pedir ajustes. Eu resolvo no momento em que o problema aparece.

4 – Plugins são impacto visível. Distribuir um plugin pro time mostra que você entende o problema profundamente, tão profundamente que construiu a solução. E quando o time inteiro começa a usar algo que você criou numa tarde, o valor fica óbvio sem precisar de apresentação.

Pra quem quer começar

Se você nunca usou Claude Code, o caminho mais simples:

• – Instala o Claude Code (como uma extensão do VS Code, Cursor ou um CLI no terminal);

• – Abre um projeto vazio;

• – Descreve o plugin que quer criar, em português;

• – Testa no Figma Desktop;

• – Itera até ficar bom.

Não precisa aprender JavaScript antes. Não precisa de curso de TypeScript. Não precisa de bootcamp. Você precisa de um problema real e da disposição de descrever ele bem.

O Figma vira o que você quiser. E a barreira de entrada desapareceu.