SkillsBench Testou 47 Mil Skills De Agentes E A Nota Média Foi 6,2 De 12

Há umas duas semanas fui procurar uma skill pronta para automatizar um fluxo de revisão de PR que meu time repete várias vezes por sprint. Não é nada exótico — checar convenção de commit, rodar um linter específico, comentar de um jeito padronizado. Abri um dos marketplaces, busquei o termo óbvio e caí numa dúzia de resultados com nome quase idêntico. Testei quatro antes de achar uma que fazia o que o SKILL.md prometia. As outras três não eram maliciosas nem perigosas — eram só rasas. Uma tinha instrução genérica demais para ser útil em qualquer projeto real. Outra parava de funcionar no segundo passo porque assumia uma estrutura de repositório que não é a mais comum. A terceira parecia ter sido gerada em cinco minutos e nunca revisada por ninguém.

Não é a primeira vez que isso acontece, e o incômodo não é o tempo perdido — é o padrão. O catálogo de skills cresceu de um jeito que qualquer um que acompanha o ecossistema percebe: mais opção, mais marketplace, mais gente publicando. O que não cresceu na mesma proporção, pela experiência de garimpar, foi a qualidade média do que está sendo publicado. E "qualidade" é palavra vaga o suficiente para eu desconfiar da minha própria impressão — talvez eu estivesse só com azar, ou procurando errado.

Foi por isso que um estudo que andou circulando nas últimas semanas me chamou atenção de um jeito diferente dos anúncios de lançamento que normalmente cobrem este espaço. O SkillsBench, construído por pesquisadores de Stanford, CMU, Berkeley, Oxford e da organização BenchFlow, não testou se o formato SKILL.md funciona ou se um agente consegue carregar uma skill — isso já está resolvido. Testou se as skills de fato publicadas, em massa, ajudam o agente a fazer melhor o trabalho. A resposta, medida em nota de qualidade sobre 47.150 skills públicas, foi 6,2 de 12. Pouco mais da metade do possível.

Este post cobre como o SkillsBench foi construído, o que a nota de 6,2 revela na prática sobre o catálogo que qualquer um de nós usa hoje, o efeito concreto de skills curadas sobre a taxa de sucesso do agente, por que esse é um problema diferente do risco de segurança que já tratei em um post anterior sobre marketplaces de skills, e o que isso muda em como avaliar skill antes de instalar.

---

O Que É O SkillsBench E Como Foi Construído

O SkillsBench parte de uma pergunta simples de formular e difícil de responder direito: quando um agente de codificação tem acesso a uma skill, o resultado da tarefa melhora, piora ou não muda nada? Para responder isso de forma sistemática, os pesquisadores desenharam um benchmark com 84 tarefas espalhadas por 11 domínios diferentes — amplitude que evita que a conclusão fique presa a um nicho só, como código de backend ou automação de dados.

A parte que dá peso estatístico ao resultado é o volume de execuções avaliadas: 7.308 trajetórias de agente, cada uma representando uma execução completa de ponta a ponta de uma tarefa, com ou sem skill disponível, e com 7 configurações diferentes de combinação entre agente e modelo. Rodar a mesma tarefa repetidas vezes com variações de setup separa o que é efeito real da skill do que é ruído — um agente pode ir bem numa tarefa por acaso, mas um padrão que se repete em sete configurações diferentes já é outra categoria de evidência.

O desenho do benchmark é o oposto de "peguei uma skill, rodei um teste manual e gostei do resultado", que é mais ou menos o rigor que a maior parte de nós aplica ao instalar algo achado num marketplace. Nenhum dev tem tempo de rodar sete configurações e milhares de trajetórias antes de instalar uma skill para automatizar revisão de PR — e é exatamente por isso que um benchmark acadêmico com esse volume de dados tem valor: testa em escala o que ninguém consegue testar sozinho.

O outro pilar do trabalho, e o que interessa mais diretamente a quem instala skill de terceiro no dia a dia, foi a análise do catálogo público existente — não só das 84 tarefas controladas do benchmark, mas de uma amostra ampla do que está de fato publicado e disponível para instalação. Foram 47.150 skills avaliadas quanto à qualidade, com uma métrica que atribui nota de 0 a 12 considerando completude das instruções, clareza da descrição, consistência entre o que o SKILL.md promete e o que entrega, e ausência de generalidade vazia — instrução tão genérica que não ajuda o agente a fazer nada específico. O relatório da Agentman que resume esses achados descreve essa nota como medida direta de utilidade prática, não de segurança nem de popularidade.

---

A Nota Média De 6,2 E O Que Ela Significa Na Prática

Uma nota média de 6,2 numa escala de 0 a 12 não é catastrófica no sentido de "a maioria é lixo perigoso" — é pior no sentido mais chato de entender: a maioria é medíocre. Nem terrível a ponto de ser óbvio que algo está errado, nem boa o suficiente para realmente ajudar. É o tipo de nota que passa despercebida numa instalação rápida, porque a skill não quebra, não trava, não faz nada visivelmente errado. Ela só não entrega o ganho que o nome e a descrição prometem.

Vale colocar isso ao lado do que qualquer um de nós já sentiu na prática, incluindo o episódio que abriu este post: skill genérica demais para um contexto específico, skill cujo SKILL.md descreve um fluxo que não bate com o código dentro da pasta, skill publicada rápido demais para capturar audiência de um termo em alta, sem o cuidado de testar em mais de um cenário. Nenhuma dessas categorias é maliciosa nem dispara alarme de segurança. Ainda assim, cada uma é tempo perdido de quem confiou na skill para acelerar o trabalho.

Um cenário hipotético ajuda a tornar isso concreto. Imagine um time que adota uma skill de terceiro para padronizar a geração de changelog a partir de commits — tarefa comum, com dezenas de opções em qualquer marketplace. Escolhem uma com contador de instalação alto e nome que bate exatamente com a busca. Funciona nas primeiras duas semanas, mas passa a gerar entradas cada vez mais genéricas conforme o repositório cresce, porque o SKILL.md nunca detalhava como lidar com commits que tocam múltiplos módulos — cenário que provavelmente nunca apareceu no teste original de quem publicou. Ninguém percebe de imediato porque o changelog continua sendo gerado, só que cada vez menos útil. Não há incidente, não há exfiltração de dado, nada que um scanner de segurança pegasse. Só qualidade caindo silenciosamente abaixo do necessário.

É esse tipo de situação, multiplicado por milhares de skills e times, que a nota de 6,2 tenta capturar de forma agregada. O relatório da Agentman é direto: o ecossistema de skills é real e cresce rápido, mas de forma desigual — a distribuição, publicar e instalar skill em qualquer agente compatível, já está essencialmente resolvida. Qualidade e segurança, não. São problemas distintos crescendo em ritmos diferentes, e o catálogo público reflete essa assimetria: fácil de publicar, difícil de garantir que vale a pena instalar.

---

O Efeito De Skills Curadas: 16,2 Pontos Percentuais, Até 51,9 Em Saúde

A parte mais acionável do SkillsBench não é a nota média isolada — é o que acontece quando se compara skills curadas contra o resto do catálogo. Por "curada" o estudo entende skill que passou por revisão humana e organização deliberada, em oposição a skill gerada automaticamente ou publicada sem qualquer processo de checagem antes de ir ao ar. Medido através das mesmas 7.308 trajetórias e das mesmas 7 configurações de agente e modelo usadas no restante do benchmark, o ganho médio de taxa de sucesso do agente ao usar uma skill curada em vez de uma não curada foi de 16,2 pontos percentuais.

Dezesseis pontos percentuais é diferença grande o suficiente para mudar a decisão de qualquer tech lead avaliando se vale a pena investir tempo revisando skill antes de liberar para o time, em vez de deixar cada dev instalar o que achar no marketplace. Mas o número mais interessante do estudo não é a média — é a variação entre domínios. Em domínios regulados como saúde, o ganho de skills curadas chegou a 51,9 pontos percentuais. Uma diferença dessa magnitude sugere que, onde precisão e conformidade importam mais, a diferença entre uma skill escrita com cuidado e uma escrita às pressas deixa de ser detalhe de produtividade e passa a ser risco operacional direto.

A tabela abaixo resume os números centrais do estudo, na forma como aparecem nas fontes consultadas:

Métrica	Valor
Skills públicas avaliadas quanto à qualidade	47.150
Nota média de qualidade	6,2 de 12
Tarefas do benchmark	84, em 11 domínios
Trajetórias de agente avaliadas	7.308
Configurações de agente/modelo testadas	7
Ganho médio de sucesso com skill curada	+16,2 pontos percentuais
Ganho de sucesso com skill curada em saúde	+51,9 pontos percentuais

Faz sentido, quando se pensa no mecanismo, que domínios regulados amplifiquem tanto o efeito da curadoria. Uma skill mal escrita de automação de changelog produz um changelog ruim — chato, mas recuperável. Uma skill mal escrita que orienta um agente a lidar com dado clínico, terminologia regulatória ou fluxo de conformidade tem muito mais chance de o agente errar de um jeito que só aparece depois, quando já causou dano. A curadoria não está apenas melhorando a média — está reduzindo a variância nos casos em que a variância é mais cara.

Isso explica por que a diferença entre 16,2 pontos percentuais na média geral e 51,9 num domínio específico não é contraditória: curadoria tem retorno em qualquer lugar, mas o retorno marginal é proporcional ao custo do erro que ela previne. Num domínio de baixo risco, uma skill de 6,2 talvez funcione bem o suficiente na maior parte do tempo. Num domínio de alto risco, a mesma nota provavelmente já representa uma taxa de falha inaceitável.

---

Por Que Isso É Diferente Do Problema De Segurança Que Já Tratei

Vale ser explícito aqui, porque os dois assuntos se parecem à primeira vista e são coisas distintas. Em agosto escrevi sobre o risco de segurança nos marketplaces de skills — supply chain, skill maliciosa disfarçada de skill legítima, contador de instalação inflável, exfiltração de credencial embutida num bloco de shell com aparência inocente. Aquele post tratava de uma pergunta binária e adversarial: essa skill está tentando me prejudicar de propósito?

O SkillsBench não está fazendo essa pergunta. Está perguntando algo mais chato e, para a maioria dos times, mais frequente: essa skill, mesmo sendo completamente honesta e sem intenção maliciosa, é boa o suficiente para ajudar de verdade? Uma skill pode passar em qualquer scanner de segurança, não ter uma linha suspeita, nenhuma requisição de rede não autorizada, e ainda assim ter nota 3 de 12 porque a descrição é vaga, o corpo do SKILL.md não cobre casos comuns, e o autor nunca testou fora do cenário que motivou a publicação.

A distinção importa porque as defesas são diferentes. Contra skill maliciosa, o checklist que descrevi naquele post inclui ler o repositório de origem, desconfiar de contador de instalação, isolar em sandbox — medidas clássicas, emprestadas de como qualquer time trata dependência de terceiro num pipeline de software. Contra skill de baixa qualidade, sandbox não ajuda em nada: ela roda exatamente como devia, sem comprometer nada, e ainda assim entrega resultado ruim porque foi mal escrita. Não existe scanner de malware que detecte instrução vaga ou cobertura incompleta de caso de uso. Isso exige um tipo diferente de julgamento — mais próximo de revisão de código do que de auditoria de segurança.

Os dois problemas compartilham uma causa raiz, a mesma que apontei quando escrevi sobre o formato SKILL.md como padrão aberto de portabilidade entre agentes: a simplicidade que tornou o formato fácil de adotar — publicado em agentskills.io, funcionando sem modificação em Claude Code, Codex CLI, Cursor, Gemini CLI e outros agentes compatíveis — é a mesma simplicidade que tornou fácil publicar qualquer coisa. Uma skill escrita para um agente roda em outro sem esforço de adaptação, ótimo para quem escreve bem e péssimo como filtro de qualidade, porque não existe barreira técnica impedindo alguém de publicar um SKILL.md de três linhas genéricas e chamar de skill completa. O mesmo mecanismo que resolveu a distribuição é o que deixou segurança e qualidade sem controle.

Dito isso, tratar os dois problemas como a mesma coisa levaria a soluções erradas. Um time que só audita segurança — lê o SKILL.md procurando comando de shell suspeito, verifica chamada de rede escondida, roda em ambiente isolado — pode aprovar sem hesitar uma skill perfeitamente segura e completamente inútil, porque a auditoria de segurança nunca foi desenhada para medir isso. E um time que só mede qualidade pode instalar uma skill muito bem escrita que ainda assim contém um vetor de exfiltração de credencial disfarçado, como os exemplos documentados no post anterior. Segurança e qualidade são eixos ortogonais, e o SkillsBench deixa isso mais visível ao medir apenas um deles, sem se pretender substituto do outro.

---

Como Escolher E Avaliar Skills Antes De Instalar

A conclusão mais direta do efeito de 16,2 pontos percentuais é que curadoria não é luxo opcional — é a variável que mais move o resultado prático de usar skill de terceiro. E curadoria, no sentido que o SkillsBench usa, não é sinônimo de "vem de fonte oficial". É revisão humana deliberada antes da publicação ou da adoção, o que significa que essa responsabilidade pode e deveria ser assumida pelo time que instala, não só esperada de quem publica no marketplace.

