Criando o seu primeiro comando

Um arquivo de texto vira um comando

A ideia por tras dos comandos personalizados e desarmante de simples: um arquivo de texto vira um comando. Você cria um arquivo com um nome curto, escreve dentro dele o pedido que costuma fazer, e pronto: aquele nome vira um comando de barra. Quando você o chama, o Claude Code pega o conteúdo do arquivo e o entrega ao agente como se você tivesse digitado tudo aquilo. Ou seja, um pedido longo que você repete toda semana, como revise este código procurando problemas de segurança e explique cada achado, vira um comando de uma palavra que faz exatamente isso.

Revise o código que acabei de mudar procurando problemas de segurança.
Para cada achado, explique o risco e sugira a correção, sem alterar nada ainda.

Exemplo de conteúdo de um comando personalizado (um arquivo cujo nome vira o comando).

O nome do arquivo importa porque e ele que vira o comando. Um arquivo chamado revisar vira o comando de mesmo nome; um chamado resumo-do-dia vira outro. Assim que o arquivo existe no lugar certo, o comando aparece no menu da barra, ao lado dos de fabrica, e passa a ser filtrado quando você digita. Não ha mgica nem configuração complicada: e literalmente escrever o pedido num arquivo e dar a ele um bom nome. Essa simplicidade e proposital, para que criar comandos seja algo que você faca sem cerimonia, sempre que perceber uma repetição.

Comando do projeto ou comando pessoal

Assim como a memória tem níveis, os comandos tem dois lugares para morar, e a escolha segue a mesma lógica de alcance. Se o comando é útil para todo o time daquele projeto, como uma revisão no padrão que vocês combinaram, ele vai para a pasta de comandos dentro da configuração do projeto, e viaja pelo controle de versão para todos. Se o comando é um hábito seu, que você quer em qualquer projeto que abrir, ele vai para a pasta de comandos na sua área pessoal. Um e do time, naquele projeto; o outro e seu, em todo lugar. A pergunta e sempre quem mais se beneficia disto?

Uma vantagem dos comandos de projeto e que eles espalham boas práticas pelo time sem esforco. Se você cria um comando de revisão que já embute o que a equipe considera importante, qualquer colega que abrir o projeto ganha esse comando de graca e revisa no mesmo padrão. Comandos viram, assim, uma forma de codificar o jeito de trabalhar do time num atalho compartilhado. E os pessoais fazem o mesmo por você, carregando os seus hábitos de projeto em projeto. Nos dois casos, o ganho e não reinventar o pedido toda vez.

Quando vale a pena criar um comando

Nem todo pedido merece virar comando, e o teste e a repetição. Se você se pega digitando o mesmo pedido longo pela terceira vez, ele é candidato natural a comando. Se e algo que você faz uma vez e nunca mais, não vale o arquivo. O ponto doce são as tarefas recorrentes com um formato fixo: uma revisão no seu padrão, um resumo estruturado, uma checagem que você sempre roda antes de entregar. Transformar essas em comandos economiza digitacao, garante consistencia, porque o pedido sai sempre igual, e reduz a chance de esquecer um detalhe importante no calor da hora.

Com o comando simples dominado, você já pode automatizar boa parte das suas repetições. Mas ha um limite no comando fixo: ele sempre faz a mesma coisa, com o mesmo texto. E se você quisesse um comando de revisão que aceitasse qual arquivo revisar, ou um de resumo que recebesse o tema? Para isso existem os argumentos, que transformam um comando fixo num comando flexível, reutilizavel para vários casos. E o assunto da próxima aula, e o que faz os comandos personalizados saltarem de úteis para poderosos.