Install
plan, review against the brief, build, critiquePara quem serve
Use frontend-design quando faz uma interface nova, ou altera uma existente, e precisa de uma direção visual consciente e reconhecível. Ajuda a fixar uma direção estética, tipografias e escolhas que não pareçam valores padrão de um modelo.
Encaixa melhor tratar esta tarefa como o responsável de design de um estúdio: o cliente já recusou propostas ocas ou com ar de modelo e está disposto a pagar por um ponto de vista claro. Deve tomar decisões com posição sobre cor, tipografia e layout deste brief e pode assumir risco estético quando as razões sustentam. O material de origem não dá lista de produtos de agentes nem instalador; não o leia como função exclusiva de um software. A página oficial de descrição é
https://raw.githubusercontent.com/anthropics/skills/main/skills/frontend-design/SKILL.md
Concluir a primeira tentativa em 3 minutos
Este guia não dá um comando de instalação. Na primeira tentativa, não invente um caminho de repositório nem uma instrução de gestor de pacotes. O caminho recomendado é o processo do material de origem: primeiro plan, depois conferir com o brief, então build e por fim critique.
Pré-requisito: já tem uma tarefa de interface, mesmo que o brief seja curto. O primeiro gesto de baixo risco é só o posicionamento — não alterar código nem escrever ficheiros. Se o brief não esclarece o produto ou o tema, defina primeiro um tema concreto, um público e a tarefa principal deste design, escreva como proposta e confirme com quem pediu o trabalho. Antes da confirmação, não entre em cor nem em escrever a interface.
Sinal de sucesso: em três frases consegue dizer para quem é, o que resolve e qual é o tema, e só altera depois de a outra pessoa acenar ou se opor com clareza. Não comece por um fundo creme quente próximo de #F4F1EA, depois títulos serif de alto contraste e toques terracota — o material de origem lista isso como traço dos rascunhos gerados que agora se acumulam.
Casos de uso
Caso 1: se o brief não tem informação de produto, alinhe primeiro e depois desenhe. Segundo o material de origem, proponha primeiro um tema concreto, um público e uma tarefa principal, como proposta a confirmar. O critério de concluído é que esses três pontos estão confirmados, não que já existe uma UI completa. Não diz que ferramenta usar para confirmar; oral ou escrito serve. Desenhar a interface sem confirmar sai deste caminho.
Caso 2: decidir tipografia para um brief já alinhado. O material de origem diz: títulos e corpo não precisam cada um de uma fonte totalmente diferente; uma família, ou duas claramente distintas. Escolher de propósito. Não pegar «a fonte padrão de qualquer projeto». O resumo também menciona manter o comprimento de linha dentro de 80 caracteres, mas o excerto não descreve um procedimento de verificação. O critério de concluído deste caso é que o número de famílias e a diferença já estão decididos, não que uma verificação de composição já correu. Cor e layout ainda têm de ser deste brief; não reutilize o emparelhamento comum de fundo creme mais acento terracota.
Limites de uso
O processo é plan, confronto com o brief, build e depois critique. Primeiro tema, público e tarefa principal; depois o visual. Uma família tipográfica ou duas; recusar fontes padrão universais. Evitar o acúmulo que o material de origem nomeia: fundo creme quente (próximo de #F4F1EA), títulos serif de alto contraste, acentos terracota ou argila quente.
Não invente um instalador nem um caminho dentro do repositório. O material de origem não dá lista de bibliotecas de componentes, ficheiro de amostra de cor padrão nem lista de clientes. Antes de escrever código ou sobrepor estilos existentes, confirme que a proposta foi aceite. Além deste posicionamento, tipografia e armadilhas já escritos, este guia não cobre. Se só aplica um modelo pronto sem escolher para este brief, não deve seguir este caminho. Alinhe primeiro o brief e depois assuma um risco estético justificado.