Defina slash commands reutilizáveis como arquivos Markdown, compartilhe-os pela equipe via git e cubra tarefas frequentes como revisão de código, geração de testes e descrições de PR.
O Claude Code vem com alguns slash commands embutidos — /help, /clear, /compact. Mas os que realmente aceleram seu fluxo de trabalho são os que você mesmo escreve.
Este artigo é sobre como projetar um sistema de slash commands reutilizáveis para que toda a equipe compartilhe a mesma biblioteca de prompts, em vez de reescrever descrições de tarefas do zero toda vez.
No Claude Code, um slash command personalizado é simplesmente um arquivo Markdown. Coloque-o no diretório certo, o Claude Code o detecta na inicialização, e digitar /nome-do-arquivo o aciona.
O conteúdo do arquivo é o prompt enviado ao Claude. Só isso.
Sem sintaxe especial, sem formato de configuração — um arquivo .md é um comando.
Dois locais, dois propósitos:
| Local | Caminho | Escopo |
|---|---|---|
| Projeto | .claude/commands/ |
Apenas o projeto atual, pode ser commitado no git |
| Usuário | ~/.claude/commands/ |
Todos os projetos, pessoal |
O nível de projeto é o núcleo do compartilhamento em equipe. Faça commit de .claude/commands/ no git e todos que clonarem o repositório terão automaticamente o conjunto completo de comandos.
O nível de usuário é para hábitos pessoais — suas verificações de estilo de código preferidas ou integrações de ferramentas que só você usa.
Na raiz do projeto:
mkdir -p .claude/commands
Crie .claude/commands/review.md:
Revise a qualidade do código das mudanças atuais. Foque em:
1. Erros lógicos e casos de borda
2. Se a nomenclatura está clara
3. Código duplicado que vale a pena extrair
4. Problemas de segurança (injeção SQL, XSS, segredos expostos)
Dê sugestões específicas e acionáveis — não conselhos genéricos.
Reinicie o Claude Code e digite /review para acioná-lo.
Comandos de conteúdo fixo têm uso limitado. $ARGUMENTS os torna flexíveis — o que o usuário digita após /comando é substituído no prompt.
Exemplo .claude/commands/test.md:
Escreva testes para o seguinte: $ARGUMENTS
Requisitos:
- Cubra o caminho feliz e os casos de borda
- Os nomes dos testes devem ser autodescritivos
- Use dados reais em vez de mocks onde possível
Uso:
/test o método login da classe UserAuthentication
Claude recebe:
Escreva testes para o seguinte: o método login da classe UserAuthentication
Requisitos:
...
$ARGUMENTS pode aparecer em qualquer lugar do prompt e ser usado várias vezes.
Um comando, uma responsabilidade
Não escreva um comando "faz tudo". /review é para revisão de código, /test para escrever testes, /pr para descrições de PR. Comandos focados são mais fáceis de lembrar e reutilizar.
Escreva prompts concretos, não abstratos
Ruim:
Me ajude a otimizar este código
Bom:
```
Otimize este código para performance. Priorize:
1. Reduzir consultas desnecessárias ao banco (problemas N+1)
2. Evitar computação repetida dentro de loops
3. Substituir buscas lineares por estruturas de dados mais eficientes
Mantenha a interface sem alterações — mude apenas a implementação.
```
Restrições concretas levam a resultados precisos.
Adicione frontmatter aos seus comandos
O campo description aparece na lista de comandos do Claude Code, para que os membros da equipe entendam rapidamente para que serve cada um:
---
description: Revisa as mudanças atuais para feedback de qualidade de código
---
Revise a qualidade do código das mudanças atuais...
Para um projeto Rails, esses comandos cobrem as tarefas de desenvolvimento diário mais comuns:
.claude/commands/review.md — Revisão de código
Revise as mudanças no git diff. Verifique:
- Erros lógicos e tratamento de casos de borda
- Problemas de segurança: injeção SQL, verificações de autorização
- Clareza na nomenclatura
- Lógica duplicada que vale a pena extrair
Para cada problema, indique a localização específica e uma sugestão concreta.
```
.claude/commands/test.md — Gerar testes
Escreva testes para este código: $ARGUMENTS
Use RSpec. Cubra: caminho feliz, casos de borda, condições de erro.
Formato de nomes: describe ... context ... it ...
Use objetos reais por padrão; mock apenas dependências externas quando necessário.
```
.claude/commands/pr.md — Descrição de PR
Com base no git diff e no log de commits, gere uma descrição de PR.
Formato:
(2-3 frases resumindo o que foi feito)
(Contexto e motivação)
(Como verificar esta mudança)
Seja conciso, escrito para um revisor de código.
```
.claude/commands/explain.md — Explicar código
Explique o que $ARGUMENTS faz:
- Qual é sua responsabilidade geral?
- Como a lógica principal funciona?
- Quais casos de borda valem a pena destacar?
Escreva para um desenvolvedor novo nessa parte do código. Foque no porquê, não apenas no o quê.
```
Alguns hábitos são pessoais e não devem ser impostos a toda a equipe. Coloque-os em ~/.claude/commands/:
~/.claude/commands/standup.md — Preparação do standup diário
```markdown
Com base no git log de hoje e nos TODOs abertos, prepare um resumo para o standup:
- O que completei ontem
- O que planejo fazer hoje
- Algum bloqueio
Máximo 5 frases.
```
~/.claude/commands/refactor.md — Sugestões de refatoração
```markdown
Analise $ARGUMENTS e sugira melhorias de refatoração.
Levante apenas mudanças genuinamente valiosas — não refatore por refatorar.
Para cada sugestão, explique: qual problema resolve, quanto trabalho envolve e qual é o risco.
```
O valor real dos comandos personalizados não é a produtividade individual — é dar à equipe um vocabulário compartilhado.
Faça commit de .claude/commands/ no repositório e documente os comandos disponíveis no seu README ou CLAUDE.md. Novos membros têm a biblioteca de prompts acumulada pela equipe no momento em que clonam o repo, sem precisar descobrir por conta própria.
À medida que o projeto evolui, os comandos também evoluem. Se um prompt não está funcionando bem, corrija em uma linha e faça push — toda a equipe recebe a atualização. Esta é a forma de menor sobrecarga para implementar engenharia de prompts no nível da equipe.
.claude/
├── commands/
│ ├── review.md # Revisão de código
│ ├── test.md # Gerar testes
│ ├── pr.md # Descrição de PR
│ └── explain.md # Explicar código
└── settings.json