fundamentos·Fabricio Telles

Skill Hell: Como Sair do Inferno das Skills de Agentes IA

Skill hell é o novo framework hell. Aprenda a identificar skills ruins, aplicar critérios de qualidade e escapar do ciclo de acumulação sem resultado.

TL;DR — Existem mais de 90 mil skills publicadas em marketplaces. A nota média de qualidade é 6.2 de 12. Skills geradas por IA não melhoram performance de agentes — e em 16 de 84 tarefas testadas, elas pioram o resultado. Este artigo explica o que é skill hell, como reconhecer que você caiu nele, e o que separa uma skill útil de uma skill que só engorda o contexto do seu agente.


Lembra do framework hell? Aquela época — que na real nunca acabou — em que a cada dez minutos alguém lançava um framework JavaScript novo e você sentia a obrigação moral de avaliar todos? Matt Pocock, na palestra Building Great Agent Skills: The Missing Manual na AI Engineer Conference, cunhou o termo que define o momento atual: skill hell.

A analogia é perfeita. Troca “framework” por “skill” e a dinâmica é a mesma: proliferação sem critério, FOMO coletivo, e a incapacidade de distinguir o que presta do que é ruído.

Só que com uma diferença cruel. Um framework ruim te custa tempo de migração. Uma skill ruim te custa resultado e tokens — sem que você perceba. Porque, diferente de um código que quebra o build, uma skill medíocre falha silenciosamente. O agente continua rodando, continua respondendo, mas o output é pior do que seria sem skill nenhuma.

O que raios é skill hell?

Skill hell é o estado em que você acumula dezenas de skills no seu agente sem critério de qualidade, sem testar se elas melhoram performance, e — principalmente — sem entender quando uma skill é melhor que nenhuma skill.

Os números são escabrosos:

  • 47.150 skills analisadas pelo SkillsBench em 2026, nota média de qualidade: 6.2/12
  • 90.368 skills publicadas em marketplaces gratuitos (dados de junho 2026)
  • 26.4% das skills não têm sequer uma descrição de roteamento (como o agente vai saber quando usá-la?)
  • 60%+ do conteúdo das skills é “non-actionable” — texto que não ajuda o agente a executar nada

Sabe o ClawHub? 44 mil skills. Uma auditoria independente pegou 1.024 delas e os resultados são, no mínimo, constrangedores. A Chrome Web Store levou uma década pra chegar nesse número de extensões — com um time de humanos e ML revisando cada submissão. O ecossistema de skills chegou lá em meses, sem revisão alguma.

Como você caiu no skill hell sem perceber?

É insidioso. Começa assim:

  1. Você descobre que seu agente de codificação aceita skills
  2. Instala cinco, dez skills de um marketplace porque “não custa nada”
  3. O agente fica mais lento (contexto maior, mais tokens processados)
  4. Você não mede se o output melhorou ou piorou
  5. Instala mais skills achando que vai compensar
  6. Repeat

Existe um post no Reddit com 328 upvotes que resume o sentimento: “Eu cobro mais dos clientes para NÃO construir um agente de IA.” O argumento? A maioria dos setups com agentes são over-engineering puro. Um script Python determinístico resolve 90% dos casos que as pessoas estão tentando resolver com agentes + skills + orquestração.

E aqui vai uma opinião que talvez incomode: a cultura de “instalar skills” virou a versão low-effort de engenharia de agentes. É o equivalente de copiar configuração de .vimrc do GitHub sem entender o que cada linha faz. Dá uma falsa sensação de sofisticação.

O que o SkillsBench revelou de brutal?

O paper SkillsBench é a melhor evidência empírica que temos. Testaram 7 configurações de modelo-harness em 7.308 trajetórias. Os achados:

Skills curadas por humanos → +16.2 pontos percentuais de pass rate em média. Em Healthcare, o ganho chega a +51.9pp. Em Manufacturing, +41.9pp.

Skills geradas por IA → ganho zero mensurável. Em vários cenários, performance pior que sem skill.

Relê esse parágrafo. O modelo não consegue escrever o conhecimento procedimental que ele mesmo se beneficia de consumir. A skill precisa vir de alguém que já fez a tarefa, errou, ajustou, e codificou o aprendizado numa instrução precisa.

Outro achado: skills focadas com 2-3 módulos superam documentação abrangente. A skill que tenta cobrir tudo não cobre nada. Tamanho não é qualidade.

E talvez o mais contraintuitivo: modelos menores COM boas skills podem empatar com modelos maiores SEM skills. Isso inverte a lógica de “preciso do modelo mais caro.” Às vezes você precisa da skill certa.

Skill hell não é só desperdício — é risco de segurança

Tá, até aqui falei de performance. Mas tem outro lado que pouca gente discute.

A OWASP publicou o Agentic Skills Top 10 — um framework de riscos de segurança específico para skills. A Lineaje, firma de segurança, encontrou que a skill maliciosa mediana nos marketplaces tinha 2.200 stars. A mais popular? 361 mil stars.

Uma skill de segurança da AIR, criada como prova de conceito, passou pelos scans de segurança do marketplace, foi promovida via Instagram Ads, e atingiu 26 mil agentes — incluindo contas corporativas. Isso em 2026.

Quando você instala uma skill de um marketplace sem curadoria, está dando a um markdown file escrito por um desconhecido acesso ao contexto, às ferramentas e — dependendo do setup — às credenciais do seu agente.

E sério, alguém auditou aquelas 44 mil skills do ClawHub?

Como escapar do skill hell?

Vamos ao que interessa. Três princípios e um checklist.

Princípio 1: Menos é drasticamente mais

A Forbes publicou uma frase que captura bem: “The antidote to agent sprawl is deceptively simple: Build skills, not agents.” Mas eu vou além: use poucas skills, e use as certas.

O estudo mostrou que skills focadas (2-3 módulos) superam skills abrangentes. Se sua skill tem mais de 500 linhas, provavelmente é um documento fantasiado de skill.

Princípio 2: Meça antes e depois

Se você não está medindo a performance do agente com e sem uma skill, você está no escuro. Qualquer skill que você adiciona precisa passar pelo mínimo: resolveu mais tarefas? O output ficou melhor? Ou só adicionou latência e custo?

O dado de 88% dos agents enterprise que não saem do piloto não é coincidência. É consequência de empilhar capacidades sem validar se elas funcionam em conjunto.

Princípio 3: Prefira skills de quem já errou

Skills curadas por humanos que já executaram a tarefa → +16pp. Skills geradas por IA ou escritas por quem nunca fez o trabalho → zero ou negativo.

A melhor skill que já vi tem três frases. É a grill-me do Matt Pocock: “Interview me relentlessly about every aspect of this plan until we reach a shared understanding.” Não tem nada sofisticado. Tem experiência codificada.

Checklist de qualidade para avaliar uma skill

Antes de instalar qualquer skill, passe por estes critérios:

#CritérioRed flag se ausente
1Descrição de roteamento claraAgente não saberá quando ativar
2Escopo restrito (faz UMA coisa)Vai conflitar com outras skills
3Instruções acionáveis (verbos, passos)Texto decorativo engorda contexto
4Lições aprendidas / gotchasSkill genérica, não veio de prática real
5Critérios de sucesso explícitosImpossível saber se funcionou
6Tamanho proporcional (2-3 módulos focados)Documentação disfarçada de skill
7Autoria verificávelRisco de segurança + qualidade duvidosa
8Testada em contexto realSkill teórica, nunca rodou de verdade

Se a skill falha em 3+ critérios dessa tabela, não instale. Sério. Seu agente vai performar melhor sem ela.

Como construir skills que não são lixo?

Se você escreve skills — seja pra você, pra seu time, ou pra publicar — o mindset muda:

Comece pelo erro, não pela feature. A melhor matéria-prima pra uma skill é aquele momento em que você corrigiu o agente pela terceira vez no mesmo ponto. Isso é conhecimento procedimental. Codifique isso.

Escreva como se fosse um checklist de cirurgião. Curto, sequencial, sem ambiguidade. Se você precisa de “contexto” e “filosofia” na sua skill, está escrevendo um artigo, não uma instrução.

Inclua anti-patterns. “NÃO faça X” é tão valioso quanto “faça Y.” O agente precisa saber onde estão os buracos.

Teste com e sem. Rode a mesma tarefa com a skill ativa e sem ela. Se o resultado não melhora mensuravelmente, a skill não justifica existir.

Uma tangente: sabe o que mais me incomoda nessa discussão? A narrativa de que “skills são o futuro” sem ninguém mencionar que curadoria é o gargalo. É fácil gerar 90 mil skills. É difícil ter 500 que realmente funcionam. O negócio não é produção de skills — é filtragem.

O ecossistema de ferramentas

Se você está começando a levar skills a sério, vale conhecer o cenário:

Se você quer construir skills profissionalmente ou encontrar skills que foram testadas de verdade, o skilldev.pro resolve o problema central: separar as skills que funcionam das 47 mil que só ocupam espaço.

E o OWASP nessa história?

O OWASP Agentic Skills Top 10 documenta os 10 riscos mais críticos de segurança em skills. Se você instala skills de terceiros, deveria ler. Os riscos cobrem desde prompt injection via skill até exfiltração de credenciais — e valem para todos os ecossistemas (OpenClaw, Claude Code, Cursor, VS Code).

A mensagem é clara: skill não é plugin inocente. É código que executa no contexto privilegiado do seu agente.

O que fazer agora?

Três ações imediatas:

  1. Audite suas skills instaladas. Aplique o checklist acima em cada uma. Desative as que falham. Meça se algo piora (provavelmente não vai).

  2. Meça antes de adicionar. Crie um mini-benchmark: 5 tarefas que você faz repetidamente. Rode com skills, rode sem. Compare.

  3. Escreva UMA skill boa em vez de instalar dez medianas. Pegue o procedimento que você mais repete, onde o agente mais erra, e codifique. Siga o checklist. Teste. Itere.


Skill hell é real, é caro, e — como framework hell — não vai embora sozinho. A diferença é que agora temos dados. SkillsBench mostrou que qualidade supera quantidade por uma margem absurda. Que a curadoria humana não tem substituto. E que menos skills bem escolhidas vencem mais skills empilhadas.

A indústria vai amadurecer. Vai ter linting de skills, benchmarks públicos, certificações. Mas até lá, o filtro é você.

E se você quer aprofundar, temos guias específicos sobre como escrever skills eficazes, o formato SKILL.md explicado e como usar regras de projeto para dar contexto sem depender de skills externas.

Boa sorte no inferno. A saída existe — e não tem 47 mil opções.