Um comando de barra é um arquivo Markdown cujo corpo vira um prompt. É a forma mais simples de parar de redigitar o mesmo pedido — uma revisão, uma checagem de release, um resumo no formato que sua equipe espera — e a menos chata de toda a configuração. O único ponto em que dá errado são os argumentos. Tudo o que se digita depois do nome do comando chega como um marcador, as palavras individuais como marcadores numerados, e um corpo que não menciona nenhum deles ignora o que o usuário passou enquanto continua anunciando que aceita algo. Este criador escreve o arquivo, oferece os marcadores como botões e aponta esse descompasso nos dois sentidos.
Recursos
Marcadores inseridos por botões em vez de lembrados
Avisa quando um argumento é anunciado e o prompt nunca o usa
Avisa quando o prompt usa um argumento e nada diz ao usuário o que passar
Lista opcional de ferramentas e troca de modelo
O nome é conferido como nome de arquivo, porque é nisso que ele vira
Escopo de projeto ou pessoal com o caminho correspondente
Prévia de como o comando será digitado
Baixa como um arquivo .md pronto para usar
Como usar Construtor de comandos
Nomeie o comando: será tanto /nome quanto o nome do arquivo
Escreva o prompt inserindo $ARGUMENTS ou $1 onde entra a entrada
Acrescente uma dica de argumento para o usuário saber o que passar
Escolha um escopo e baixe o arquivo
Exemplo
Entrada
argument-hint: <pr-number>
Saída
Review pull request #$1.
A dica e o marcador precisam concordar, senão um dos dois está mentindo.
Erros comuns e solução de problemas
O comando ignora o que digito depois dele. — O corpo precisa usar a entrada. $ARGUMENTS é tudo o que foi digitado; $1, $2 e $3 são as palavras individuais.
O comando não aparece na lista. — O nome do arquivo é o nome do comando, então precisa estar em minúsculas com hifens e ficar no diretório de comandos do escopo escolhido.
Falta a descrição na lista. — Ela vem do campo description no frontmatter. Sem ele o comando aparece sem rótulo.
$1 e $ARGUMENTS parecem se sobrepor. — E se sobrepõem: $ARGUMENTS inclui tudo, $1 é a primeira palavra. Use um ou outro, a menos que queira os dois de propósito.
Perguntas frequentes
Qual a diferença entre $ARGUMENTS e $1?
$ARGUMENTS é toda a string digitada após o nome do comando. $1, $2 e $3 são as palavras separadas por espaço. Use os numerados quando o comando recebe um conjunto fixo de entradas, e $ARGUMENTS quando recebe texto livre.
Preciso de uma lista de ferramentas permitidas?
Não, e a maioria dos comandos não usa. Vale a pena quando um comando deve poder executar algo específico sem perguntar toda vez, ou quando você quer que ele não consiga fazer algo que a sessão faria.
Onde fica um arquivo de comando?
Um comando de projeto fica no repositório para toda a equipe ter; um pessoal acompanha você entre projetos. O caminho exato é mostrado e se atualiza com o nome.
Um comando pode chamar ferramentas ou rodar comandos de shell?
O corpo é um prompt, então pode pedir qualquer coisa que a sessão já pudesse fazer. A lista de ferramentas estreita ou amplia o que roda sem perguntar; não concede nada novo.
Quando isso deve ser um comando e não uma skill?
Um comando é invocado de propósito, digitando. Uma skill é associada automaticamente quando uma tarefa parece relevante. Se você quer escolher o momento, escreva um comando; se quer que aconteça sozinho, escreva uma skill.
Ferramentas relacionadas
Construtor de skills — Escreva um SKILL.md com o frontmatter verificado enquanto você digita.
Construtor de subagentes — Monte o arquivo de definição de um subagente com ferramentas e modelo.
Construtor de hooks — Monte hooks do settings.json e pegue os matchers que nunca disparam.
Manifesto de plugin — Gere um plugin.json e veja a estrutura de pastas que ele espera.