Como criar uma skill de design para dashboards no Claude Code: regras de gráficos, tabelas e densidade

Dashboard bonito que não responde pergunta nenhuma é o pior tipo de tela

Fala aí, beleza? Skill de design virou o jeito padrão de tirar a cara de template dos projetos com Claude Code, só que tem um detalhe: dashboard não é landing page

Numa landing page o que manda é identidade visual, respiro, tipografia com personalidade

Numa tela de dado o que manda é leitura: o gráfico certo pra pergunta certa, cor que significa alguma coisa, tabela que cabe na cabeça de quem lê e um plano pra quando vierem dez mil registros

Aqui eu mostro como escrever uma skill de design para dashboards no Claude Code, com as regras de tipo de gráfico, de cor, de tabela e de volume de registros dentro de um arquivo que o Claude abre sozinho quando o pedido cheira a painel

Por que uma skill genérica de UI falha em dashboard

O sintoma

Você pede o painel, roda a skill de design e o resultado volta lindo

Tipografia caprichada, paleta autoral, cards alinhados, animação suave

Aí você olha o gráfico e ele não responde pergunta nenhuma: pizza com nove fatias pra comparar valores, linha do tempo sem série de comparação, número gigante sem contexto

E a tabela? Vira parede: vinte colunas, tudo com o mesmo peso visual, zero hierarquia entre o que é chave e o que é detalhe

Bonito e ilegível ao mesmo tempo, o combo perfeito pra reunião travar

A causa

A skill oficial frontend-design vive no repositório público de skills da Anthropic, na pasta skills/frontend-design, e também é distribuída como plugin no repositório oficial de plugins, em plugins/frontend-design

O escopo dela é amplo de propósito: ela é acionada quando você pede componentes web, páginas, artifacts ou aplicações, incluindo sites, landing pages, dashboards, componentes React e layouts HTML/CSS

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 15min

Conhecer formação

E o foco declarado dela é direção estética: tipografia e paleta, escolhas deliberadas de identidade visual pro resultado não parecer template, com instrução explícita de assumir um risco estético justificável

Ela inclusive nomeia três visuais recorrentes de IA como defaults a evitar: o fundo creme perto de #F4F1EA com display serifada e acento terracota, o fundo quase preto com um único acento acid green ou vermilion, e o layout estilo jornal com fios finos, border-radius zero e colunas densas

Sacou o problema? Isso é excelente pro visual não sair genérico, mas nenhuma dessas regras decide se o seu indicador de churn deve ser barra ou linha

A solução

A saída é uma skill específica que codifique leitura de dado, e o gancho pra isso está na própria frontend-design: o princípio de que estrutura é informação

Recursos estruturais (numeração, eyebrows, divisores, rótulos) precisam codificar algo verdadeiro sobre o conteúdo, não decorar

Num dashboard esse princípio vira lei: cor é categoria ou é status, ordem de coluna é prioridade de leitura, agrupamento é hierarquia real do dado

Como prevenir a colisão

O erro que mata é escrever uma description larga demais na sua skill nova

Se você descrever "design de interfaces web modernas", ela vai brigar pelo mesmo pedido que a genérica e disparar na hora errada

Description estreita, focada em dado, é o que mantém cada uma no seu quadrado

O que você precisa antes de criar a skill

O básico é curto: Claude Code instalado e uma decisão de onde a skill vai morar

No Claude Code, skills podem viver em quatro locais: enterprise (managed settings), pessoal, de projeto e diretórios de plugin

Os dois que interessam aqui:

• Pessoal: ~/.claude/skills/<nome-da-skill>/SKILL.md, vale pra todos os seus projetos naquela máquina
• Projeto: .claude/skills/<nome-da-skill>/SKILL.md, vale pro repositório e vai junto no commit

Tem uma pegadinha importante aqui: skill que existe só em ~/.claude/skills/ da sua máquina não é encontrada em sessão remota

