O que são skills de IA e como usar no trabalho

Você pediu ao assistente, pela terceira vez nesta semana, o mesmo bloco longo: como resumir a reunião, como estruturar o post, como conferir a planilha. A resposta veio boa. Na quinta, o método sumiu. Você cola o parágrafo de novo. O assistente não esqueceu de propósito. Ele não tinha um lugar para guardar o jeito de fazer o trabalho.

Esse é o problema. Não é falta de modelo. É falta de receita.

Uma skill de IA é essa receita. Um texto curto, reutilizável, que o agente carrega quando a tarefa combina. Costuma viver num arquivo pequeno (o nome comum é SKILL.md) com duas peças: quando usar e quais passos seguir. Não é uma linguagem de programação. É o método da casa escrito para o agente ler, em vez de você colar o mesmo texto a cada conversa.

O que uma skill é (e o que não é)

Skill, neste sentido, é o jeito de fazer. Você descreve o serviço uma vez. Na próxima call, no próximo post, na próxima planilha, o agente lê aquela descrição e tenta repetir o método. A qualidade da skill é a qualidade dessa descrição: o gatilho precisa ser específico, os passos precisam ser ações, o resultado precisa ter forma.

Três objetos parecidos entram na conversa e não são a mesma coisa.

Não é o prompt de uma vez. O prompt de uma vez vive naquela janela. Você fecha o chat, o método vai embora. A skill fica no lugar combinado (pasta do projeto, configuração do agente, repositório da equipe) e volta quando o pedido parecer com a tarefa. Você pode até rascunhar a skill a partir de um prompt que já funcionou duas vezes. A diferença é o destino: o prompt some; a receita permanece.

Não é MCP. MCP (Model Context Protocol) é o encaixe para o assistente usar ferramenta e dado: pasta, planilha, API. A skill não abre o sistema. Ela diz como fazer o serviço depois que o acesso existe. MCP é o plug. Skill é o modo de operar. Sem acesso, o agente descreve um trabalho que não consegue executar. Sem skill, ele acessa a pasta e improvisa o método. Se o termo ainda está opaco, leia O que é MCP (Model Context Protocol) e para que serve.

Não é comando de barra para foto de produto. Atalhos tipo /productshot ou /instagram restilizam uma imagem. São prompts curtos de cena, não um método de trabalho com passos, conferência e o que não fazer. Se a equipe usa esses atalhos, o guia de comandos para foto de produto cobre esse outro objeto. A skill não aplica um filtro. O slash não segue a política da casa.

Como funciona, em linguagem comum

Você escreve duas coisas no arquivo. Primeiro, uma linha de quando usar: "quando o pedido for resumir reunião, ata ou call de trabalho". Depois, os passos: limpar nomes, estruturar, conferir, devolver no formato combinado.

Na hora do pedido, o agente compara o que você escreveu no chat com as descrições das skills que ele conhece. Se a descrição bater, ele lê o arquivo e tenta seguir os passos. Se não bater, ignora a receita e responde do jeito genérico. Por isso a linha de quando usar não pode ser "quando fizer sentido". Precisa apontar a tarefa.

Na prática, o agente não lê todas as receitas inteiras a cada mensagem. Ele lê as descrições (quando usar) e só abre os passos da que combinou. A linha de gatilho precisa funcionar sozinha, sem depender de um detalhe enterrado no passo 7.

Você não programa o agente. Você documenta o jeito da casa. O ciclo no trabalho é este:

1. Note uma tarefa em que você já colou o mesmo parágrafo duas vezes.
2. Escreva a receita: nome, quando usar, cinco a oito passos, o que feito parece, o que não fazer.
3. Grave o arquivo onde o agente da casa procura skills (muitas vezes uma pasta com um SKILL.md por receita).
4. Na próxima vez, peça a tarefa em linguagem normal. Não cole o método de novo.
5. Confira o resultado. Se um passo sumiu, o texto da receita é que precisa ficar mais claro, não o tom do pedido.

