Slash Commands (Comandos de Barra)
O que é
Um slash command (comando de barra) é um reutilizável que você aciona digitando /nome no seu agente. Pense em um botão de discagem rápida de um telefone: em vez de discar o número completo toda vez, você aperta um botão e o número inteiro é disparado. Em vez de redigitar uma instrução longa e cuidadosamente redigida toda vez, você a salva uma vez e a invoca com um nome curto. Muitos comandos aceitam argumentos, então um único comando pode ser reutilizado com entradas diferentes — /review src/auth versus /review src/api.
Pontos fortes
- Salva um bom prompt uma vez e o reproduz de forma confiável, em vez de reescrevê-lo a cada uso.
- Curto de invocar, então fluxos de trabalho comuns viram poucas teclas.
- Argumentos tornam um comando flexível para várias entradas diferentes.
- Armazenado como arquivos de texto simples que você pode versionar e compartilhar, para que uma equipe use exatamente a mesma redação.
Contrapartidas
- Um comando só é tão bom quanto o prompt dentro dele — um prompt vago dá resultados vagos.
- Uma pilha crescente de comandos fica difícil de lembrar e manter.
- É um atalho para um prompt, não uma garantia; o agente ainda interpreta o comando.
- Esconde um pouco o que está realmente sendo enviado, o que pode surpreender iniciantes.
Quando usar
Crie um slash command sempre que você perceber que está digitando a mesma instrução repetidamente — um prompt de revisão de código, um gerador de mensagem de , um pedido de "explique este arquivo" — especialmente um com estrutura fixa que você quer manter consistente.
Encaixe no vibe coding
Slash commands transformam seus melhores prompts em um kit de ferramentas pessoal. O prompt cuidadoso que você escreveu uma vez vira um botão confiável que você aperta, então a qualidade não depende de lembrar a redação exata em cada sessão. Combine-os com argumentos para cobrir famílias inteiras de tarefas com um único comando bem ajustado.
---
description: Review a file for bugs and clarity.
argument-hint: <path>
---
Review the file at $ARGUMENTS. List concrete bugs first,
then smaller clarity or naming suggestions. Be specific.