Claude Skills vs. Comandos Slash vs. Subagentes

Índice

Atualizado agosto 2026.

TL;DR: Comandos slash são atalhos para um prompt que você digita com frequência — você os invoca pelo nome. Subagentes são trabalhadores paralelos com sua própria janela de contexto — você (ou o Claude) os cria para uma tarefa delimitada e recebe um resultado de volta. Skills são conhecimento empacotado que o Claude decide carregar por conta própria, com base no que você está pedindo, sem que você nomeie nada. A maioria das pessoas recorre a um agente personalizado quando um comando slash já resolveria, e recorre a um comando slash quando na verdade precisava de uma skill que o Claude pudesse acionar sozinho.

[Leitura do operador] Eu rodo mais de 30 agentes em produção em dois negócios, e essa exata confusão — comando, subagente ou skill — é a primeira pergunta de design em quase todos eles. Errar nessa escolha significa construir dez comandos cujos nomes ninguém lembra, ou uma skill tão ampla que nunca dispara de forma confiável. A solução não é uma regra de bolso, é perguntar o que realmente varia entre uma execução e outra.

Os três primitivos resolvem problemas diferentes

Os três permitem empacotar instruções uma vez e reutilizá-las. É aí que a semelhança termina, e é exatamente por isso que as pessoas os confundem — de fora, “digitar algo curto e obter um resultado útil” parece igual, não importa qual dos três está fazendo o trabalho por baixo.

A diferença real é quem decide invocá-lo, e em que contexto ele roda:

• Um comando slash é invocado por você, pelo nome. Você digita /deploy ou /review, o Claude expande isso em uma instrução mais completa, e ela roda na sua conversa atual.
• Um subagente é invocado por você ou pelo Claude, para uma tarefa com um limite claro. Ele recebe sua própria janela de contexto, faz o trabalho e reporta um resultado de volta — não vê sua conversa inteira, e você não vê seus passos intermediários a menos que peça.
• Uma skill é invocada pelo Claude, automaticamente, quando seu pedido corresponde ao que a descrição da skill diz que ela cobre. Você nunca digita o nome dela. Se você não pedir algo que a skill trata, ela nunca carrega.

Essa terceira propriedade — sem invocação explícita — é a mais subutilizada. É também a que traz mais alavancagem assim que você tem mais do que um punhado de fluxos empacotados, porque você para de precisar lembrar como nomeou as coisas.

Comandos slash: atalhos para um prompt que você digita com frequência

Construa um comando slash quando o gatilho for “eu fico digitando basicamente a mesma instrução.” Um comando que sempre resolve para o mesmo prompt subjacente, expandido a partir de um nome curto que você escolheu, na conversa que você já está tendo. Sem contexto separado, sem invocação autônoma — você decide quando ele roda, toda vez.

Bons encaixes: um checklist de release fixo, uma passada de code review com suas regras da casa embutidas, um atalho de “resumir este PR.” O comando não precisa de julgamento sobre se deve rodar — você é quem toma essa decisão ao digitá-lo.

O modo de falha é construir um comando para algo que na verdade precisa que o modelo decida se aquilo se aplica. Se metade do seu uso é “espera, essa situação conta?” — isso é uma pergunta de skill, não de comando, porque um comando não tem como se acionar sozinho.

Subagentes: trabalhadores paralelos com sua própria janela de contexto

Construa um subagente quando a tarefa for delimitada, delegável, e de outra forma poluiria sua conversa principal com passos que você não precisa ver. Um subagente roda seu próprio contexto — suas próprias chamadas de ferramentas, seu próprio vai-e-vem — e devolve um resultado. É o mesmo princípio que escrevi em engenharia de contexto: cada chamada de ferramenta e passo intermediário extra é contexto que sua thread principal não precisa carregar, e um subagente é como você mantém esse ruído de fora.

Bons encaixes: “pesquise isso e me reporte,” “rode esses cinco checks independentes em paralelo,” “vá corrigir este arquivo isoladamente.” A tarefa tem um início, um fim e uma entrega — exatamente a forma que o eval harness que uso para lançar agentes trata como uma única unidade avaliável.

O modo de falha é criar um subagente para algo que precisava ficar no seu contexto principal, porque o próximo passo depende de detalhes que o resumo do subagente descartou. Se você fica tendo que perguntar de novo ao subagente “espera, o que exatamente você encontrou,” o limite foi traçado errado — ou dobre a tarefa de volta para a thread principal, ou torne o relatório do subagente estruturado o suficiente para que nada se perca na tradução.

Skills: conhecimento empacotado que o Claude carrega por conta própria

Construa uma skill quando a condição de gatilho for algo que o Claude deveria reconhecer a partir do que você está pedindo, não algo que você deveria lembrar de nomear. Uma skill é uma descrição mais um pacote de instruções e scripts; o Claude lê a descrição, decide se o seu pedido corresponde, e carrega as instruções completas só se corresponder. Você nunca digita /nome-da-skill.

O exemplo mais claro que posso apontar é o que roda o pipeline por trás deste blog. O alejandrorioja.com publica em 13 idiomas, e todo o fluxo de gerar → traduzir → renderizar → revisar vive em uma única skill: um arquivo SKILL.md descrevendo quando usá-la (“gerar um novo post,” “traduzir para todos os idiomas,” “rascunhar uma divulgação”), mais os scripts que fazem o trabalho de fato. Eu não rodo quatro comandos separados e preciso lembrar a ordem deles. Eu digo o que quero em linguagem simples, e a descrição da skill é específica o suficiente para o Claude identificar e rodar os passos certos — da mesma forma que a skill de anúncios do Facebook dispara com “confira meus anúncios” sem que eu digite o nome de um comando.

