Voltar para todos os artigos
Artigo

Skills de Agente ou prompts: quando usar cada um

Autor:

Um prompt faz um pedido à IA; uma Skill de Agente reúne orientações reutilizáveis. Um exemplo de relatório semanal ajuda a decidir qual opção usar.

Uma pasta de documentos aberta com um cartão de instruções encaixado dentro dela

Toda sexta-feira, você pede a um assistente de IA que transforme suas anotações de trabalho em uma atualização semanal. As mesmas regras precisam ser repetidas: separar o que foi concluído do que está planejado, deixar os impedimentos visíveis e nunca inventar um prazo. Os fatos da semana mudam; as regras do relatório, não.

Um prompt salvo pode ser suficiente. Vale considerar uma Skill de Agente quando você quer manter essas regras recorrentes em um pacote reutilizável por um agente compatível. Uma Skill não elimina a necessidade de prompts, não fornece fatos ausentes nem garante que o relatório esteja correto.

A visão geral de Agent Skills descreve um formato baseado em pastas para conhecimentos e fluxos de trabalho reutilizáveis. Esse é o sentido técnico de “Skill” neste texto; não se trata de afirmar que o modelo aprendeu uma nova capacidade durante o treinamento. Os detalhes do formato foram conferidos em 7 de setembro de 2026.

Compare o que permanece fixo e o que muda

PerguntaPrompt para um pedidoSkill de Agente
Onde ficam as regras recorrentes?No texto que você fornece ou reutilizaEm um pacote de instruções mantido para esse fim
Onde ficam os fatos desta semana?Na entrada atualAinda precisam estar na entrada atual ou em uma fonte acessível
Exemplos e modelos podem ajudar?Você pode incluí-los no pedidoEles podem ser agrupados como recursos de apoio
O que o aplicativo precisa oferecer?Receber o pedido e a entrada relevantesDescobrir e usar a Skill, além de fornecer as ferramentas necessárias
O que comprova que o resultado pode ser usado?A revisão do relatórioAs mesmas verificações do relatório

Um prompt pode ser longo e reutilizável. Uma Skill pode ser curta e conter apenas instruções. O tamanho não é a diferença. Na prática, o que muda é a maneira de armazenar, disponibilizar e manter as orientações recorrentes.

Teste o pedido recorrente antes de criar um pacote

Considere estas anotações semanais fictícias:

Rascunho da página de ajuda concluído na segunda-feira.
Revisão solicitada a Mina; ainda não houve resposta.
Publicar depois da revisão. Nenhuma data de publicação foi combinada.
Bug da busca reproduzido; correção ainda não iniciada.

Para uma atualização feita uma única vez, este pedido já descreve o trabalho de forma suficiente:

Transforme estas anotações em uma atualização semanal com três seções:
Concluído, Aguardando outras pessoas e Próximo trabalho.
Preserve a diferença entre trabalho concluído e trabalho planejado.
Não invente responsáveis, datas, aprovações nem progresso.
Se faltar um fato essencial, marque-o como não confirmado.

[Cole as anotações desta semana.]

Um relatório que diga “Mina aprovou o rascunho; publicar na sexta-feira” falha duas vezes. Pedir um texto bem-acabado não autorizou nenhuma dessas invenções. Ao conferir as fontes, você deve constatar que o rascunho está pronto, a revisão continua pendente, não há data de publicação combinada e o bug foi reproduzido, mas não corrigido.

Se você só prepara essa atualização de vez em quando, salve o pedido em um documento e cole-o quando precisar. Assim, as instruções podem ser reutilizadas sem criar uma nova tarefa de instalação ou manutenção.

Uma Skill guarda a parte recorrente separadamente

Para um agente compatível, as mesmas regras de relatório poderiam ser armazenadas em um arquivo chamado SKILL.md, dentro de uma pasta chamada weekly-update. A especificação do formato exige um nome e uma descrição nos metadados YAML, seguidos por instruções em Markdown.

Este é um exemplo mínimo de autoria, não uma Skill instalada nem o resultado de um benchmark:

---
name: weekly-update
description: Transforme anotações de trabalho em uma atualização semanal factual. Use ao redigir um relatório semanal recorrente a partir das anotações fornecidas.
---

# Atualização semanal

Leia as anotações fornecidas. Se não houver nenhuma, peça-as.

Escreva três seções:
- Concluído
- Aguardando outras pessoas
- Próximo trabalho

Mantenha o trabalho planejado separado do trabalho concluído.
Não invente responsáveis, datas, aprovações nem progresso.
Marque informações essenciais ausentes como não confirmadas.
Antes de entregar o relatório, confira cada status nas anotações de origem.
Entregue um rascunho; não o envie a ninguém.

As anotações desta semana não devem permanecer nessas instruções. Se você incorporar “Mina não respondeu” à Skill, essa informação poderá estar desatualizada na semana seguinte. Forneça os fatos novos em cada pedido e mantenha no pacote o processo recorrente.

Agora, o pedido atual pode se concentrar na entrada variável: “Use a Skill weekly-update para redigir o relatório desta semana com base nestas anotações.” O agente ainda precisa encontrar e seguir a Skill. Siga as instruções de instalação e uso do cliente escolhido; criar uma pasta em algum lugar do computador não basta para torná-la disponível.

Empacotar instruções não substitui os testes

O formato permite descobrir uma descrição curta antes de carregar as instruções completas quando necessário. Isso pode evitar que orientações reutilizáveis extensas entrem em tarefas sem relação com elas. Porém, não comprova que todo cliente ativará a Skill certa para qualquer formulação de um pedido.

Use as mesmas anotações fictícias para comparar o prompt salvo e a Skill. Procure os fatos exatos acima, e não apenas títulos de seção iguais. Depois, remova completamente as anotações: o fluxo pede a entrada ou produz um relatório fictício? Por fim, informe que a revisão foi confirmada e observe se o relatório altera somente o status afetado.

Esses são casos de aceitação sugeridos. Não medimos este exemplo em vários clientes, portanto não alegamos melhora de precisão ou velocidade. O relato de engenharia da Anthropic sobre Skills também recomenda começar com tarefas representativas e falhas observadas, em vez de presumir que um pacote maior é melhor.

Uma Skill também pode conter scripts. Leia o que eles fazem antes de usar um pacote criado por outra pessoa, especialmente se ele solicitar acesso a arquivos ou conexões externas. Instruções para escrever um relatório são diferentes de código que o envia. A presença do pacote não é uma autorização para executar todas as ações mencionadas nele.

Quando vale a pena manter uma Skill?

Considere uma Skill quando vários elementos se repetem em conjunto: regras do relatório, um modelo, exemplos de resultados aceitáveis ou um procedimento que usa ferramentas. Um único pacote mantido oferece um lugar para atualizar esses elementos e repetir as verificações depois de uma mudança.

Continue usando um prompt salvo quando a tarefa for ocasional, as regras forem curtas ou o seu aplicativo não aceitar o formato. Se as instruções forem ambíguas, transferi-las para um arquivo não resolverá o problema. Primeiro, obtenha um relatório que você consiga conferir; depois, separe as orientações recorrentes dos fatos que mudam a cada semana.

Referências