Ferramenta é exemplo, não o produto. Claude, Cursor, Grok Bot e outros agentes leem arquivos deste tipo. O gesto é o mesmo: receita no disco, gatilho na descrição, passos no corpo. Se a sua ferramenta usar outro nome de arquivo, use o que ela documenta. O conteúdo importa mais que a extensão.

Exemplo 1. Skill para resumir reunião sem vazar dado

A tarefa que mais volta: sair da call com transcrição bagunçada e pedir "resume isso". Sem receita, o assistente devolve um parágrafo literário, às vezes com nome de cliente e um prazo que ninguém fechou. O método de resumir reuniões e e-mails sem vazar dados já está neste site. A skill é esse método virando arquivo, para você não colar o bloco a cada ata.

Você escreve isto na receita (adapte papéis e formato ao time):

Nome: resumir-reuniao-sem-vazar

Quando usar: o pedido for resumir reunião, ata, call ou thread de e-mail de trabalho.

Passos:

1. Recuse o texto se ainda tiver CPF, CNPJ, salário, preço fechado, e-mail pessoal ou nome completo de cliente. Peça a versão limpa (papéis no lugar de nomes) antes de continuar.
2. Use só o que está no texto. Se prazo, dono da ação ou acordo não aparecer, escreva "não consta". Não complete com o que "costuma" acontecer em reunião.
3. Estruture a resposta em cinco blocos: contexto em uma frase; decisões confirmadas; pendências com dono e prazo se constarem; discordâncias; próximo passo marcado como sugestão, não como decisão.
4. Não transforme silêncio em consenso. Não invente dono da ação. Se duas pessoas discordaram, a discordância permanece.
5. Devolva o resumo. Não envie e-mail, não publique, não grave o texto como ata oficial.
6. No fim, liste o que ficou de fora por falta de dado no original.

O que feito parece: um resumo em cinco blocos, sem nome próprio, sem número que o texto não tinha, com "não consta" onde faltar fato.

O que não fazer: colar a transcrição crua em conta pessoal; tratar o resumo como ata; pedir para "melhorar o tom" apagando discordância.

Na quinta você solta a transcrição já limpa e escreve "resume a call de hoje". O agente puxa a skill, monta os cinco blocos e para. Você confere no original. A receita não substitui a conferência: o agente ainda pode inventar um prazo. Só impede o método de evaporar entre uma conversa e outra.

Exemplo 2. Skill para o checklist antes de publicar um post

Outra tarefa que se repete: o texto está pronto e alguém pede "dá uma olhada antes de ir ao ar". Sem receita, o agente devolve opinião de estilo. Com receita, ele percorre a mesma lista que o time já usa no papel.

Você escreve isto na receita:

Nome: checklist-antes-de-publicar

Quando usar: o pedido for revisar, checar ou liberar um post, artigo ou peça de conteúdo antes de publicar.

Passos:

1. Confirme o título, o slug e o endereço canônico. Se faltar um dos três, pare e pergunte. Não invente slug.
2. Confira se os links internos apontam para o domínio certo da casa, não para um domínio antigo de teste.
3. Verifique se a imagem de capa tem texto alternativo. Se não tiver, proponha uma linha descritiva, sem slogan.
4. Leia o texto em busca de afirmação de fato sem fonte e de tom que a casa não usa (promessa de resultado, "você vai aprender").
5. Confira o resumo curto e a meta description: uma ideia cada um, sem copiar o título palavra por palavra.
6. Liste o que passou e o que bloqueia a publicação. Cada bloqueio traz o trecho e o conserto sugerido.
7. Não publique. Não altere o que já está no ar. Não reescreva o artigo inteiro para "ficar melhor".

O que feito parece: duas listas, itens ok e bloqueios, com trecho citado em cada bloqueio.

O que não fazer: inventar fonte; apertar publicar; trocar o tom do texto por conta própria.

O mesmo molde serve para um estilo fixo de foto de produto: fundo, recorte, o que não inventar no rótulo, formato. A skill descreve o método da equipe. O comando de barra, se ainda existir, continua sendo atalho de cena, não esta receita. Não peça à skill que "aplique /productshot". Peça o contrato: manter produto, trocar palco, recusar texto inventado na embalagem.

Como escrever a primeira skill