Isso muda de forma prática o que significa "avaliar uma skill" antes de trazer para o ambiente do time. Não basta mais checar se ela é segura — checklist que já vale a pena manter, como venho reforçando desde o post sobre marketplaces. É preciso também avaliar se ela é boa, e isso exige perguntas diferentes: a descrição no frontmatter é específica o suficiente para o agente saber quando de fato usar a skill, ou é genérica a ponto de disparar em qualquer contexto parecido? O corpo do SKILL.md cobre variações razoáveis do caso de uso, ou só o cenário exato que o autor testou uma vez? Existe algum sinal de que a skill foi testada em mais de um projeto, ou tudo indica que foi escrita e publicada no mesmo dia sem retorno de uso real?

Um cenário hipotético ilustra como isso funcionaria na prática. Imagine um tech lead decidindo se aprova a adoção de uma skill de geração de testes para o time. Em vez de rodar uma vez e aprovar se o resultado parecer razoável, ele pede que dois devs testem a skill em três repositórios diferentes ao longo de uma semana, com estruturas de código distintas, e registrem onde ela falhou. Não é o rigor de um benchmark acadêmico com milhares de trajetórias, mas é uma versão em miniatura do mesmo princípio: testar em mais de um cenário, com registro do que não funcionou. É o tipo de prática que já defendi ao escrever sobre manter instruções compartilhadas curadas e revisadas para os agentes do time em vez de deixar cada dev acumular sua própria pilha de configuração paralela — o princípio se estende de instrução geral para skill específica, porque o problema de fundo é o mesmo: conteúdo que entra no contexto do agente sem revisão tende, estatisticamente, a ser pior.

Vale também reconsiderar o peso dado a sinais superficiais de popularidade. Contador de instalação alto e nome que bate exatamente com o termo de busca dizem algo sobre distribuição, não sobre qualidade — o próprio relatório da Agentman separa essas duas dimensões do ecossistema. Uma biblioteca de skills curadas e mantidas por um time, ainda que menor em número de opções, tende a superar um marketplace amplo e não revisado justamente porque cada entrada já passou pelo filtro que o SkillsBench mediu ter tanto impacto. Isso sugere um investimento concreto: em vez de deixar cada dev garimpar skill individualmente, times maduros provavelmente ganham mais mantendo um catálogo interno pequeno e revisado, mesmo que isso signifique menos variedade.

Nada disso elimina o trabalho. Curadoria dá certo, mas dá trabalho — alguém precisa ler, testar em mais de um cenário, documentar o que não funcionou, e repetir o processo quando a skill for atualizada. O ganho de 16,2 pontos percentuais não é gratuito; é o retorno de um investimento de revisão que a maioria dos times, pela nota média de 6,2, simplesmente não está fazendo hoje.

---

Conclusão

Volto ao garimpo que abriu este post. Não testei as 47 mil skills que o SkillsBench avaliou, nem pretendo generalizar quatro tentativas de busca num marketplace como prova de nada — mas a coincidência entre a experiência pequena e o dado grande me deixou mais confortável para admitir o que já suspeitava: o catálogo de skills não ficou ruim por acidente, ficou ruim porque o mecanismo que o fez crescer tão rápido nunca teve um filtro de qualidade embutido. Formato simples, sem revisão obrigatória, sem barreira de entrada — ótimo para adoção, péssimo como controle.

O que o SkillsBench contribui de mais valioso não é confirmar que existe skill ruim por aí, o que qualquer um que já usou um marketplace já desconfiava. É dar número a isso — 6,2 de 12 como nota média, 16,2 pontos percentuais como o custo de não curar, até 51,9 em domínios onde o erro pesa mais. São números difíceis de contestar e fáceis de esquecer no dia a dia, quando a pressa de resolver uma tarefa fala mais alto do que o hábito de revisar antes de instalar.

Não tenho resposta fechada sobre qual mecanismo vai resolver isso em escala — selo de qualidade equivalente ao que já se discute para segurança, consolidação natural em torno de poucas bibliotecas curadas, ou o ecossistema simplesmente seguindo desigual, cabendo a cada time decidir quanto trabalho de revisão está disposto a fazer. O que fica difícil de ignorar é que tratar skill como configuração pronta para uso, em vez de algo que precisa ser lido e revisado antes de entrar em produção, tem custo mensurável. E esse custo não aparece como incidente de segurança — aparece, de forma mais silenciosa, como agente que faz o trabalho de qualquer jeito, só que pior do que deveria.

Fontes:

• Emergent Mind — SkillsBench (paper summary)
• SkillsBench — Citations
• Agentman Blog — Agent Skills Ecosystem Report 2026
• arXiv — SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks