Comandos Slash do Claude Code: crie comandos personalizados de A a Z (2026)

- Este guia segue a documentação oficial em code.claude.com/docs/skills (acessada em 20/08/2026) - a antiga página slash-commands agora redireciona para cá, e a lista de comandos nativos foi para code.claude.com/docs/commands («Commands», com o «Slash» removido). A documentação do Claude Code muda rápido, então alguns campos exigem uma build recente (Claude Code v2.1.x ou posterior).

O que é um comando slash no Claude Code? (nativo vs. personalizado)

No Claude Code, um comando slash é qualquer comando que começa com / e que você digita direto numa sessão de chat para disparar algo rápido. O glossário oficial da Anthropic agora chama isso de «Command» (tirando o «Slash» do texto do produto); este guia mantém o termo pesquisado «comando slash» no título e no texto, porque é assim que as pessoas ainda buscam. São dois tipos, e é fácil confundir.

Os comandos nativos já vêm com o Claude Code, direto da Anthropic - nada para instalar. Alguns que você vai usar quase todo dia:

• /help - lista todos os comandos disponíveis
• /clear - apaga o histórico da conversa e começa com um contexto limpo
• /compact - comprime a conversa para economizar contexto
• /init - gera um arquivo CLAUDE.md para o projeto
• /model - troca o modelo que você está usando
• /status - verifica o status da sessão, da conta e do contexto

Os comandos personalizados são os que você mesma cria para empacotar um prompt que usa muito num único atalho. Sem rodeios: um comando slash personalizado é um arquivo Markdown em .claude/commands/ - o nome do arquivo é o nome do comando, e o corpo do arquivo é o prompt que o Claude roda quando você o chama. Em vez de colar de novo «revise o diff atual seguindo este checklist...» toda vez, você salva uma vez e digita /review.

E aqui vem a parte boa: os comandos personalizados aparecem no mesmo menu dos nativos. Digite / e o menu abre sugerindo tanto os comandos nativos quanto os seus. Se você commitar a pasta .claude/commands/ no seu repositório, o time inteiro compartilha um único conjunto de comandos - e é exatamente por isso que comandos personalizados batem os «prompts de copiar e colar» de longe.

Então por que não colar o prompt toda vez? Três motivos práticos. Um prompt que você usa muito costuma ser longo, e você vai esquecer uma linha se digitar de cabeça. Cada pessoa do time escreve de um jeito um pouco diferente, então os resultados ficam desiguais. E, quando você melhora o prompt, não há como levar essa melhoria para o resto do grupo. Transformar isso num arquivo de comando resolve os três: o prompt fica num só lugar, todo mundo chama o mesmo comando, e editar o arquivo atualiza para todos. Em outras palavras, um comando personalizado transforma um «truque pessoal» numa «ferramenta compartilhada» que você versiona como código.

Crie seu primeiro comando slash personalizado (.claude/commands)

Vamos montar um comando /review que faz o Claude revisar as mudanças do seu código. Três passos, cada um pronto para copiar e colar.

Passo 1 - Crie a pasta de comandos na raiz do seu projeto:

mkdir -p .claude/commands

O Windows PowerShell não tem mkdir -p, então use:

New-Item -ItemType Directory -Force .claude/commands

Passo 2 - Crie o review.md dentro dessa pasta. O nome do arquivo (menos o .md) é o nome do comando. O corpo do arquivo é o prompt:

You are a strict reviewer. Review the current code changes.

Focus on:
- Logic bugs and unhandled edge cases
- Security holes (unvalidated input, leaked secrets)
- Naming, clarity, and duplicated code

For each issue: give the file + line, the severity,
and a concrete fix. No vague praise.

Passo 3 - Rode o comando na sua sessão do Claude Code:

/review

O Claude carrega o conteúdo do arquivo como prompt e roda na hora. Pronto. Você acabou de montar seu primeiro comando personalizado sem escrever uma única linha de código.

Dica: se você acabou de criar o arquivo mas o menu / ainda não mostra o comando, pule para a seção «Problemas comuns» perto do fim - em geral é só a pasta errada ou uma sessão que precisa reiniciar.

Passando argumentos para um comando ($ARGUMENTS, $1, argumentos nomeados)

Um comando engessado não é muito reaproveitado. O poder de verdade vem dos argumentos - o texto que você digita depois do nome do comando é injetado no prompt.

