Quatro Skills que Prendem o Claude Code ao Design System

TV
Thiago Victorino
7 min de leitura
Quatro Skills que Prendem o Claude Code ao Design System

Em cinco posts argumentamos que design systems são infraestrutura de governança para IA. Esta semana o argumento ganhou peças operacionais. Dois praticantes publicaram os detalhes que faltavam.

Sen Lin, atualmente Senior Product Designer na Worldline e ex-Lead of Futures Innovation na Thoughtworks, lançou quatro Skills do Claude Code no GitHub. Elas obrigam o agente a ler o mapa de tokens, confirmar o brief, consultar o registro de componentes e amarrar cada propriedade visual a uma variável antes de escrever no Figma. Código aberto. Pronto para usar hoje.

Na mesma semana, Romina Kavcic publicou o enquadramento sistêmico: componentes como contratos, tokens semânticos com metadados useFor e avoidFor, gates de qualidade via axe-core, Chromatic e stylelint já rodando em Microsoft, Shopify e IBM.

O modelo de harness que escrevemos para engenharia agora chega ao design. A pergunta de governança é a mesma: quem aprova o quê, e quando.

As Quatro Skills, Nomeadas

O repositório de Sen Lin em github.com/senlindesign/claude2figma não é um framework. São quatro arquivos Markdown que qualquer time pode adicionar a um projeto Claude Code agora.

Preflight. Antes de o agente desenhar qualquer coisa, ele carrega uma linha de base. Mapa de tokens (cor, espaçamento, tipografia, raio). Registro de componentes. Convenções de nomenclatura. Se algum desses elementos está ausente, o agente recusa prosseguir. A formulação de Lin é precisa: “o que construí não é um harness. Um harness é uma preocupação arquitetural. Vive no nível do sistema. O que construí está mais próximo de uma camada de aplicação de fluxo de trabalho.” Preflight é o portão de entrada dessa camada.

Reference Interpreter. O agente lê o Design Brief e o reescreve com suas próprias palavras antes de executar. É o mesmo padrão que engenheiros sêniores usam em pull requests: reformule o requisito, exponha a ambiguidade, peça confirmação. O modo de falha no design é idêntico. Um agente que interpreta “deixe mais limpo” sem confirmar produzirá seis redesigns da mesma tela. Reference Interpreter força o contrato antes do trabalho.

Component Rules. Busca antes de inventar. Se um botão existe, use o botão. Se uma variante de card cobre o caso, use a variante. A Skill proíbe explicitamente a geração de componentes que já têm registro. É a regra que a integração MCP do Figma viabiliza estruturalmente; a Skill de Lin a torna aplicável dentro do Claude Code mesmo sem MCP.

Style Binding. Cada propriedade visual precisa rastrear a uma variável. Cor referencia o token. Espaçamento referencia a escala. Tipografia referencia o sistema. Lin acrescenta uma passada de QA pós-escrita: a Skill reabre o artefato gerado e verifica se nenhum hex bruto, número mágico ou tamanho de fonte avulso escapou. É a restrição que fecha o ciclo. Sem ela, as três primeiras Skills ainda podem produzir saída que deriva.

As quatro não são sugestões. São sequenciais. Preflight define o perímetro. Reference Interpreter define o alvo. Component Rules restringe a jogada. Style Binding verifica o resultado. Pule uma e a corrente quebra.

O que Kavcic Adiciona: a Camada de Contratos

A peça de Lin descreve o que aplicar. A peça de Kavcic descreve contra o que aplicar.

A tese central dela é que prompts não escalam. Estrutura escala. Um design system feito de componentes, exemplos e explicações em prosa dá ao agente contexto ambiente e torce pelo melhor. Um design system feito de componentes-como-contratos dá ao agente regras executáveis.

Um contrato de componente, na formulação dela, tem cinco campos. Intenção (para que serve). Variantes (que formas assume). Regras (quando usar cada variante). Acessibilidade (o que precisa satisfazer). Anti-padrões (o que nunca pode fazer). O agente lê o contrato e cumpre ou falha o check. Não há interpretação envolvida.

Tokens recebem o mesmo tratamento. Kavcic argumenta contra tokens semânticos genéricos como color-primary e a favor de tokens com tags comportamentais como:

color-action-primary:
  value: "#1A73E8"
  useFor: ["CTA principal", "navegação primária"]
  avoidFor: ["decoração", "fundo"]

O metadado é a restrição. Um agente lendo useFor e avoidFor sabe onde o token cabe e onde não cabe. O token deixa de ser um valor. Vira valor mais política de uso.

Ela cita os gates de qualidade já em produção. O sistema Fluent da Microsoft usa interfaces adaptativas com regras explícitas para conteúdo gerado por IA. O Polaris da Shopify entrega tokens semânticos com metadados comportamentais. O Carbon da IBM roda stylelint em CI para pegar uso não autorizado de variáveis. A Spotify roda agentes de código em background dentro de sistemas amarrados por contrato. A Gartner projeta que 40% das aplicações enterprise embutirão agentes específicos para tarefas até o final de 2026. A infraestrutura não é teórica.

Por que o Par Importa

Lin dá a camada de aplicação. Kavcic dá os contratos contra os quais a camada aplica. Cada peça sozinha está incompleta. Juntas, descrevem um padrão pronto para produção.

Leia assim. As quatro Skills são um fluxo que roda dentro do Claude Code. Os contratos são os artefatos que o fluxo consulta. Preflight carrega o mapa de tokens e o registro de componentes. Reference Interpreter converte o Design Brief em intenção estruturada. Component Rules consulta o contrato pelo componente correspondente. Style Binding verifica a saída contra o metadado dos tokens.

É a mesma forma operacional da engenharia governada. O harness carrega testes, lints e CI antes de o agente escrever código. Skills carregam tokens, contratos e validação antes de o agente escrever design. A disciplina é idêntica. O vocabulário viaja.

O que é novo aqui é o fechamento de uma distância operacional que sinalizamos em peças anteriores. Argumentamos que ferramentas de design estavam ignorando a camada de restrição. Que design systems precisavam evoluir de documentação para infraestrutura. Que o substrato se adapta à era dos agentes. Esses argumentos eram direcionais. Lin e Kavcic os tornam concretos. As quatro Skills existem. O padrão de contratos existe. Empresas estão rodando os dois.

Os Limites Honestos

Três ressalvas antes da adoção.

As Skills de Lin são código aberto e recentes. Foram publicadas, não testadas em batalha em centenas de times de design. Os padrões são sólidos. Os casos de borda ainda não estão documentados. Trate as quatro Skills como um harness inicial, não como um harness acabado.

Os exemplos corporativos de Kavcic são reais, mas seletivos. Shopify, IBM e Microsoft têm escala e disciplina para rodar design systems amarrados por contrato. Um time de produto de 12 pessoas não vai implantar pipelines de stylelint e regressão visual com Chromatic da noite para o dia. A direção do padrão está correta; a escada de maturidade é mais íngreme para times menores.

A questão de governança que o enquadramento de Lin expõe segue aberta. Ele distingue um harness (“uma preocupação arquitetural, no nível do sistema”) da sua camada de aplicação de fluxo. A distinção é útil. Também significa que as quatro Skills não respondem à pergunta maior: quem decide o que os contratos dizem, como eles mudam, quando eles quebram. Isso é papel de governança, não de tooling. O modelo de harness vindo da engenharia carrega a mesma questão pendente, e não resolvemos lá também.

Faça Isso Agora

Se você mantém um design system e seu time usa Claude Code, três passos concretos esta semana.

Um: clone github.com/senlindesign/claude2figma. Leia os quatro arquivos de Skill. São curtos. Investimento total abaixo de uma hora.

Dois: audite seus tokens em busca de metadados comportamentais. Se seus tokens são valores sem campos useFor e avoidFor, você não tem contra o que aplicar. Comece pelos cinco tokens mais mal utilizados. Adicione o metadado. Documente os anti-padrões.

Três: pegue um componente, escreva seu contrato usando os cinco campos de Kavcic, e teste se o agente produz saída compatível quando restrito pelo contrato versus quando guiado por prosa. A diferença é o argumento inteiro a favor de estrutura sobre prompts.

Design systems são infraestrutura de governança. Esta semana a infraestrutura ganhou documentação pronta para produção.


Fontes

A Victorino ajuda times de design e engenharia a operacionalizar autonomia governada no canvas: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa