Me peguei digitando o mesmo prompt de 200 palavras pela quarta vez em uma semana. "Escreva uma mensagem de commit convencional para as mudanças em stage, mantendo a primeira linha abaixo de 72 caracteres, referencie o issue se houver um número de branch..." Toda. Maldita. Vez. Esse é o momento em que você deve parar e construir um comando de barra. Vamos configurar os comandos de barra e as skills do Claude Code e nunca mais redigitar isso.
Ambas as funcionalidades fazem a mesma coisa básica — empacotar instruções para reutilizá-las — mas são feitas para trabalhos diferentes. Comandos de barra são para coisas que você aciona. Skills são para coisas que Claude aciona quando uma tarefa as exige. Entenda essa distinção e o resto é fácil.
Comandos de barra: seus atalhos
Um comando de barra é um prompt salvo que você dispara com /nome. Você cria um colocando um arquivo markdown em .claude/commands/ no seu projeto. O nome do arquivo vira o comando.
Vamos matar esse prompt de mensagem de commit de vez. Crie .claude/commands/commit.md:
Escreva uma mensagem de commit convencional para as mudanças atualmente em stage.
Regras:
- Primeira linha com menos de 72 caracteres, modo imperativo ("Add", não "Added").
- Prefixo de tipo: feat, fix, refactor, docs, test ou chore.
- Se o nome do branch contiver um número de issue, referencie-o no corpo.
- Me mostre a mensagem. Não execute git commit você mesmo.
Primeiro execute `git diff --staged` para ver o que mudou.
Agora em qualquer sessão digito /commit e o Claude faz tudo. Quatro caracteres em vez de duzentas palavras. O arquivo é o comando — o que estiver nele é enviado como meu prompt quando o invoco.
Passando argumentos
Os comandos ficam mais úteis quando aceitam entrada. Use $ARGUMENTS como marcador de posição. Aqui está .claude/commands/explain.md:
Explique como $ARGUMENTS funciona nesta base de código.
Encontre onde está definido, rastreie como é usado e me dê um
resumo curto em linguagem simples. Use um subagente para fazer a busca
para não encher nossa conversa com dumps de arquivos.
Então /explain o fluxo de autenticação coloca "o fluxo de autenticação" naquele lugar. Um comando, usos infinitos. Tenho uma dúzia desses agora — /test, /review, /changelog — e eles silenciosamente removeram a maior parte do trabalho repetitivo do meu dia.
Skills: instruções que Claude aciona por conta própria
Comandos de barra são ótimos quando você sabe o que quer. Mas às vezes você quer que Claude aplique conhecimento especializado automaticamente, no meio de uma tarefa, sem que você precise se lembrar de invocar nada. Isso é uma skill.
Uma skill é uma pasta com um arquivo SKILL.md. O topo desse arquivo descreve quando a skill se aplica. Claude mantém essa descrição em mente, e quando uma tarefa bate, ele carrega as instruções completas por conta própria. Você não digita um comando. Simplesmente acontece.
Digamos que sua equipe tenha uma forma rigorosa de escrever migrações de banco de dados. Crie .claude/skills/migrations/SKILL.md:
---
name: migrations
description: Como escrever migrações de banco de dados neste projeto.
Usar sempre que criar, editar ou revisar um arquivo de migração.
---
As migrações ficam em db/migrations, nomeadas com um prefixo de timestamp UTC.
Cada migração deve:
- Ser reversível — incluir tanto up quanto down.
- Nunca remover uma coluna na mesma migração que para de escrever nela.
Divida em dois deploys.
- Envolver mudanças de schema em uma transação.
Antes de escrever uma, leia as três migrações mais recentes para igualar o estilo.
Agora quando peço ao Claude para "adicionar uma migração para a nova coluna archived_at", ele percebe que a tarefa bate com a descrição da skill, carrega essas regras e as segue — sem eu pronunciar a palavra "skill". Essa é a mágica. O conhecimento aparece exatamente quando é relevante e fica de lado o restante do tempo.
Qual devo construir?
Aqui está a regra simples que uso.
Construa um comando de barra quando você decide quando executá-lo. Mensagens de commit, gerar um changelog, iniciar uma revisão específica — são ações deliberadas. Você as invoca.
Construa uma skill quando Claude deve decidir. Convenções de código, regras de domínio, padrões de formatação — qualquer coisa que deva se aplicar automaticamente sempre que uma tarefa correspondente aparecer. Você não quer ter que se lembrar de digitar /migrations toda vez que tocar no banco de dados. Você quer que as regras simplesmente estejam lá.
Uma boa heurística: se a frase começa com "sempre que Claude fizer X, ele deveria..." — é uma skill. Se começa com "às vezes eu quero..." — é um comando.
A descrição é a parte estrutural
Para skills especialmente, a linha description é tudo. É assim que Claude decide se a skill se aplica. Descrição vaga, skill nunca dispara. Seja concreto sobre o gatilho: "Usar sempre que criar, editar ou revisar um arquivo de migração" diz ao Claude exatamente quando ativá-la. "Coisas de banco de dados" não funciona.
É a mesma energia de uma boa descrição de ferramenta, honestamente. Você está escrevendo para um agente que precisa decidir, no momento, se aquilo é relevante. Dê a ele um sim ou não claro.
Comece pelo que mais te incomoda
Não sente para construir vinte de uma vez. Você vai adivinhar errado o que realmente precisa. Em vez disso, espere até sentir o atrito — aquela quarta redigitação, aquela regra que você fica reexplicando — e construa aquela. Naquele momento. Leva dois minutos e o retorno é imediato.
Toda minha coleção cresceu assim, um incômodo de cada vez. O comando de commit veio de redigitar prompts de commit. A skill de migrações veio de cometer o mesmo erro de migração duas vezes. Cada um resolveu uma irritação real e específica que eu podia apontar.
Então aqui está seu dever de casa. Na próxima vez que se pegar digitando um prompt que já digitou antes, pare. Abra .claude/commands/, crie um arquivo, cole o prompt. Você acabou de recuperar cada cópia futura daqueles dois minutos. Faça isso dez vezes e sua configuração do Claude Code vai parar de parecer genérica e começar a parecer sua.