Pular para o conteúdo
PTEN

Claude Code na prática: skills e plugins que uso

Como uso skills e plugins do Claude Code em projetos reais: o que é uma skill, a que monta sites de clientes, design, code review e testes no navegador.

Eu construo apps, sites e sistemas com Claude Code e Codex. O que faz o Claude Code render no dia a dia não é o prompt que digito na hora: são as skills e os plugins que ficam instalados e entram sozinhos quando a tarefa pede. Aqui mostro quais Claude Code skills e Claude Code plugins eu uso, como escrevo as minhas e o que aprendi errando.

O que é uma skill do Claude Code

Uma skill é um pacote de instruções que o Claude carrega quando a tarefa combina com ela. Na prática é uma pasta com um SKILL.md e, se precisar, scripts, modelos e arquivos de referência. O arquivo começa com um cabeçalho de duas linhas que importam: o nome e a descrição.

A descrição é o que decide se a skill entra ou não. O Claude lê as descrições de todas as skills instaladas e só abre o resto do arquivo quando a sua tarefa se parece com o que está descrito. Por isso o corpo pode ser longo e detalhado sem gastar contexto em toda conversa.

Um plugin é um nível acima: empacota várias skills, comandos e às vezes servidores MCP, e você liga ou desliga tudo de uma vez nas configurações.

A skill que mais uso: o pipeline de sites de clientes

A skill mais útil que tenho é uma que eu mesmo escrevi, site-cliente. Ela leva o site de um pequeno negócio do Instagram e do Google Meu Negócio do cliente até o deploy. É o processo por trás dos sites de clientes da DockPlus.

O cabeçalho dela, encurtado:

---
name: site-cliente
description: Pipeline completo para criar o site-prévia de cotação
  de um cliente da DockPlus a partir do Instagram e do Google Meu
  Negócio dele. Cobre pesquisa, identidade visual, brandbook, site
  estático, repositório GitHub e deploy. Use sempre que alguém da
  equipe pedir para fazer um site, uma cotação ou uma proposta de
  site para um cliente [...] mesmo que ele cite só uma parte
  ("pega as fotos do insta dela", "faz o brandbook").
---

O corpo divide o trabalho em quatro fases: pesquisa, brandbook, site e deploy. Ao fim de cada fase o Claude para e espera minha aprovação. Ninguém publica um site que eu não revisei.

Algumas regras que estão escritas nela:

  • Sites diferentes entre si. Cada cliente novo precisa diferir dos dois anteriores em pelo menos 5 de 9 eixos de layout. Trocar só cor e fonte não conta. Um arquivo de referência registra o estilo de cada cliente já feito.
  • Contraste calculado, não estimado. Um script calcula o contraste WCAG do CSS e acusa falha abaixo de 4,5:1.
  • Prévia fora do Google. Toda prévia sai com noindex e robots.txt bloqueando tudo. Só a produção é indexada.
  • Deploy em um comando. Um script cria o projeto na Cloudflare Pages ligado ao GitHub, cadastra o domínio e aponta o DNS. Depois a skill manda conferir que um endereço inventado responde 404, porque sem uma 404.html real a Pages responde 200 para qualquer caminho.

O mesmo pipeline gerou 30 prévias de proposta, e a equipe da DockPlus usa a mesma skill. A pasta também tem um arquivo de interface para o Codex, então o processo não fica preso a uma ferramenta.

Skills de design e motion

Para interface, uso um grupo de skills de design: frontend-design, impeccable, design-taste-frontend, high-end-visual-design e motion-design, além do plugin ui-ux-pro-max. Elas existem para tirar o modelo das escolhas padrão: a mesma fonte, o mesmo gradiente, o mesmo card com sombra. Cada uma traz regras de tipografia, espaçamento e animação que o Claude segue quando a tarefa é visual.

Também uso uma skill chamada anti-slop, que procura padrões genéricos de texto, código e design gerados por IA. Ela é útil na revisão, quando o resultado está correto mas sem cara.

Plugins para processo e revisão de código

Os plugins que deixo ligados:

  • superpowers: skills de processo. Brainstorm antes de construir, escrita de plano, TDD, depuração sistemática, pedido de revisão de código e uma checagem antes de dizer que terminou. É o plugin que mais muda o comportamento do Claude em tarefas longas.
  • ponytail: um modo que empurra o Claude para a menor solução que funciona. Reusar o que já existe no código antes de escrever algo novo, sem abstração que ninguém pediu. Traz também comandos de revisão nessa linha.
  • vercel e stripe: skills com a documentação e as boas práticas de cada plataforma, que entram quando o código toca nelas.

Para revisão uso também o /code-review do próprio Claude Code, que lê o diff atual e aponta bugs de correção.

Verificação no navegador

Código que compila não é site que funciona. Por isso o Claude tem acesso ao navegador: o Chrome DevTools via MCP, o Playwright e o Claude in Chrome. Com eles ele abre a página, tira print em desktop e mobile, lê o console e roda Lighthouse.

Na skill de sites isso é obrigatório: revisar no Chrome antes de mostrar o brandbook, conferir desktop e mobile e corrigir overflow. Tenho ainda uma skill, google-consoles, que abre o Search Console e o Bing Webmaster na conta de trabalho certa para enviar sitemaps e ler relatórios de indexação.

Um exemplo: este portfólio

Este site também foi feito com Claude Code. O CLAUDE.md na raiz do repositório descreve os comandos, a arquitetura e onde ficam os dados, e o Claude lê isso no início de cada sessão. O histórico mostra o que foi construído em cima disso: a marca Cobre & Petróleo, a versão em inglês indexável em /en com sitemap e hreflang, e a exportação estática para a Cloudflare Pages.

A exportação estática é um bom exemplo de decisão pequena que fica registrada no código. O next.config.ts lê uma variável:

// STATIC_EXPORT=1 gera HTML estático em out/ para o Cloudflare Pages;
// sem ela, o build continua em modo standalone para o Docker/Dokploy.
const staticExport = process.env.STATIC_EXPORT === "1";

const nextConfig: NextConfig = {
  output: staticExport ? "export" : "standalone",
  images: { unoptimized: staticExport },
};

O build roda checagem de tipos e lint, e há testes com Jest e Testing Library com limite de 60% de cobertura. É isso que me deixa aceitar mudança grande feita pelo agente: se ele quebrar algo, o teste ou o build acusa.

Dicas para escrever suas próprias skills

Mantenha a skill pequena e específica. Uma skill que faz uma coisa bem entra na hora certa. Uma que tenta cobrir tudo entra quando não devia. Detalhe longo vai para arquivos de referência que a skill manda ler só quando precisa, como o imagens.md da site-cliente, que só entra na hora de tratar e recortar fotos.

Escreva a descrição pensando no gatilho. Inclua as frases que as pessoas realmente falam, inclusive pedidos parciais. A descrição da site-cliente cita exemplos como "pega as fotos do insta dela" justamente para um pedido pela metade também acionar a skill.

Ponha regras onde o modelo erra, e transforme em script quando der. "Verifique o contraste" o modelo esquece. Um script que falha abaixo de 4,5:1 não esquece.

Deixe credenciais fora da skill. A site-cliente é um repositório Git que a equipe clona. Tokens ficam em arquivos na pasta de cada cliente, fora do repositório, e a skill manda nunca imprimir chaves.

Verifique a saída. Pare para aprovar entre fases, teste, abra no navegador. A skill acelera o trabalho; ela não substitui olhar o resultado.

Como aprender Claude Code sem curso

Muita gente procura um curso de Claude Code. Não vendo curso, mas posso contar como aprendi: construindo. Escolha uma tarefa que você repete toda semana, faça com o Claude Code uma vez, anote onde ele errou e transforme essas anotações numa skill. Na próxima vez, use a skill e corrija o que ainda falhar. A site-cliente nasceu assim e muda a cada cliente.

O mesmo vale para produto. No LedgerJob, um SaaS para empresas de construção dos EUA, arquitetei o backend, o agente e o servidor MCP com o Claude Code, com testes em Vitest segurando as regras de negócio.

Quer trocar ideia sobre como usar Claude Code no seu time? fale comigo

Todos os artigos