Pegue tudo - $ARGUMENTS. Essa variável captura todo o texto depois do nome do comando. Crie .claude/commands/fix-issue.md:

Fix GitHub issue #$ARGUMENTS. Read the issue description,
find the root cause in the code, then write a fix with tests.

Digite /fix-issue 123 e $ARGUMENTS vira 123. Digite /fix-issue 123 security first e $ARGUMENTS vira a string inteira 123 security first.

Argumentos posicionais - $1, $2... Quando você precisa de cada argumento separado, use variáveis posicionais. Por exemplo, .claude/commands/rename.md:

Rename the variable `$1` to `$2` across every open file,
keeping the logic intact and updating all references.

Digite /rename oldName newName e $1 é oldName, $2 é newName. Para argumentos com várias palavras, coloque entre aspas: /rename "user id" "customer id".

Argumentos nomeados - o frontmatter arguments. Se você quer nomes com significado em vez de $1/$2, declare-os no frontmatter (veja a próxima seção) e faça referência pelo nome. Declare arguments: [from, to] e você pode usar $from e $to - mapeados na ordem dos argumentos.

Referência rápida das variáveis de substituição:

Observação: a página atual das Skills também lista uma forma indexada em 0, $ARGUMENTS[N]/$N ($0 é o primeiro argumento), ao lado da forma indexada em 1, $1/$2, acima - ambas aparecem na documentação neste momento, então confira a documentação ao vivo antes de depender de um índice específico.

Qual você deve usar? Regra simples. Se o comando só recebe «um bloco de texto livre» (a descrição de uma issue, uma pergunta, um trecho para explicar), $ARGUMENTS basta e é o mais flexível. Se o comando precisa de um número exato de argumentos numa ordem fixa (rename: de quê -> para quê), o posicional $1/$2 é mais claro. Argumentos nomeados só valem a pena quando um comando tem vários argumentos fáceis de confundir - aí $from/$to lê melhor do que $1/$2.

Todos os detalhes sobre $ARGUMENTS e argumentos posicionais estão na documentação do Claude Code (acessada em 20/08/2026) (agora incorporada à página das Skills - não existe mais uma página separada de slash-commands). Para uma olhada rápida em toda a sintaxe de comandos, eu deixo à mão a folha de referência do Claude Code.

Frontmatter: configure um comando com YAML

No topo de um arquivo de comando, você pode adicionar um bloco de frontmatter em YAML (entre duas linhas ---) para configurar o comportamento. Essa é a parte que a maioria dos guias pula por completo, mesmo sendo ela que define o quanto o comando é seguro e conveniente de verdade.

Tudo é opcional; na prática, só o description vale a pena adicionar sempre. Aqui vai um .claude/commands/commit.md que deixa o comando mexer só no git e em mais nada:

---
description: Create a conventional commit from staged changes
argument-hint: [optional scope]
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git diff:*)
---

Look at the staged changes and write one tight, accurate
conventional commit (feat/fix/docs/refactor...).
If nothing is staged, tell me to `git add` first.

Com allowed-tools configurado direito, o comando só consegue rodar alguns comandos git predefinidos - bem mais seguro do que deixar o Claude livre para rodar o que quiser. Esse é um hábito que vale cultivar em qualquer comando que toca no shell.

Injetando dados ao vivo com !`bash` (e referências a arquivos)

Um comando fica bem mais forte quando ele mesmo consegue pegar o contexto atual, em vez de fazer você colar. O Claude Code deixa você injetar a saída de um comando bash direto no prompt com a sintaxe !`<command>`.

O ponto-chave para entender: o comando dentro de !`...` roda ANTES de o Claude ler o prompt, e a saída dele é encaixada direto no conteúdo. Isto não é o Claude decidindo rodar um comando - ele já rodou. Aqui vai um comando /review que pega o diff atual sozinho:

Review the diff below and point out bugs + security risks:

!`git diff HEAD`

Quando você digita /review, o Claude Code roda git diff HEAD, pega o resultado, cola no lugar e só então entrega o prompt inteiro para o Claude. Você nunca mais copia o diff na mão.

Para um bloco bash de várias linhas, use um bloco cercado que abre com !:

```!
git status --short
git log --oneline -5
```