Essa escolha de design — uma skill decidindo por conta própria quando se aplica — também é o motivo pelo qual o padrão de segurança importa mais aqui do que com comandos ou subagentes. Um comando slash só roda quando você o digita; uma skill roda quando o modelo acha que deveria. Minha skill de conteúdo escreve rascunhos por padrão e exige um passo de aprovação explícito e separado antes que qualquer coisa seja publicada ou enviada — o mesmo padrão de humano no loop que uso em qualquer lugar onde uma skill possa se acionar rumo a uma ação com consequências reais.

Bons encaixes: qualquer coisa com uma frase-gatilho reconhecível e um procedimento repetível por trás — “gerar um relatório,” “avaliar esta submissão,” “rascunhar um resumo para o Slack.” O modo de falha é uma descrição de skill tão ampla que dispara quando você não queria, ou tão estreita que nunca dispara quando você queria. Escreva a descrição da forma como você explicaria o gatilho para um novo contratado, não da forma como nomearia uma função.

O framework de decisão

Pergunte isto	Se sim →	Por quê
Eu sempre quero digitar um nome para acionar isso?	Comando slash	Você é o gatilho, não o modelo
A tarefa é delimitada, delegável e melhor mantida fora do meu contexto principal?	Subagente	Janela de contexto própria, devolve um resultado
O Claude deveria reconhecer a necessidade sem que eu nomeie nada?	Skill	Correspondência por descrição, acionamento automático
Isso envolve dinheiro, publicação, ou algo difícil de desfazer?	Qualquer um dos três, mais uma barreira de aprovação explícita	Acionamento automático não é o mesmo que execução automática

A maioria dos fluxos de trabalho reais é uma pilha desses três, não uma escolha única. Meu pipeline de conteúdo é uma skill (acionada automaticamente com “escreva um post”) que internamente chama subagentes (um por idioma, rodando em paralelo) e expõe um comando slash (/publish) para o único passo — ir ao ar — que nunca deve acontecer sem eu dizer explicitamente que sim.

O erro que mais vejo

Construir um agente personalizado completo — com seu próprio agendamento, seu próprio estado, seu próprio deploy — para algo que na verdade era um comando slash fantasiado. Se a tarefa é “rode este procedimento exato quando eu mandar,” você não precisa de autonomia, memória, ou uma condição de gatilho. Você precisa de um nome e um prompt. Guarde a maquinaria de subagente e skill para tarefas em que o limite (subagente) ou o gatilho (skill) está de fato fazendo trabalho, não apenas adicionando infraestrutura a algo que já era simples.

O veredito do operador

Pergunte quem decide invocar antes de perguntar como construir. Você decidindo, pelo nome, toda vez → comando slash. Uma tarefa delimitada que você quer fora do seu contexto principal → subagente. O Claude reconhecendo a necessidade por conta própria → skill, com uma barreira de aprovação em qualquer coisa que não possa ser desfeita. Acerte essa única pergunta e o resto — o que vai no arquivo, quanta instrução empacotar — quase se resolve sozinho.

FAQ

Qual é a diferença entre uma skill do Claude e um comando slash?

Um comando slash é invocado explicitamente, pelo nome, toda vez que você quer que ele rode. Uma skill é invocada automaticamente — o Claude compara seu pedido com a descrição da skill e a carrega sem que você nomeie nada. Use um comando quando você é sempre quem decide acioná-lo; use uma skill quando a condição de gatilho é algo que o modelo deveria reconhecer sozinho.

Quando devo usar um subagente em vez de uma skill?

Quando a tarefa é delimitada e delegável e você quer que ela rode em sua própria janela de contexto, separada da sua conversa principal — não por causa de como é acionada, mas por causa de onde o trabalho acontece. Skills e subagentes não são mutuamente exclusivos: uma skill pode criar subagentes internamente, da mesma forma que uma skill de tradução pode distribuir um post para um subagente por idioma.

É seguro deixar uma skill acionar automaticamente ações como publicar ou gastar dinheiro?

Só com uma barreira de aprovação explícita no passo de consequência. O acionamento automático da skill em si não tem problema — significa apenas que o Claude reconheceu o que você está pedindo. O risco é a execução automática de algo difícil de desfazer. Mantenha rascunhar, ler e reportar dentro da skill acionada automaticamente; exija uma confirmação separada e explícita para publicar, pagar ou excluir.

Preciso construir os três eventualmente?

Só se seus fluxos de trabalho realmente tiverem as três formas. Um operador solo com um punhado de tarefas repetíveis pode viver inteiramente de comandos slash por muito tempo. A necessidade de skills e subagentes aparece quando você tem condições de gatilho distintas o suficiente para não lembrar mais os nomes dos comandos, ou subtarefas delimitadas o suficiente para que mantê-las no seu contexto principal comece a prejudicar a qualidade.

---

Relacionados: A skill do Claude que roda meus anúncios do Facebook · Engenharia de contexto: o que entra na janela de contexto · Agentes de IA com humano no loop: quando construir uma barreira de aprovação · A stack de agentes que uso para rodar mais de 30 agentes em produção

Precisa de ajuda para decidir o que automatizar e como? Entre em contato — eu desenho sistemas de agentes em produção para equipes de operadores.