📐 Skill de design global

Novo aqui? Uma skill (já apresentada na Trilha 3) é um conjunto de instruções gravado num arquivo que o agente consulta sozinho antes de fazer determinado tipo de trabalho — como uma ficha de procedimento que um funcionário pega na gaveta antes de começar uma tarefa que já tem "jeito certo de fazer" na casa. Uma skill de design é esse mesmo mecanismo, especializado em front-end: guarda paleta de cores, tipografia, espaçamento, tom visual e os princípios que definem "bonito" pra você — não pra internet inteira.

Pense numa oficina de arquitetura de verdade: existe uma pasta física (ou um PDF) chamada "manual de identidade visual" — cores exatas em código hexadecimal, fontes aprovadas, margens mínimas, exemplos do que pode e do que não pode. Todo estagiário novo lê aquilo antes do primeiro projeto. Ninguém reexplica cor por cor numa reunião toda vez. A skill de design é exatamente esse manual, só que o "estagiário" é o agente e ele lê o manual sozinho, no início de cada tarefa de front-end — sem você precisar redigitar nada.

"Faz um site bonito" é um pedido vago porque "bonito" não tem definição fixa — cada pessoa do planeta que treinou aquele modelo tem um "bonito" diferente, e o modelo faz a média disso tudo, que é justamente o "cheiro de IA" do módulo anterior. Já um pedido apoiado numa skill de design não precisa dizer "bonito" nenhuma vez: a skill já define, de antemão, o que "bonito" significa pra você — que paleta usar, que tipografia, que espaçamento, que tom (sério? divertido? luxuoso? artesanal?). O agente não inventa mais nada visualmente: ele aplica a regra que já existe.

Legenda: em cima, sem manual nenhum, o pedido vago cai direto na média estatística. Embaixo, o agente tem o hábito de abrir a skill de design ANTES de escrever qualquer front-end — mesmo um pedido curto já sai com a paleta, a tipografia e o tom certos, porque a decisão já estava tomada no manual.

Toda skill (relembrando a Trilha 3) tem uma descrição/gatilho — a frase curta que diz ao agente QUANDO consultar aquele arquivo, sem precisar ler o arquivo inteiro pra decidir isso. Numa skill de design, o gatilho é algo como "use antes de criar, redesenhar ou revisar qualquer página, componente ou interface". Isso é o que faz o agente abrir o manual sozinho, mesmo quando você só pediu "cria um formulário de contato" sem mencionar "design" ou "skill" nenhuma vez.

Depois do gatilho vêm as regras de estilo propriamente ditas: paleta de cores (com os códigos hexadecimais exatos, não "azul" ou "verde" vago), a tipografia (que fontes usar, em que tamanho, pra título e pra texto corrido — tipografia é só o nome técnico pra "a escolha e o estilo das letras"), espaçamento (quanto respiro entre elementos, cantos retos ou arredondados) e o tom visual geral (sério e corporativo? divertido e colorido? minimalista e sofisticado?). Por fim, uma skill boa traz exemplos — trechos de código ou descrições concretas de "isto está certo" e "isto está errado" — porque exemplo concreto guia melhor que regra abstrata.

Novo aqui? "Global vs. projeto" é sobre ONDE a skill fica guardada e QUAIS projetos enxergam ela (assunto aprofundado no módulo 3.5, mas central aqui de novo). Uma skill de projeto mora dentro da pasta daquele projeto específico e só vale ali. Uma skill global fica instalada uma vez, num lugar do seu computador que todo projeto Claude Code enxerga automaticamente — funciona pra qualquer pasta que você abrir, sem precisar copiar o arquivo de novo pra cada projeto novo.

A diferença prática é enorme. Sem skill global, toda vez que você abre um projeto novo — o site da padaria, o dashboard da consultoria, a landing page do curso — você reexplica do zero: "usa essa cor, essa fonte, esse espaçamento". Isso é cansativo, é fácil esquecer um detalhe, e o resultado varia de projeto pra projeto mesmo quando você queria o MESMO estilo em todos. Com a skill instalada globalmente, você grava o manual uma única vez, e todo projeto novo — mesmo daqui a seis meses, mesmo um que você nem imagina hoje — já nasce puxando aquela mesma referência.

A disciplina que separa uma skill útil de uma skill esquecida é uma frase só: sempre invocar a skill de design ANTES de escrever qualquer front-end, nunca depois. Se você deixa o agente escrever o componente primeiro e "revisar com a skill" depois, ele já gastou esforço construindo em cima do palpite genérico — é retrabalho. O hábito certo é: pedido de front-end chega → skill abre primeiro → só então o código é escrito já dentro da referência certa.

Objetivo: testar, no seu próprio ambiente, se uma skill de design instalada globalmente muda o resultado de um pedido simples de componente — sem você precisar mencionar cor, fonte ou estilo nenhuma vez no pedido, porque isso já deve vir da skill.

Antes de escrever qualquer HTML ou CSS, verifique se existe uma skill de design instalada
e a use como referência de estilo. Agora crie um cartão de produto para 
com título, preço e um botão de comprar. Não me pergunte cor nem fonte — decida pela skill.

Se você já tem uma skill de design instalada globalmente, o resultado deve sair com a paleta e a tipografia dela, sem "Get Started" azul genérico. Se ainda não tem nenhuma skill instalada, o agente provavelmente vai avisar que não achou skill nenhuma — o que já confirma a lição: sem manual pra consultar, ele volta pro palpite. (Como instalar a sua própria skill de design é passo a passo dos módulos 5.6 e 5.7, com a pasta de marca completa.)

A skill de design ataca a causa 1 do módulo 5.1 — falta de referência — mas não ataca a causa 2: ninguém força o agente a de fato OLHAR o resultado antes de te entregar. Uma skill bem escrita reduz muito o "cheiro de IA" porque o agente já parte de boas escolhas, mas ela não substitui um olho crítico sobre o resultado final — o CSS pode estar tecnicamente certo e mesmo assim sair desalinhado, apertado ou com contraste ruim numa tela real. É exatamente essa segunda metade que o próximo módulo resolve.