Observação: mantenha !`...` no começo de uma linha ou depois de um espaço. Se você quer um $ literal (digamos, um preço como \$1.00 no seu texto), escape-o com uma \ para não ser lido como argumento.

Compartilhando comandos: Projeto vs. Pessoal + subpastas

Os comandos personalizados ficam em dois lugares que diferem pelo escopo:

• Projeto - .claude/commands/ na raiz do repositório. Comite no git e o time inteiro compartilha o conjunto. Ótimo para comandos específicos do projeto: /deploy, /test, as convenções de commit do seu time.
• Pessoal - ~/.claude/commands/ no seu diretório home. Só na sua máquina, mas usável em todos os projetos. Ótimo para hábitos pessoais: /explain, /tldr.

Quando os nomes colidem, o comando de nível de projeto costuma ganhar, porque está mais perto do contexto do projeto.

Subpastas para agrupar comandos (namespacing). Conforme seu conjunto de comandos cresce, crie subpastas para agrupá-los. Por exemplo, .claude/commands/git/commit.md expõe o comando sob um grupo git, mantendo o menu / arrumado e fácil de buscar.

Esse mecanismo de «configure por repositório, comite para compartilhar com o time» é exatamente o espírito do arquivo CLAUDE.md. Se isso é novidade para você, leia como escrever um CLAUDE.md para o seu repositório para que os dois se complementem: o CLAUDE.md declara as convenções compartilhadas, e a .claude/commands/ empacota as ações repetitivas.

5 templates de comando para copiar e colar (prontos para rodar)

Aqui está o conjunto que eu mesma uso no dia a dia. Copie para .claude/commands/ e ajuste para a sua stack.

1. /review - revisa o diff atual (review.md):

---
description: Review current changes for bugs and security risks
---

Review the diff below, prioritizing logic bugs and security holes:

!`git diff HEAD`

For each issue: give file:line, severity, and a concrete fix.

2. /commit - commit convencional (commit.md):

---
description: Write a conventional commit from staged changes
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git diff:*)
---

Look at `git diff --staged` and write one accurate
conventional commit. Do not add AI references to the message.

3. /test - roda os testes e corrige as falhas (test.md):

---
description: Run the test suite and fix failing tests
argument-hint: [optional test file path]
---

Run the tests for $ARGUMENTS (run everything if empty).
If any test fails: read the error, find the root cause, fix
the code or the test, then rerun until green.

4. /docs - escreve docstrings (docs.md):

---
description: Write docstrings for the open file
---

Write docstrings for the functions/classes in the open file.
Follow the language's convention, list parameters, return
values, and errors that can be thrown. Keep it short, don't
repeat the function name.

5. /fix-issue - corrige uma issue pelo número (fix-issue.md):

---
description: Fix a GitHub issue by number
argument-hint: <issue-number>
---

Fix issue #$ARGUMENTS: read the description, find the root
cause, write a fix with tests, briefly explain the fix.

[Novo em 2026] Comandos personalizados se fundem com as Skills - e «Slash Command» agora é só «Command»

Essa é a grande mudança que a maioria dos guias atuais ainda não acompanhou. Segundo a documentação oficial das Claude Code Skills (acessada em 20/08/2026), os comandos personalizados foram fundidos nas Skills. A tabela «Termos descontinuados e renomeados» do glossário oficial deixa claro: «Slash commands → Commands» (tirando o «Slash» do texto do produto) e «Custom commands → Skills», e afirma sem rodeios que «as Skills são a sucessora recomendada dos comandos personalizados» - embora seus arquivos antigos em .claude/commands/ continuem rodando de boa.

