Voltar para o Blog
Vibe Coding15 / 40
  1. 01O que é vibe coding (e o que não é)
  2. 02De escrever código a dirigir a intenção
  3. 03O ciclo: contexto → plano → geração → revisão
  4. 04O arsenal: visão geral do nosso stack de IA
  5. 05Quando não usar vibe coding
  6. 06Da ideia ao protótipo em horas
  7. 07Claude para brainstorm de produto e PRD
  8. 08Claude Artifacts para mockups instantâneos
  9. 09Lovable: do prompt ao app funcional
  10. 10Google AI Studio: prototipando com Gemini
  11. 11Lovable × Claude × Google Studio: quando usar cada um
  12. 12Claude Code: o par de programação que conhece o monorepo
  13. 13Anatomia de um bom prompt de engenharia
  14. 14Plan mode: planejar antes de gerar
  15. 15Skills e slash commands (/investigate, /review, /ship)
  16. 16Refactors e migrations em massa
  17. 17Debugging com IA: do stack trace à causa raiz
  18. 18Supabase: a espinha dorsal de dados
  19. 19Modelagem com Drizzle ORM
  20. 20RLS na prática: a regra que não tem exceção
  21. 21Migrations SQL à mão e o drift DB↔Drizzle
  22. 22Auth com Google OAuth no Supabase
  23. 23Realtime, Storage e o resto do Supabase
  24. 24Trigger.dev: o piloto automático
  25. 25Seu primeiro job agendado
  26. 26Workflows com retry e observabilidade
  27. 27IA em background: resumos e narrativas
  28. 28Deploy do Trigger.dev e as pegadinhas
  29. 29Evolution API: WhatsApp como canal de produto
  30. 30Instância por usuário e gestão centralizada
  31. 31IA gerando resumos de conversa
  32. 32Boas práticas e armadilhas no WhatsApp
  33. 33Integrando APIs de terceiros com IA
  34. 34Anthropic SDK: Claude dentro do produto
  35. 35Resend: e-mail transacional que chega
  36. 36Google Analytics, Search Console e Ads
  37. 37Rate limit, retry, idempotência e secrets
  38. 38GitHub: CI/CD e AI Code Review como portão de qualidade
  39. 39Deploy no Google Cloud Run
  40. 40A cultura por trás do vibe coding (e o futuro)
Vibe CodingParte 15 de 40

Skills e slash commands (/investigate, /review, /ship)

2 min de leitura
Compartilhar
Vibe Coding

Pedir tudo "solto" pro Claude Code funciona, mas a gente descobriu algo melhor: fluxos prontos pras tarefas que se repetem. São as skills (slash commands) — e elas embutem o jeito certo de fazer cada coisa, em vez de você reinventar o prompt toda vez.

O que é uma skill

Uma skill é um fluxo nomeado, acionado por /comando, que carrega um procedimento especializado: a sequência de passos, o contexto certo e as boas práticas daquela tarefa. Em vez de "me ajuda a investigar esse bug", você chama /investigate e o fluxo já sabe como conduzir.

As que mais usamos no ClubPetro

  • /investigate — bug, erro 500, "por que isso quebrou". Conduz a investigação de forma estruturada em vez de chutar causa.
  • /review — revisar um diff antes do PR. Olha correção, risco, padrão.
  • /ship — subir/deployar, criar PR. Encadeia os passos de entrega com segurança.

E há outras no nosso fluxo (qa, document-release, design-review, plan-eng-review, checkpoint, health…). A regra de roteamento do nosso CLAUDE.md é clara: quando a tarefa casa com uma skill, invoca a skill primeiro — ela produz resultado melhor que prompt ad-hoc.

Por que isso é melhor que pedir solto

  1. Consistência. Todo mundo investiga bug do mesmo jeito bom, não cada um do seu.
  2. Boas práticas embutidas. A skill já carrega o "como fazer certo" — você não depende de lembrar.
  3. Menos prompt, mais resultado. O fluxo faz o trabalho de estruturar; você foca no problema.
  4. Conhecimento que escala. Melhorou o fluxo? Todo mundo ganha, sem treinar de novo.

Como tirar proveito

  • Aprenda quais skills existem antes de inventar prompt. Metade das tarefas comuns já tem uma.
  • Deixe a skill conduzir. Ela tem um roteiro melhor que o improviso — siga.
  • Combine com plan mode. /investigate que entende o bug → plano de correção → geração → /review.

A ideia maior

Skills transformam vibe coding de "talento individual com prompt" em processo de time. O bom prompt deixa de ser segredo de quem manja e vira ferramenta que todo mundo usa.

⚠️ Armadilha #15: ignorar as skills e reescrever o mesmo prompt manual toda vez. É reinventar a roda — pior, uma roda mais torta que a que o time já lapidou.

Próximo da série: #16 — Refactors e migrations em massa.

Curtiu como a gente pensa?

É assim que trabalhamos todo dia.

Se esse jeito de pensar é o seu, vem construir com a gente — dá uma olhada nas vagas abertas.

Ver vagas