Pra sessão remota enxergar, a skill precisa estar commitada em .claude/skills/ do repositório ou vir num plugin declarado no .claude/settings.json

Outro detalhe do modo projeto: as skills são carregadas a partir de .claude/skills/ do diretório onde o Claude Code foi iniciado e de cada diretório pai até a raiz do repositório

Se você subiu o Claude Code dentro de apps/web, a skill na raiz continua sendo encontrada 😀

Decidir entre global e por repositório é uma discussão que rende sozinha, e eu já destrinchei o caso da skill de design entre projetos por lá

Regras do frontmatter que você não pode furar

Uma Agent Skill é uma pasta contendo um SKILL.md com frontmatter YAML e instruções em markdown, mais arquivos opcionais (scripts, templates, referências)

Dois campos são obrigatórios: name e description

Os limites:

• name: no máximo 64 caracteres, só letras minúsculas, números e hífens, sem tags XML e sem as palavras reservadas anthropic e claude
• description: no máximo 1024 caracteres e não pode ser vazia

E as propriedades permitidas no frontmatter são seis: allowed-tools, compatibility, description, license, metadata e name

Inventou campo fora dessa lista? Tome cuidado, você está escrevendo comentário decorativo, não configuração

Passo a passo: criando a skill de design para dashboards

1. Criar a pasta e o SKILL.md

Começa pelo esqueleto, dentro do projeto:

mkdir -p .claude/skills/dashboard-design
touch .claude/skills/dashboard-design/SKILL.md

O nome da pasta e o name do frontmatter andam juntos, então já escolha algo curto e minúsculo

O erro comum deste passo: criar skills/dashboard-design/ solto na raiz do projeto

O Claude Code procura em .claude/skills/, com o ponto na frente, e pasta fora desse caminho simplesmente não existe pra ele

2. Escrever a description como gatilho

A description não é documentação bonitinha: é o texto que o Claude compara com o pedido do usuário pra decidir se aciona a skill

---
name: dashboard-design
description: Regras de design para telas de dado. Define escolha de tipo de grafico, uso de cor com significado, densidade de tabela e comportamento com muitos registros. Use quando o pedido envolver dashboard, painel administrativo, tela de metricas, relatorio, tabela de dados ou grafico.
---

Repare no padrão: primeiro o que a skill faz, depois quando usar, com as palavras que o usuário realmente digita

O erro comum deste passo: description larga demais

Se você escrever "melhora o design de interfaces", ela rouba pedido de landing page e você acaba aplicando regra de tabela numa página de vendas

3. Regras de escolha de tipo de gráfico

Agora o corpo do markdown, e ele deve ser decisório, não poético

## Escolha do tipo de grafico

Decida pela pergunta que a tela responde, nunca pelo que fica bonito:

- Comparar categorias entre si: barra, ordenada pelo valor
- Evolucao no tempo: linha, com o eixo temporal continuo
- Composicao de um total: barra empilhada ou stacked area
- Relacao entre duas medidas: dispersao
- Valor unico com meta: numero grande + variacao, sem grafico

Regras duras:
- Pizza so com poucas fatias e quando a soma faz sentido como 100%
- Nunca use dois eixos Y com escalas diferentes no mesmo grafico
- Todo grafico precisa de titulo que seja a pergunta respondida

O erro comum deste passo: escrever "use gráficos adequados ao contexto"

Isso não é regra, é desejo, e a IA vai continuar chutando pizza

4. Regras de cor com significado

Cor em dashboard tem duas funções: identificar categoria e sinalizar estado

Quando ela vira decoração, o leitor perde o mapa

E aqui dá pra ancorar em critério objetivo, o WCAG 1.4.11, de contraste não textual

O critério exige contraste mínimo de 3:1 entre as partes do gráfico necessárias pra entender o conteúdo e as cores adjacentes

Na orientação do W3C, gráficos muito finos têm exigência maior, de 4,5:1, enquanto formas mais espessas ou sólidas ficam na régua de 3:1

