Vou ser direto: há um número enterrado em um paper recente do Microsoft Research que deveria mudar como seu time constrói skills de agentes — e a maioria da cobertura está tratando como uma curiosidade acadêmica em vez da mudança operacional que realmente é.
Aqui está o número. Sobre GPT-5.5, um skill document otimizado por SkillOpt adicionou +19.1 pontos rodando dentro do harness do Claude Code, e +24.8 pontos dentro do Codex — comparado a rodar o mesmo modelo congelado sem skill alguma. Mesmo modelo. Mesmo harness. Mesmo custo de inferência. A única coisa que mudou foi o arquivo Markdown que diz ao agente como trabalhar.
Se agora você mantém um CLAUDE.md, um AGENTS.md, ou qualquer skill.md à mão, essa é a parte para ficar pensando um tempo.
A premissa: seu skill doc é estado treináve, não documentação
Durante dois anos, toda a conversa de IA e código girou em torno dos modelos. GPT-5.5 vs Opus 4.8. Qual escreve melhor código, qual alucina menos, qual sustenta mais contexto. SkillOpt vem de um ângulo completamente diferente: deixa o modelo congelado e trata o skill document como a coisa que você otimiza.
O framing está deliberadamente emprestado do deep learning. Você tem epochs, minibatches, uma learning rate e validation gates — só que tudo isso se aplica a um arquivo Markdown em vez dos pesos do modelo. A skill é “estado externo” de um agente congelado, e você a treina da mesma forma que treinaria qualquer outra coisa: você roda, pontua, ajusta, e fica com o que melhora.
Isso não é prompt engineering com passos extras. A disciplina é justamente o ponto.
Como o loop funciona na realidade
Quatro etapas, repetidas:
Rollout. O modelo target congelado roda as tarefas usando a skill atual e registra trajectories pontuadas — cada tool call, geração de código, output do compilador e resultado do verifier. Pense nisso como o forward pass.
Reflect. Um modelo optimizer separado (um frontier model, diferente daquele que faz o trabalho) analisa batches de sucessos e fracassos separadamente, procurando por procedimentos reutilizáveis. Este é o backward pass em nível de linguagem.
Edit. O optimizer propõe operações limitadas de add / delete / replace no skill document. E aqui está a parte mais engenhosa: há um edit budget que funciona como uma learning rate textual. Limita quanto o doc pode mudar em um único passo. Sem isso, o self-editing fica errático — o agente sobrescreve regras que estavam funcionando e perde seu lugar. O budget é o que mantém a evolução gradual e reproduzível em vez de ser uma moeda ao ar.
Gate. Um edit candidato é aceito apenas se melhora estritamente um validation score held-out. Se não melhora, é rejeitado — e os edits rejeitados se tornam feedback negativo para que o optimizer não se meta no mesmo beco sem saída novamente. Isso transforma a reflexão em otimização do tipo propose-and-test, em vez da abordagem incondicional de “deixa o agente reescrever suas próprias instruções” que tende a divergir.
O modelo em si nunca muda. Você termina com um artifact best_skill.md deployável que tem zero custo extra de inferência.
Por que o resultado cross-harness é o destaque
O varredura de benchmarks é ampla: 7 modelos target, 6 benchmarks, dois harnesses de execução reais — Codex e Claude Code. SkillOpt foi o melhor ou empatou no melhor nas 52 células (modelo × benchmark × harness). Venceu as skills escritas à mão, e venceu as abordagens automatizadas anteriores (TextGrad, GEPA, EvoSkill).
Duas coisas importam mais do que os scores crus para qualquer um que gerencie um time:
Primeiro, funciona dentro dos harnesses que você já usa. Não é um benchmark que só vive em um notebook de laboratório. Os números de Codex e Claude Code dizem que a skill otimizada se transfere para as ferramentas concretas que seus devs abrem cada manhã.
Segundo, as skills aprendidas se transferem entre modelos e harnesses. Uma skill treinada contra um setup carrega ganhos para outros. Para um time que está padronizando workflows agênticos, essa é a diferença entre manter um único artifact treinado e reescrever instruções para cada ferramenta e cada bump de modelo.
Os avisos honestos — porque isso não é um plugin
Aqui é onde eu frearia um pouco antes de alguém do seu time clonar o repo esperando um comando /install-skill.
SkillOpt é um framework de pesquisa, com licença MIT e público em github.com/microsoft/SkillOpt (~3.2K stars e subindo). Não é um plugin de um clique para Claude Code. Para rodar você precisa de uma API de LLM ou um endpoint do Azure OpenAI, um modelo optimizer separado, e cómputo real para os batches de rollout. Os datasets dos benchmarks não vêm inclusos — você traz seus próprios dados, formatados segundo o que cada environment espera. E os ganhos, embora consistentes, variam muito por benchmark: algumas células mostram um dígito, outras saltam 50+ pontos. Seu domínio decide onde você cai.
Também há uma armadilha de nomes que vale a pena marcar: andam circulando repos de “skill factory” não relacionados que fazem bridge entre Claude Code e Codex. Esses não são este. SkillOpt é o optimizer do Microsoft Research, e a distinção importa quando você está procurando.
O que eu faria com isso
Não espere pelo plugin polido. A ideia é o ativo aqui, e você pode adotá-la antes do tooling chegar.
Se seu time tem uma tarefa agêntica recorrente — um ciclo rígido plan→dev→test→deploy, um fluxo de review documentado, qualquer coisa que você já tentou codificar em uma skill escrita à mão — esse é um candidato. Rode seu agente congelado contra um set de specs representativas, pontue as trajectories com honestidade, e deixe que um modelo mais forte proponha edits limitados ao doc, gated segundo se realmente melhoram os resultados. Mesmo uma versão manual desse loop vence o status quo, que para a maioria dos times é: escrever a skill uma vez, esperar que generalize, e nunca mais tocar nela.
O skill.md escrito à mão sempre foi um placeholder. SkillOpt é o argumento do que o substitui.