Como usar uma skill do Claude para revisar uma tela pronta em vez de gerar outra?

Fala aí, beleza? A Anthropic tem uma skill de design que quase ninguém usa, e não é a de gerar tela: é a que senta do outro lado da mesa e critica o que você já fez

O reflexo padrão quando a interface sai esquisita é pedir outra pro Claude

Aí vem tela nova, com outro layout, outro espaçamento, e o problema original continua ali, só que escondido embaixo de uma casca diferente

Existem duas skills oficiais nesse território e elas fazem coisas opostas: a design-critique, que vive no repositório anthropics/knowledge-work-plugins, e a frontend-design, que vive no anthropics/skills

A maioria só conhece a segunda

Neste post tu vai ver como instalar o plugin de design, como disparar a crítica, como ler o relatório que ela devolve e, principalmente, o critério pra saber qual das duas entra em cada momento 🙂

O que você precisa antes de começar

A lista é curta, e é bom conferir antes pra não travar no meio:

• Claude Code instalado com acesso à CLI de plugins, aquela que responde pelo comando claude plugin
• O material da tela que vai ser criticada: a skill aceita link do Figma, captura de tela ou descrição escrita, e é isso que está documentado como entrada dela
• Um jeito de produzir a captura, se o que tu quer revisar é app rodando

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Sobre esse último ponto: existe a skill oficial webapp-testing, que usa Playwright pra interagir com aplicações web locais, tirar screenshots e ler logs do navegador

Ela resolve a parte chata de gerar o material, e a design-critique fica com a parte de opinar

Tome cuidado com uma expectativa comum aqui: as entradas documentadas da design-critique são Figma, screenshot e descrição

Então o fluxo mental não é "aponta pro meu componente e lê o código", é "mostra a tela e escuta a crítica"

Como instalar e rodar a skill design-critique passo a passo

1. Adicione o marketplace de plugins da Anthropic

claude plugin marketplace add anthropics/knowledge-work-plugins

Esse repositório é descrito pela própria Anthropic como um repositório aberto de plugins voltado principalmente a knowledge workers no Claude Cowork

O erro comum deste passo: pular ele

Sem marketplace adicionado, o instalador não sabe de onde tirar o pacote e o passo seguinte falha sem motivo aparente

2. Instale o plugin de design

claude plugin install design@knowledge-work-plugins

Se tu prefere navegar em vez de decorar identificador, o Claude Code tem o comando interativo /plugin, que abre o gerenciador de plugins pra você olhar e instalar dali mesmo

O erro comum deste passo: instalar achando que veio só a crítica

O plugin design é completão, ele traz um pacote: design-critique, design-system, ux-copy, design-handoff, accessibility-review e research-synthesis

3. Entregue a entrada certa

Link do Figma, screenshot ou descrição escrita da tela

Quanto mais contexto de uso tu der junto (quem usa, o que a pessoa precisa fazer ali, em que momento), menos genérica a devolutiva volta

O erro comum deste passo: mandar um print cortado, só do bloco que te incomoda

Hierarquia visual e consistência são coisas que só aparecem quando a tela está inteira na frente

4. Dispare com uma frase de gatilho

A design-critique responde a linguagem natural, com frases do tipo review this design, critique this mockup ou what do you think of this screen?

O erro comum deste passo: procurar um slash command bonitinho pra chamar ela

O gatilho é a frase, não o comando

Se tu ficar caçando barra, vai jurar que a instalação deu errado quando ela está funcionando perfeitamente

5. Leia o relatório por eixo

A saída é um feedback estruturado em markdown, organizado em usabilidade, hierarquia visual, consistência e acessibilidade

E tem uma coisa que muda como você lê isso: a base teórica declarada da skill são as 10 heurísticas de usabilidade do Nielsen Norman Group e as Laws of UX

Ou seja, não é chute estético, é um checklist antigo e conhecido sendo aplicado na sua tela

O erro comum deste passo: tratar o relatório como lista de tarefas e sair aplicando tudo

Crítica é insumo, a decisão continua sua

O que eu vi usando skills nos meus projetos com Claude Code

No vídeo abaixo eu mostro as skills que entraram no meu fluxo de verdade, e uma parte dessa história explica exatamente por que revisão importa tanto quanto geração

O plano de implementação que eu gerei rodou por quase 10 minutos na minha máquina e fechou 14 tarefas

O app ficou de pé, funcionando

Aí eu abri no navegador e o veredito foi duro: interface genérica, sem identidade, aquele resultado padrão de projeto sem alma

E olha o detalhe, isso não é falha de execução, as 14 tarefas foram concluídas

É que "funcionar" e "estar bom" são duas avaliações diferentes, e só a segunda depende de alguém olhar pra tela pronta

O que eu fiz não foi refazer o app

Foi aplicar uma skill de front end por cima da tela que já existia, com o projeto rodando

E o prompt que eu usei não descrevia componente nenhum, descrevia sensação: visual clean e moderno que passasse confiança financeira, modo escuro, e o usuário sentindo que tem controle das finanças sem sobrecarga

Isso conecta com a reclamação que eu mais vejo por aí

Quando a IA não entrega o layout esperado, na maioria das vezes o pedido estava raso

Não é bala de prata, o resultado depende MUITO do prompt

No fim, o Claude devolveu um resumo do que mudou: modo escuro, tipografia, cor de acento, cards, barra de navegação, animações

Esse resumo eu trato como algo pra conferir, nunca pra aceitar de olhos fechados

A validação foi voltar no navegador e comparar antes e depois, olhando tipografia e consistência entre os elementos, que é praticamente o mesmo trabalho que uma crítica estruturada faz por escrito

Ah, e antes de chegar na parte visual eu ainda peguei erro real de cadastro e login na primeira execução

Copiei a mensagem, mandei o Claude analisar e corrigir, seguimos

Isso é normal no primeiro prompt, não é sinal de que o projeto nasceu torto

Como criar sua própria skill de revisão de tela

Skill pronta é ótima pra começar, mas ela não conhece as regras do teu time

Eu gosto de criar skills próprias de auditoria justamente por isso, e com uma exigência: a verificação tem que ser mecânica

Rodar comandos reais, contar quantos problemas apareceram e devolver uma nota de 0 a 100

Nota sem contagem por trás é achismo com cara de relatório

A estrutura é simples:

1. Crie o diretório da skill com um SKILL.md dentro

Uma skill no Claude Code é um diretório com um arquivo SKILL.md que tem frontmatter YAML mais as instruções em markdown

mkdir -p ~/.claude/skills/revisao-de-tela

2. Escreva o frontmatter e as instruções

---
name: revisao-de-tela
description: Revisa telas prontas do projeto apontando inconsistencia de espacamento, hierarquia e estados. Use quando pedirem revisao, critica ou auditoria de uma interface que ja existe.
---

## Como revisar

1. Liste os problemas por eixo: espacamento, hierarquia, estados
2. Conte quantos problemas foram encontrados
3. Devolva uma nota de 0 a 100 com a conta explicada

3. Escolha o escopo: pessoal ou de projeto

Skills pessoais ficam em ~/.claude/skills/<nome>/SKILL.md e valem pra todos os teus projetos

Skills de projeto ficam no próprio repositório, e é assim que a regra viaja junto com o código quando outra pessoa clona

4. Capriche no description, porque ele é o gatilho

O campo description do frontmatter é o que o Claude lê pra decidir se carrega a skill

O erro comum deste passo: escrever algo tipo "skill de design"

Description genérica é skill que nunca carrega, e tu vai passar a tarde achando que o arquivo está no lugar errado

Se tu quer ir mais fundo nessa parte de estrutura e migração, eu já detalhei o processo de criar e usar skills no Claude Code num post separado

design-critique x frontend-design: revisar ou gerar?

As duas são oficiais, as duas mexem com interface, e elas não competem: elas entram em momentos diferentes do projeto

A leitura rápida da tabela: se tu ainda não tem tela, é frontend-design

Se tu já tem tela e ela te incomoda, é design-critique

Quando chamar cada skill: crítica, acessibilidade ou design system

O plugin design tem mais gente dentro dele, e escolher errado é o que faz o retorno vir raso

Se liga no mapa:

• Espaçamento inconsistente, hierarquia confusa, estados mal resolvidos numa tela pronta: design-critique, que é justamente a que olha usabilidade, hierarquia visual, consistência e acessibilidade em cima do que já está desenhado
• Conformidade de acessibilidade pra valer: accessibility-review, que aceita um design ou uma URL e devolve relatório de conformidade WCAG 2.1 AA com os problemas, a severidade de cada um e os passos de correção
• Biblioteca de componentes virando bagunça: design-system, que revisa a component library quanto a consistência, completude e convenções de nomenclatura, com recomendações específicas

O plugin ainda traz ux-copy, design-handoff e research-synthesis, que cobrem texto de interface, entrega pro dev e síntese de pesquisa

Do lado da comunidade existe a skill design-review, mantida no repositório jezweb/claude-skills, focada em auditoria de UI e revisão de PR em código frontend

Deixando claro: essa não é da Anthropic, é comunidade

O que não muda é que quanto mais skill tu acumula, mais vale ter um critério pra revisar e aposentar skills paradas, senão a pasta vira um cemitério de arquivo que nunca carrega

Próximo passo

A ideia central do post é essa: gerar tela nova esconde o problema, revisar expõe

Quando tu pede outra interface, o Claude te dá um resultado diferente e tu nunca fica sabendo o que estava errado no anterior

Quando tu pede crítica, vem uma lista com nome e endereço de cada coisa

O próximo passo concreto é curto: adiciona o marketplace, instala o plugin design e roda a design-critique na tela mais antiga do teu projeto, aquela que tu já nem olha direito de tão acostumado

Se o retorno virar rotina, aí sim vale transformar as regras do teu time numa skill própria em ~/.claude/skills, com contagem e nota, do jeito que eu gosto 😀

faça o teste e me conta o que a crítica achou da tua tela

até o próximo post!