O próprio W3C usa gráfico como exemplo: num gráfico de pizza, os objetos gráficos são as fatias e é preciso distinguir uma da outra; num gráfico de linhas em fundo claro, cada linha precisa de 3:1 contra o fundo

E tem a exceção que salva muito layout: gráfico com texto embutido ou sobreposto transmitindo a mesma informação, tipo rótulo e valor no próprio gráfico, dispensa a exigência de contraste da forma

## Cor

- Cor sempre codifica algo: categoria, status ou serie. Nunca decora
- Status usa uma escala fixa e unica em todo o produto
- Objetos graficos solidos (fatias, barras): minimo 3:1 contra cores adjacentes
- Tracos finos (linhas, sparklines): minimo 4,5:1
- Se o valor estiver rotulado dentro do proprio grafico, o requisito de
  contraste da forma nao se aplica: use isso a favor da paleta
- Nunca use so a cor para diferenciar series: adicione rotulo, forma ou padrao

O erro comum deste passo: escolher a paleta primeiro e checar contraste depois

Aí o acento lindo do modo escuro some no fundo e você refaz tudo

5. Regras de tabela: densidade e muitos registros

Densidade não tem número oficial pra copiar, então trate como critério de projeto, escrito e decidido por você

O importante é a skill ter uma resposta pronta pras três perguntas que sempre voltam: o que aparece por padrão, o que é detalhe sob demanda e o que acontece quando o volume cresce

## Tabelas

- Defina colunas primarias (sempre visiveis) e secundarias (sob demanda)
- Numero alinhado a direita, texto a esquerda, cabecalho na mesma regra
- Uma unica fonte numerica tabular, casas decimais consistentes por coluna
- Zebra ou divisor: escolha um dos dois, nunca os dois juntos
- Acao por linha fica no fim da linha, com rotulo acessivel

## Muitos registros

- Nunca renderize a base inteira: defina a estrategia (paginacao ou carregamento
  incremental) e mantenha a mesma em todas as telas do projeto
- Estado vazio, estado de carregamento e estado de erro sao obrigatorios
- Ordenacao e filtro precisam sobreviver ao recarregar a pagina
- Contagem total sempre visivel junto do recorte aplicado

O erro comum deste passo: deixar a estratégia de volume em aberto

Aí cada tela nasce com um comportamento diferente e o produto fica com três tabelas que se comportam de três jeitos

6. Manter o corpo enxuto e quebrar o excedente

Skills usam progressive disclosure: nomes e descrições ficam pré-carregados no contexto do agente, cerca de 200 tokens no total, e o conteúdo completo dos arquivos só é lido quando o agente decide abrir

Por isso a recomendação oficial de autoria é manter o corpo do SKILL.md abaixo de 500 linhas e dividir o excedente em arquivos separados, que ficam no sistema de arquivos sem consumir contexto até serem acessados

.claude/skills/dashboard-design/
  SKILL.md
  references/tabelas.md
  references/paleta-e-contraste.md

O erro comum deste passo: jogar o guia de design inteiro dentro do SKILL.md

Fica pesado e, pior, a regra que importa se perde no meio do resto

7. Preferir script pro que é determinístico

A documentação de boas práticas recomenda preferir scripts pra operações determinísticas em vez de pedir ao Claude que gere o código a cada execução

Checar contraste de uma paleta, contar colunas, validar se toda tabela tem estado vazio: isso é conta, não criatividade

Escreve o script uma vez, referencia ele no SKILL.md e pronto, o resultado para de variar a cada rodada

O erro comum deste passo: pedir pro modelo "verificar" e aceitar a resposta em prosa

Verificação sem comando rodado é opinião com cara de relatório

8. Testar na sessão atual

A parte boa: o Claude Code detecta mudanças no texto do SKILL.md e aplica na sessão atual, sem reiniciar

Então o ciclo é curto: edita a regra, pede uma tela, olha o resultado, ajusta a regra de novo

Só lembre que alterações em outros componentes de plugin (hooks/, .mcp.json, agents/, output-styles/) exigem /reload-plugins ou reinício

