Skill não é template estático. É a unidade mínima de capacidade reutilizável de um agente de IA, e o conceito é o mesmo em todos os agent harnesses maduros, mesmo com nomes diferentes em cada produto. Claude chama de Skill. Gemini chama de Extension. Codex chama de Function. Cursor chama de Rule. A ideia é uma só. Pra empresa, skill bem desenhada é o que separa piloto que vira produto de piloto que vira slide.
O que é uma skill (definição multi-fornecedor)
Uma skill é um pacote pequeno e auto-contido que ensina o agente a fazer uma tarefa. O pacote típico tem três partes: instruções em linguagem natural sobre o que a skill faz e quando usar, exemplos concretos de input e output esperados, e às vezes ferramentas opcionais que a skill pode acionar (ler arquivo, chamar API, rodar comando). O formato preferido é markdown com frontmatter YAML, porque é legível por humano, versionável em git e parseável por máquina.
| Vendor | Nome | Formato | Onde mora |
|---|---|---|---|
| Anthropic | Claude Skills | .md com frontmatter | ~/.claude/skills/ ou repo |
| Gemini Extensions | JSON ou TOML | Configuração do CLI | |
| OpenAI | Function/Tool calling + custom GPTs | JSON Schema + instruções | Plataforma OpenAI |
| Cursor | Rules | .mdc (markdown com config) | .cursor/rules/ no projeto |
A semelhança não é coincidência. Os quatro produtos chegaram numa solução parecida porque o problema é o mesmo: o modelo precisa de contexto especializado pra tarefa específica, mas a janela de contexto é cara e finita. Carregar tudo o tempo todo é desperdício, então a skill vira a unidade de carga sob demanda. O agente lê uma lista resumida das skills disponíveis, decide qual ativar, carrega só aquela, executa, descarrega.
Anatomia de uma skill
Uma skill bem feita tem estrutura previsível. O frontmatter declara o nome da skill, o trigger (quando ativar) e os recursos que a skill precisa (ferramentas, arquivos auxiliares). O corpo descreve o procedimento em passos curtos, com exemplos pra cada decisão importante. Quando faz sentido, a skill aponta pra arquivos auxiliares no mesmo diretório, pra evitar que o corpo fique gigante.
Um exemplo genérico, sem cravar fornecedor:
---
name: revisar-pr
description: "Revisa PR de banco de dados, valida migrations, sugere índices."
trigger: "/revisar pr <numero>"
---
# Revisar PR
## Quando usar
Ative quando o usuário pedir revisão de PR que toca em migration ou query.
## Procedimento
1. Carregar diff do PR via gh.
2. Identificar arquivos de migration alterados.
3. Aplicar checklist em `checklist-migration.md` (anexo).
4. Sugerir índice se houver query nova com WHERE em coluna não indexada.
A skill acima tem ~10 linhas no corpo principal e referencia um arquivo auxiliar com checklist longo. O agente carrega só o que precisa e o checklist completo entra na janela de contexto só quando a skill ativa.
Skill, system prompt e rule não são a mesma coisa
Os três são instruções pro agente, mas têm escopo e custo de carga diferentes. Confundir os três gera arquitetura ruim.
O system prompt é fixo e carrega em toda chamada do modelo. Define identidade, voz, fronteiras éticas. É o que torna o agente "um agente", e não um genérico LLM. Custo: alto em tokens, mas pago uma vez por sessão.
A rule é uma instrução curta, geralmente de comportamento ("nunca commite sem rodar os testes"), que se aplica sempre que faz sentido. Custo baixo em tokens. Não traz ferramentas, só intenção.
A skill é um procedimento completo, com ferramentas anexas, que carrega só quando o trigger bate. Custo: pago só quando usado. Pode ser grande sem penalizar conversas curtas.
Decisão prática: se a instrução deve estar sempre presente, vai pra system prompt. Se é regra de comportamento que não exige ferramenta nova, vira rule. Se é procedimento com tooling, vira skill.
Skill é produto interno, não template descartável
A maioria das empresas trata skill como prompt-engineering: alguém escreve uma vez, joga no agente, e considera resolvido. Esse é o erro que separa skill saudável de skill que envenena o agente. Skill é produto interno. Tem dono, versão, eval e ciclo de vida.
Dono. Cada skill precisa de pessoa responsável por mantê-la viva. Sem dono, skill envelhece e o agente continua usando, o que produz resultado errado com aparência confiante. Pro Translator, gerenciar o catálogo de skills da empresa é responsabilidade tão concreta quanto gerenciar dashboard ou data product.
Versão. Skill em produção tem v1.2.0 no frontmatter, não "última versão". Mudança de comportamento exige bump explícito. Sem versão, não tem como rollback nem investigar regressão.
Eval. Skill precisa de bateria de teste binário (passou/falhou) com casos representativos. Sem eval, não tem como saber se a próxima edição quebrou algo que funcionava. A pesquisa "Memento-Skills" (Sohrab Rahimi, 2026) mostrou que skills com eval contínuo melhoram performance de agentes de 52% para 66% no benchmark GAIA, sem precisar trocar o modelo subjacente. O ganho não veio de inteligência maior; veio de skill melhor calibrada.
Ciclo de vida. Skill nasce experimental, vira beta, vira estável, vira deprecada. Skill deprecada deve continuar funcionando por janela explícita pra permitir migração. Sem ciclo, repositório vira museu de skill morta.
Skills evolutivas: o conceito de Memento-Skills
A pesquisa de Sohrab Rahimi propôs uma evolução do conceito tradicional. Em vez de skill estática que sempre executa o mesmo procedimento, Memento-Skill acumula contexto procedural a cada execução. O resultado bem-sucedido vira exemplo na próxima vez. O resultado ruim vira contraexemplo. A skill aprende com uso, sem retreinar o modelo.
A arquitetura tem dois componentes principais. Um RL router (roteador por aprendizado por reforço) decide qual skill ativar dado o contexto. E as skills mantêm memória estruturada do que funcionou e do que não funcionou. No benchmark GAIA, modelo de 4 bilhões de parâmetros equipado com Memento-Skills igualou performance de modelos significativamente maiores rodando sem skills evolutivas.
Pra empresa, isso muda a economia. Em vez de pagar pelo próximo modelo maior, você investe em catálogo de skill que melhora sozinho. A pergunta migra de "qual modelo escolho?" pra "como construo skill que evolui com uso?".
Como o decisor avalia skills numa proposta
Quatro perguntas separam catálogo saudável de coleção de prompt-pasta. Estas são complementares ao framework geral de avaliação de proposta de IA.
Quem é o dono? Se ninguém responde sem hesitar, a skill está órfã. Skill órfã é dívida técnica disfarçada de produto.
Tem eval? Se não tem bateria de teste binário rodando regularmente, qualquer mudança é apostar. E em produção, apostar é caro.
Tem rollback? Se a versão anterior não está acessível, a regressão é definitiva. Skill séria tem versão imutável publicada.
É portável? Se a skill só funciona num harness específico (Claude Code, Cursor, etc.) e não pode ser exportada pra outro, você está se trancando num vendor. Skill bem desenhada é portável; o que muda entre harnesses é o adapter, não a lógica.
O que vem depois
Continua a anatomia do agente:
- O que é agent harness — o ambiente onde a skill vive.
- O que são sub-agentes — sub-agente carrega skill específica pra tarefa delegada.
- Equipe de agentes: quando multi-agent vale e quando vira teatro — orquestração de agentes especializados por skill.