🖼️ Interfaces: o agente que enxerga

"Novo aqui? Front-end é a parte visual de um site ou app — os botões, cores, textos e layout que aparecem na tela. O oposto é o back-end, que roda escondido no servidor." O agente escreve os dois, mas o front-end é o que o cliente/usuário julga primeiro.

Sem esse termo claro, o resto da trilha ("skill de design", "screenshot") não faz sentido — front-end é o alvo de tudo que vem a seguir.

Front-end, back-end, o que o usuário vê vs. o que roda por trás.

O agente aprendeu vendo milhões de páginas na internet. Sem uma direção específica, ele reproduz o padrão mais frequente — que tende à média, não ao excepcional.

Entender a causa evita frustração: não é "o agente é ruim em design", é "ele precisa de direção, igual um estagiário novo".

Regressão à média, ausência de direção, "cara de IA" como sintoma.

Cinza claro em cinza escuro, sombras genéricas, cantos arredondados demais, ícone de foguete/estrela em tudo, gradiente roxo-azul — a "assinatura visual" que qualquer pessoa reconhece de longe como feita por IA sem curadoria.

Saber reconhecer o sintoma ajuda você a pedir correção específica em vez de "deixa mais bonito" (que não ajuda o agente a decidir nada).

Padrões reconhecíveis, feedback específico vs. vago.

Por padrão o agente lê e escreve texto (código); ele não abre a página no navegador para "olhar" o resultado, a não ser que você — ou uma ferramenta extra — peça isso explicitamente.

É essa lacuna que os módulos 5.2 e 5.3 fecham: dar ao agente instrução de gosto (skill de design) e visão (laço de screenshot).

Escrever código às cegas, feedback visual ausente por padrão.

Sem nada, o resultado fica em algo como 40% do caminho até "parece profissional". Com skill de design + laço de screenshot, sobe para perto de 60%. Os 40% finais exigem gosto humano — não são um bug a corrigir, são o seu trabalho.

Expectativa realista evita duas armadilhas: desistir cedo ("não dá pra fazer bonito") ou confiar demais ("o agente resolve sozinho").

Ganho parcial automatizável, limite estrutural, papel do julgamento humano.

Skill de design → laço de screenshot → limites do laço → referência visual/rebranding → pasta de marca → build de landing page publicada → regras de publicação.

Ver o caminho inteiro ajuda a entender por que cada módulo existe antes de chegar nele.

Progressão: instruir o gosto, dar visão, testar limites, aplicar marca, publicar com regras.

Uma skill é um arquivo de instruções que o agente carrega quando o pedido combina com ela (visto na Trilha 3). Uma skill de design guarda suas preferências visuais para todo projeto de front-end.

Sem isso, você reescreve "use cores sóbrias, tipografia limpa" toda conversa nova — a skill elimina essa repetição.

Skill, reuso entre projetos, memória de preferência.

Paleta de cores preferida, fontes aprovadas, regras de espaçamento ("nunca cole elementos sem respiro"), tom visual (sóbrio, divertido, corporativo) e o que evitar (gradiente roxo-azul, ícone de foguete).

Quanto mais concreta a instrução, menos o agente cai de volta na média genérica do módulo 5.1.

Paleta, tipografia, espaçamento, lista de "não fazer".

Uma skill de design "global" fica numa pasta que vale para todos os seus projetos; uma "de projeto" fica só dentro daquele repositório específico (tema visto a fundo na Trilha 3.5).

Seu gosto pessoal (tipografia que você gosta, por exemplo) é global; a marca de um cliente específico é por projeto.

Escopo global, escopo de projeto, quando usar cada um.

Objetivo: gerar o arquivo de skill com suas preferências de design. Bloco copiável: "Crie uma skill global chamada 'meu-design' com estas preferências: paleta <suas cores>, fonte <sua fonte>, tom <sóbrio/divertido>. Evite gradiente genérico e ícones de foguete." Como verificar: peça ao agente para listar o conteúdo do arquivo de skill criado e confira se bate com o que você pediu.

É o exemplo prático que fecha a teoria dos tópicos anteriores num resultado que você usa hoje mesmo.

Prompt de criação de skill, verificação do arquivo gerado.

Cada vez que você corrige algo que saiu errado, vale voltar na skill e adicionar essa regra — "nunca use essa cor de fundo com esse texto", por exemplo.