Não comece por um catálogo. Comece por uma tarefa que você já repetiu esta semana.

Cinco peças, nesta ordem:

1. Nome curto, em minúsculas, com hífen: resumir-reuniao, checklist-post, conferir-planilha. O nome é etiqueta, não slogan.
2. Uma linha de quando usar. Específica o bastante para o agente não aplicar a receita no pedido errado. "Quando o usuário pedir ajuda" é inútil. "Quando o pedido for conferir a planilha de horas da semana" serve.
3. Cinco a oito passos, em ordem. Cada passo é uma ação verificável, não um valor ("seja claro"). Se o passo precisa de um dado que o agente não tem, diga para perguntar, não para inventar.
4. O que feito parece: o formato da entrega (cinco blocos, lista de bloqueios, tabela com três colunas). Sem isso, o agente improvisa o envelope.
5. O que não fazer: enviar, publicar, apagar, colar segredo, tratar a saída como documento oficial.

O arquivo pode ser Markdown simples. No topo, o nome e a descrição de quando usar. Abaixo, os passos, o feito e o não fazer. SKILL.md é o nome que vários agentes já procuram. Se a ferramenta pedir outro nome ou uma pasta por skill, siga a documentação dela.

Teste no dia seguinte: peça a tarefa em linguagem normal, sem colar a receita. Se o agente não puxou a skill, a linha de quando usar está vaga, ou o arquivo não está no lugar em que ele procura. Se puxou e pulou o passo 2, o passo 2 está escrito como desejo, não como ação. "Se o texto tiver nome completo, pare e peça a versão com papéis" funciona melhor do que "tenha cuidado com dados".

Não peça uma skill genial. Peça para transformar o parágrafo que você já cola numa receita com as cinco peças. Você edita. A primeira versão boa costuma nascer de um prompt que já funcionou.

Limites: vago, enorme, secreto, falho

Uma skill vaga é ignorada. "Use quando fizer sentido" e "sempre que houver texto" não são gatilhos. O agente compara o pedido com a descrição. Descrição larga compete com todas as outras e perde. Escreva o tipo de tarefa, o tipo de arquivo, o tipo de pedido.

Uma skill enorme é pulada. Receita de vinte páginas não cabe no que o agente consegue carregar de uma vez. Ele lê a descrição, estima o custo e, se o corpo for um manual, pula. Corte o que não é passo. Teoria e apêndice ficam fora. Se o método for longo de verdade, quebre em duas skills com gatilhos diferentes.

Segredo não pertence à receita. Token, senha, chave de API, cookie, código de dois fatores: nada disso entra no SKILL.md. A receita diz "peça para a pessoa autenticar" ou "use a ferramenta já ligada". MCP, quando existir, é o lugar do acesso, não o arquivo de método.

O agente ainda pode falhar os passos. Receita boa reduz improvisação. Não garante fato. Não impede alucinação. Você continua conferindo o resultado, principalmente se a saída for e-mail, post ou número que outra pessoa vai usar. Skill também não substitui permissão. Se o agente não pode ler a pasta, a receita descreve um trabalho que ele não consegue executar. Aí o problema é acesso (conta, permissão, MCP), não o texto da skill.

Skill que ninguém revisa apodrece. O time muda o formato da ata e o arquivo continua pedindo o formato antigo. Se o passo mudou na vida real, mude o arquivo.

O que fazer agora

Escolha uma tarefa que você já repetiu o parágrafo nesta semana. Só uma. Resumir a call de segunda, revisar o post, conferir a planilha de horas. Escreva as cinco peças (nome, quando, passos, feito, não fazer) num arquivo curto. Coloque onde o agente da casa procura skills.

Peça a tarefa em linguagem normal. Confira se os passos apareceram. Se não apareceram, feche a linha de quando usar. Se apareceram e o resultado ainda inventou fato, o passo de "só o que está no texto" precisa ficar mais duro, não mais educado.

Não monte um repositório de quinze skills no primeiro dia. Uma receita que o time usa na quinta vale mais que um catálogo que ninguém carrega.

O valor não é ter skill. É parar de reensinar o método toda vez que a conversa recomeça.