O erro comum deste passo: testar só com o pedido perfeito

Teste também com o pedido torto ("faz uma tela de relatório") pra ver se a description dispara mesmo

Se você está na dúvida entre colocar essas regras num arquivo de skill ou direto no contexto do projeto, eu comparei skill ou CLAUDE.md pras regras de design num post separado

O que aprendi usando skills em todos os meus projetos

No vídeo abaixo eu levanto um app de controle de despesas, com dashboard de resumo mensal e gráfico de gastos por categoria

O resultado inicial saiu com aquela interface padrão, genérica, sem identidade nenhuma

Eu chamo isso de AI slop: é o sintoma de projeto sem alma, e eu prefiro corrigir com skill de front end a instalar pacote de terceiro

Antes disso, aliás, passei por erro real no caminho: cadastro de conta redirecionando pra login com erro

Resolvi do jeito mais chato e mais eficiente que existe, colando o erro no Claude Code pra ele analisar e corrigir, e só então acessei o app funcionando

Com o app de pé, ativei uma skill de design de front end e escrevi um prompt que descrevia a intenção do produto, não os componentes: visual clean e moderno que passasse confiança financeira, modo escuro, e a sensação de controle das finanças sem sobrecarregar o usuário

Depois de rodar, o próprio Claude Code listou o que mudou: modo escuro, tipografia, cor de acento, cards, barra de navegação e animações

Comparando antes e depois, a tipografia mudou bastante, o estilo ficou mais nobre e os elementos ficaram bem mais consistentes entre si

Mas não é bala de prata, e eu falo isso lá: pode ocorrer ou não, depende bastante do prompt

Na minha visão, boa parte da reclamação de "a IA não entrega o layout que eu quero" é prompt ruim, não ferramenta ruim

No mesmo vídeo eu mostro o outro lado, que é criar skill própria dentro do projeto (skill de projeto, não global) descrevendo as regras que eu quero que sejam checadas

E fiz questão de que a verificação fosse mecânica: rodar comandos reais, contar problemas encontrados e imprimir nota total, breakdown por categoria e a lista de problemas

É exatamente o que a regra de dashboard pede… nota e lista de problemas não discutem, prosa discute

A razão de eu defender skill sob medida é simples: tecnologia e regra variam de projeto pra projeto, mesmo quando existe skill pronta boa disponível

Quando usar a skill de dashboard (e quando a genérica basta)

Nem toda tela precisa dessa skill, e forçar ela em tudo é o caminho pra brigar com a genérica

E se você prefere partir de algo pronto antes de escrever a sua, o caminho de plugins é curto

Rodar /plugin sem argumentos abre a interface de descoberta e instalação, com escopos de usuário, de projeto ou local

A instalação segue o padrão /plugin install <nome-do-plugin>@<nome-do-marketplace>, e o marketplace oficial claude-plugins-official é registrado automaticamente na primeira vez que o Claude Code roda de forma interativa

O marketplace da comunidade é adicionado manualmente:

/plugin marketplace add anthropics/claude-plugins-community

Ele hospeda plugins de terceiros que passaram pela validação automatizada e pela triagem de segurança da Anthropic

Conclusão

Uma skill de design para dashboards não vale pela tela que ela arruma hoje

Ela vale pelo que decide por você em toda tela nova: o tipo de gráfico que responde a pergunta, a cor que significa alguma coisa, a tabela que ainda é legível no registro dez mil

O próximo passo é commitar a pasta em .claude/skills/ do repositório, assim o time inteiro e a sessão remota enxergam a mesma regra que você

E se a skill estiver disparando na hora errada, ou nem disparando, existe a skill oficial skill-creator, no anthropics/skills e também como plugin no claude-plugins-official, voltada a criar skills, melhorá-las e rodar avaliações, incluindo otimizar a description pra acionar melhor

Escreve a regra uma vez, deixa ela versionada, e para de repetir prompt 😀

até o próximo post!