A skill vira melhor projeto a projeto; sem esse hábito você repete o mesmo erro sempre.

Iteração, aprendizado acumulado, edição incremental.

A skill dá instrução de gosto, mas o agente ainda escreve às cegas — não vê o resultado. Falta o passo de verificação visual, tema do próximo módulo.

Entender essa lacuna evita achar que só a skill resolve tudo — ela é metade da solução.

Instrução vs. verificação, as duas metades da solução.

Um servidor local é um programinha que exibe a página só dentro do seu computador (endereço tipo localhost) — como um ensaio antes de publicar de verdade para o mundo.

É o primeiro passo do laço: sem subir esse servidor, não existe página para fotografar.

Servidor local, localhost, ambiente de ensaio.

Um screenshot é uma foto da tela naquele instante. Com a ferramenta certa (um navegador automatizado), o próprio agente tira essa foto da página que acabou de construir.

É essa foto que transforma "escrever código às cegas" (módulo 5.1) em "ver o resultado antes de te entregar".

Screenshot, navegador automatizado, feedback visual.

O agente compara o screenshot contra um "alvo": pode ser a skill de design (módulo 5.2), uma imagem de referência (módulo 5.5) ou uma checklist descritiva ("texto legível, botões alinhados, espaço entre seções").

Sem um alvo claro, "comparar" vira opinião vaga — o alvo é o que torna a correção objetiva.

Alvo de comparação, critério objetivo, checklist visual.

Depois de corrigir, o agente sobe o servidor de novo, tira outro screenshot, compara de novo — repetindo até bater o critério ou esgotar um número razoável de tentativas.

Essa repetição é o que diferencia um resultado "primeira tentativa, sem revisão" de um resultado "verificado antes de te entregar".

Iteração, ciclo fecha-testa-corrige, limite de tentativas.

Objetivo: fazer o agente construir e verificar visualmente uma página sozinho. Bloco copiável: "Crie uma landing page para <seu produto>. Suba um servidor local, tire um screenshot, compare com a skill de design e corrija até ficar consistente antes de me mostrar." Como verificar: peça para o agente te enviar (ou descrever) o screenshot final e confira se bate com o pedido.

É o momento em que a teoria dos módulos 5.1/5.2 vira ação — o laço rodando de ponta a ponta.

Prompt do laço completo, verificação do resultado entregue.

Skill (gosto) + laço (visão) juntos fecham erros grosseiros: texto cortado, botão fora do lugar, contraste ruim — mas não decidem sozinhos "isso é bonito" de verdade.

Prepara para o módulo 5.4, que detalha exatamente o que o laço não resolve.

Erros grosseiros vs. julgamento fino, ganho automatizável.

Texto cortado da caixa, elementos sobrepostos, botão sem espaço para clicar, contraste de cor que dificulta leitura — coisas que dá para checar de forma objetiva na imagem.

Saber a força do laço evita descartá-lo — ele resolve, sim, uma fatia grande e chata de erros.

Erro objetivo, checável por regra, quebra estrutural.

"Essa cor combina com a marca?", "esse espaçamento parece elegante ou vazio?", "esse texto soa confiável?" — perguntas de gosto que dependem de contexto, público e sensibilidade humana.

É exatamente essa fatia que sobra para você — os "40% finais" citados no módulo 5.1, aqui explicados de fato.

Julgamento subjetivo, contexto de marca, sensibilidade humana.

Sem um alvo claro (módulo 5.3), o agente pode entrar num ciclo tentando agradar um critério vago e nunca parar — por isso vale sempre combinar um número máximo de tentativas.

Evita gastar tempo/custo à toa num laço que nunca converge.

Loop sem critério de parada, limite de tentativas, custo.

Uma página pode ficar boa no tamanho de tela testado e quebrar em celular ou tela grande — o laço só verifica o que foi de fato fotografado.

Leva a pedir explicitamente screenshots em mais de um tamanho quando o resultado importa de verdade.

Responsividade, múltiplos tamanhos de tela, cobertura de teste.

Mesmo depois do laço rodar e "aprovar" o próprio resultado, o veredito de "está bom para publicar" continua sendo seu — o agente reduz o trabalho, não substitui a decisão final.

Fecha a régua honesta da trilha: automação ajuda, mas não tira a responsabilidade de olhar o resultado você mesmo antes de publicar (ligação direta com o módulo 5.8).

Aprovação humana final, automação como redução de esforço, não substituição de julgamento.

Uma forma de reduzir a subjetividade do módulo 5.4 é mostrar, e não descrever, o que você quer — dando uma imagem de referência ao agente.

É o gancho para o próximo módulo, que ensina exatamente essa técnica.

Mostrar vs. descrever, imagem de referência.

"Estilo minimalista e elegante" significa coisas diferentes para pessoas diferentes; uma imagem de referência remove essa ambiguidade de uma vez.

É a forma mais rápida de reduzir a distância entre o que você imagina e o que o agente entrega.

Ambiguidade da linguagem, referência visual como âncora.

A maioria dos agentes de código aceita imagem anexada na conversa ou o caminho de um arquivo PNG/JPG salvo no projeto — o agente "lê" a imagem junto do texto do pedido.

Sem saber o mecanismo, a técnica de "mostrar" fica só teoria.

Anexar imagem, caminho de arquivo, leitura multimodal.

Sites de galeria de design, um concorrente que você admira, ou até um print do seu próprio material antigo — qualquer imagem real que capture o estilo desejado.

Ter um repertório de referências prontas acelera qualquer pedido de design futuro.

Repertório de referências, curadoria pessoal.

"Rebranding" é atualizar a identidade visual de algo já existente — mesma referência visual funciona aqui: mostre a nova direção e peça para aplicar em cima do que já está pronto.

Você raramente começa do zero — na maioria das vezes está atualizando algo que já existe.

Rebranding, atualização sobre base existente.

Objetivo: guiar o resultado com uma imagem em vez de só palavras. Bloco copiável: "Anexei uma imagem de referência (<caminho da imagem>). Recrie o layout dessa referência para <seu conteúdo>, mantendo a mesma sensação visual — cores, espaçamento e tom." Como verificar: compare lado a lado o screenshot final com a referência anexada.

É a aplicação direta da técnica "mostrar em vez de descrever" com um resultado checável.

Prompt com anexo, comparação lado a lado.

Referência de estilo ("essa vibe visual") é diferente de copiar conteúdo, logo ou identidade de outra marca — pedir para inspirar-se é diferente de pedir para clonar.

Protege você de um problema legal e ético antes de publicar qualquer coisa.

Inspiração vs. cópia, identidade de terceiros.

Uma pasta dentro do projeto (ou global) com os arquivos de logo, a paleta de cores exata e as fontes usadas — a fonte única de verdade da sua identidade visual.

Sem ela, cada projeto novo reinventa (errado) o logo ou a cor da marca de memória.

Fonte única de verdade, ativos de marca, consistência.

Guardar o código exato da cor (tipo #0d9488) em vez de "aquele verde-azulado" — o agente usa o valor certo sem adivinhar.

Cor "quase certa" quebra a consistência da marca de forma sutil mas visível para quem conhece.

Código hexadecimal de cor, precisão vs. aproximação.

Nome exato da fonte (e onde baixá-la), mais as versões do logo (com fundo claro, escuro, só o ícone) prontas para usar sem precisar recriar.

Evita o agente "inventar" uma fonte parecida ou distorcer o logo tentando recriá-lo do zero.

Nome exato da fonte, variações de logo prontas.

A skill de design (módulo 5.2) pode apontar diretamente para a pasta de marca — assim, gosto pessoal (skill) e identidade específica de um cliente (pasta) trabalham juntos sem conflito.

Fecha a arquitetura: skill global dá o "como fazer", pasta de marca dá o "com o quê".

Skill referenciando pasta, separação gosto/identidade.

Objetivo: organizar seus ativos de marca num único lugar consultável. Bloco copiável: "Crie a pasta 'marca/' com um arquivo marca.md listando: cor primária <hex>, cor secundária <hex>, fonte principal <nome>, e onde estão os arquivos do logo." Como verificar: abra o arquivo gerado e confira se todos os valores batem com os seus.

Transforma a teoria dos tópicos anteriores numa pasta que você usa no próximo módulo de build.

Arquivo marca.md, checagem de valores.

Com skill de design, laço de screenshot, referência visual e pasta de marca prontos, você tem tudo para construir e publicar uma landing page de verdade.

Marca a transição da teoria para o projeto prático que fecha a trilha.

Ferramentas prontas, transição para o build.

"Landing page" é uma página única de apresentação (para um produto, serviço ou projeto pessoal): seções típicas são cabeçalho, o que é, como funciona e uma chamada para ação.

Definir o escopo antes de pedir evita ida e volta — o agente sabe exatamente o tamanho do projeto.

Landing page, seções típicas, escopo definido.

Antes de pedir o build, confira: a skill de design (5.2) está ativa, a pasta de marca (5.6) está pronta, e você tem (opcionalmente) uma referência visual (5.5) à mão.

Juntar os insumos antes evita pedir o build "pela metade" e ter que corrigir depois.

Checklist de insumos, preparo antes do pedido.

Objetivo: construir a landing page inteira num único pedido bem formado. Bloco copiável: "Usando a pasta 'marca/' e a skill de design, crie uma landing page para <seu produto/projeto> com seções: topo, o que é, como funciona, chamada para ação. Suba servidor local, tire screenshot, compare com a skill e corrija antes de me mostrar." Como verificar: veja o screenshot final e confira as 4 seções presentes e a marca aplicada.

É o exercício que junta tudo que a trilha ensinou até aqui num resultado tangível.

Pedido completo, verificação por checklist de seções.

Depois que o agente aprova o próprio laço, é sua vez: olhe o resultado com atenção, peça ajustes de gosto específicos (não "melhora", mas "essa cor de fundo está pesada demais").

É a aplicação prática do limite explicado no módulo 5.4 — o julgamento fino é seu.

Feedback específico, revisão humana final.

Deploy é o processo de tirar a página do "ensaio" no servidor local e colocá-la no ar, com um endereço acessível por qualquer pessoa — tema aprofundado na Trilha 4.

A landing page só cumpre a função dela quando alguém de fora consegue acessá-la.

Deploy, endereço público, ligação com a Trilha 4.

O build está pronto quando: no ar, sem erro visual grosseiro, com a marca aplicada e você — não o agente — assinando embaixo que está bom.

Sem um critério de parada, o perfeccionismo trava o projeto — e o módulo 5.8 detalha as regras antes de publicar de fato.

Critério de conclusão, evitar perfeccionismo paralisante.

Mesmo que você consiga apagar uma página depois, alguém já pode ter visto, salvo ou compartilhado — publicar é, na prática, uma ação de mão única.

Justifica por que essa trilha termina com regras explícitas em vez de deixar por conta do bom senso.

Ação de mão única, cautela antes do irreversível.

A mesma técnica da Trilha 0.4: escrever "nada vai ao ar sem minha aprovação explícita" no CLAUDE.md do projeto para o agente ler sempre, em toda sessão nova.

Uma regra falada uma vez se perde; uma regra escrita é lida em toda conversa nova.

Regra persistente, CLAUDE.md, aprovação explícita.

Antes de aprovar: revisar o screenshot final, checar ortografia e links, confirmar que nenhum dado pessoal/sensível aparece por engano, e testar em pelo menos um tamanho de tela diferente.

Uma checklist objetiva evita aprovar no "olhômetro" apressado.

Checklist de revisão, dados sensíveis, múltiplos tamanhos.

Confirmar que nenhuma senha, chave de API ou informação privada ficou visível no código da página publicada (tema de "Segredos", Trilha 4.4).

Página bonita com um segredo vazado é pior do que página feia sem vazamento — a checagem de segurança vem antes da estética.

Vazamento de segredo, prioridade sobre estética, ligação com Trilha 4.

Objetivo: fixar a regra de aprovação de forma permanente no projeto. Bloco copiável: "Adicione ao CLAUDE.md a seção: 'Publicação — nunca fazer deploy ou publicar qualquer página sem antes me mostrar o resultado e receber minha aprovação explícita.'" Como verificar: abra o CLAUDE.md e confirme que a seção foi adicionada, palavra por palavra.

É o exercício final que trava, de forma permanente, a regra mais importante da trilha.

Regra permanente no arquivo, verificação literal do texto.

Com interface visual construída, verificada e publicada com regras claras, a Trilha 6 muda o eixo: de "o que o agente constrói" para "quando o agente trabalha sozinho, sem você pedir".

Fecha a trilha com clareza do próximo passo — agendamento e loops.

Transição de trilha, de "construir" para "agendar".