Na prática: um arquivo .claude/commands/deploy.md e uma skill .claude/skills/deploy/SKILL.md criam os dois o comando /deploy, usando o mesmo mecanismo de frontmatter. O que importa para você: seus arquivos antigos .claude/commands/*.md continuam rodando de boa - não há nada para migrar às pressas.

Então quando você deve subir para uma Skill? Uma Skill difere de um comando em dois pontos: (1) ela é uma pasta, então pode guardar arquivos de apoio (scripts, templates, docs de referência) ao lado do prompt; e (2) o Claude pode carregá-la automaticamente quando ela é relevante para a tarefa em mãos, sem você digitar um comando. Resumindo: comandos são melhores para ações únicas e invocadas na mão; skills são melhores para capacidades complexas, de vários arquivos, que você quer disparar sozinhas.

Para se aprofundar, leia o que são as Skills no Claude Code e depois como criar uma skill personalizada. Se os conceitos ainda se misturam, o texto sobre skills vs subagents vs hooks vs MCP desembaraça tudo para você.

Problemas comuns & dicas

• O comando não aparece no menu /. Confira se você está na pasta certa - .claude/commands/ (plural, com ponto na frente) - e se o arquivo tem a extensão .md. Na primeira vez que criar uma subpasta, reinicie a sessão do Claude Code para ele re-escanear.
• Os argumentos não expandem. Se o seu prompt tem $2 mas você passa só um argumento, $2 fica como texto literal. Use $ARGUMENTS quando o número de argumentos não é fixo.
• Um $ é lido errado, como variável. Escreva \$1.00 (com uma \) quando quiser um cifrão literal em texto comum.
• Quando NÃO fazer um comando. Se é algo pontual, ou muda toda vez, digitar o prompt direto é mais rápido. Um comando só se justifica quando a ação é repetida e estável. Não empacote tudo em comandos - um conjunto inchado e pouco usado só bagunça o menu /.

Não quer escrever o seu? Use um conjunto de comandos pronto

Escrever os comandos você mesma é a melhor forma de entender a mecânica e manter o controle - eu recomendaria a qualquer pessoa construir pelo menos os primeiros na mão. Mas se você prefere ter um conjunto de comandos e skills já desenhados e testados para fluxos comuns, dê uma olhada no conjunto pronto de comandos e skills do AgentKit: segundo a página inicial dele, ele reúne mais de 108 skills e 45 agentes de IA para o Claude Code, divididos em um Engineer Kit e um Marketing Kit. Você ainda pode personalizar tudo como em qualquer arquivo .claude/commands/ normal - só não começa do zero. Para ver direto, você pode experimentar o AgentKit aqui (20% de desconto pelo link); o site menciona garantia de devolução do dinheiro (sem condições específicas indicadas) e atualizações vitalícias para os kits.

Perguntas frequentes (FAQ)

Onde ficam armazenados os comandos slash personalizados?

Em .claude/commands/ na raiz do seu projeto (compartilhado com o time quando você comita no git), ou em ~/.claude/commands/ no seu diretório home (só na sua máquina, mas usável em todos os projetos). O nome do arquivo menos a extensão .md é o nome do comando.

Como passo vários argumentos para um comando?

Use $ARGUMENTS para pegar de uma vez todo o texto depois do nome do comando, ou $1, $2... para cada argumento posicional. Coloque argumentos de várias palavras entre aspas: /rename "old id" new.

Qual a diferença entre um comando personalizado e um nativo?

Os comandos nativos (/help, /clear, /compact...) já vêm com o Claude Code, da Anthropic. Os comandos personalizados são os que você cria como arquivos Markdown, empacotando o seu prompt ou o do seu time. Os dois aparecem juntos no menu /.

Posso rodar comandos de terminal dentro de um comando?

Pode. Use a sintaxe !`<command>` - o comando bash roda primeiro e a saída dele é encaixada no prompt antes de o Claude ler. Por exemplo, !`git diff HEAD` deixa o comando pegar o diff atual sozinho.

Os comandos podem ser comitados e compartilhados com todo o time?

Podem. Coloque o comando em .claude/commands/ na raiz do repositório e comite no git. Todo mundo que clona o repositório recebe o mesmo conjunto de comandos, mantendo o fluxo do time em sincronia.

Qual a diferença entre um comando personalizado e as Skills?

Em 2026 os dois se fundiram, e os arquivos de comando antigos ainda rodam. A diferença: um comando é um único arquivo de prompt, invocado na mão; uma skill é uma pasta que pode guardar arquivos de apoio e pode carregar automaticamente quando o Claude a considera relevante. Comandos servem para ações únicas, skills para capacidades complexas.

Conclusão + próximos passos

Comandos slash personalizados são a forma mais barata de transformar prompts repetidos numa ferramenta compartilhada: um arquivo Markdown, uma tecla, e o time inteiro se beneficia. Comece com /review e /commit, adicione frontmatter quando precisar de segurança e depois suba para uma Skill conforme seu fluxo fica mais complexo. Continue com o que são as Skills no Claude Code e como criar uma skill personalizada, ou abra a folha de referência do Claude Code para consultar a sintaxe quando quiser.