Elton José logo
Elton José
SKILL.md

O Mercado De Skills Verticais: Por Que Nicho Vale Mais Que Skill Genérica No Catálogo

O Mercado De Skills Verticais: Por Que Nicho Vale Mais Que Skill Genérica No Catálogo
0 visualizações
16 minutos de leitura
#SKILL.md

O Mercado De Skills Verticais: Por Que Nicho Vale Mais Que Skill Genérica No Catálogo

Semana passada baixei, meio de curiosidade, duas skills de repositórios diferentes para comparar lado a lado — não foi teste extenso nem benchmark, só uma olhada rápida antes de decidir o que valia instalar. Uma prometia "ajudar com documentação", em termos bem largos, aplicável a qualquer linguagem e qualquer contexto. A outra era estreita o bastante para incomodar à primeira vista: gerava changelog seguindo uma convenção específica de versionamento semântico para bibliotecas Python publicadas no PyPI, com exemplos de entrada e saída já embutidos no arquivo. A diferença de utilidade prática entre as duas, só de ler a instrução, já dava para sentir — a genérica pedia para o modelo resolver metade da ambiguidade sozinho, a de nicho já tinha resolvido essa ambiguidade antes de eu abrir o editor.

Essa observação pequena ficou martelando porque ela aponta para uma pergunta maior que o mercado de agent skills está respondendo com dado, não com opinião. Se uma skill de nicho bem construída reduz tanto trabalho de interpretação para o agente, isso deveria aparecer em número de taxa de sucesso — e, uma vez que aparece em número, deveria aparecer também em disposição de pagar. Não é intuição solta: é exatamente o que o primeiro benchmark independente e revisado por pares sobre agent skills, o SkillsBench, mediu formalmente ao longo de 2026.

Este blog já tratou duas vezes de assuntos vizinhos a este nos últimos dois meses, e vale marcar a diferença logo de saída para não confundir os três. Em julho, escrevi sobre por que compor agentes especializados costuma vencer o agente generalista — aquele post era sobre arquitetura, sobre como dividir responsabilidade entre múltiplos agentes numa mesma tarefa. Semana passada, tratei da Claudeforce, a parceria entre Salesforce e Anthropic, como estudo de caso de integração de modelo dentro de CRM. Este post aqui é sobre uma terceira coisa, adjacente às duas mas distinta: o mercado. Por que uma skill construída para um nicho específico — jurídico, saúde, vendas, compliance regulatório — vale objetivamente mais, em desempenho mensurável e em preço que alguém topa pagar, do que uma skill genérica escrita em uma tarde para caber em qualquer caso de uso.

Vou passar pelo dado central do SkillsBench e pelo mecanismo que explica por que ele existe, pela diferença explícita entre este ângulo e o da composição de agentes, pelo estudo de caso da Claudeforce como exemplo do padrão em produção, pelo que isso significa para quem constrói e vende skill como produto, e pelo que muda para quem está do lado de comprar e adotar.


O Número Que Não Dá Para Ignorar: 16,2 Pontos Percentuais Em Média

O SkillsBench foi construído por pesquisadores de Stanford, CMU, Berkeley, Oxford e da BenchFlow, e é hoje a referência mais citada para medir, de forma controlada, o quanto uma skill muda o comportamento de um agente. A versão citada pelo relatório de ecossistema da Agentman testou 84 tarefas em 11 domínios profissionais, rodando 7.308 trajetórias em sete configurações de agente e modelo — volume grande o bastante para o resultado não depender de um modelo ter tido um dia bom.

O resultado central é direto: skills curadas e específicas de domínio elevam a taxa de sucesso média do agente em 16,2 pontos percentuais, comparado ao mesmo agente operando sem skill nenhuma. Esse número sozinho já seria notável. O que torna o dado mais interessante para quem pensa em mercado é a variação entre domínios — o ganho não é uniforme, e a extremidade mais alta aparece exatamente onde a expertise de domínio é mais difícil de improvisar. Em saúde, domínio fortemente regulado e cheio de convenção específica que um modelo generalista simplesmente não tem como inferir sozinho, o ganho medido chegou a 51,9 pontos percentuais — o maior de qualquer domínio testado.

RecorteGanho de taxa de sucesso
Média geral (skills curadas vs. sem skill)+16,2 pontos percentuais
Saúde (domínio regulado, maior ganho medido)+51,9 pontos percentuais
Combinação de 2-3 skills focadas por tarefa+18,6 pontos percentuais
Skill monolítica ("faz tudo" num único documento)-2,9 pontos percentuais

A última linha da tabela é tão relevante quanto a primeira. O mesmo benchmark mostrou que empilhar tudo numa única skill genérica e extensa não é neutro — é pior do que não ter skill nenhuma, porque o agente perde tempo e contexto navegando instrução irrelevante para a tarefa que tem na frente. Isso reforça, com número, algo que a intuição de qualquer tech lead já desconfiava: uma skill ampla demais para servir a tudo acaba não servindo bem a nada específico.

Vale registrar a outra metade incômoda do relatório, porque ela é parte do argumento comercial deste post. A mesma pesquisa analisou 47.150 skills públicas e encontrou pontuação média de qualidade de apenas 6,2 em escala de 12 — e só usou, nos testes de desempenho, as skills do quartil superior, com nota 9 ou acima. Catálogo grande não é sinônimo de catálogo bom: distribuição é abundante, qualidade curada é escassa, e é essa escassez que dá valor comercial a quem constrói bem.


Por Que Conhecimento De Domínio Embutido Muda O Resultado

O mecanismo por trás desse número não é misterioso, mas vale explicar porque é ele que sustenta o argumento comercial do resto do post. Toda tarefa que um agente recebe carrega ambiguidade — convenção de nomenclatura que a empresa usa, ordem em que passos devem acontecer, exceção que a regra geral não cobre, jargão específico do setor que muda o sentido de uma frase aparentemente simples. Um agente sem skill, ou com uma skill genérica, precisa resolver essa ambiguidade por conta própria, a cada execução, usando só o que consegue inferir do prompt e do conhecimento geral do modelo.

Uma skill de nicho bem construída faz um trabalho diferente: ela transporta para dentro do contexto do agente decisões que já foram tomadas antes, por alguém que entende o domínio. Não é "ajude com relatório financeiro" — é "gere a demonstração seguindo o plano de contas específico que esta empresa usa, com estas três exceções de classificação que aparecem em toda auditoria". A ambiguidade que sobra para o agente resolver sozinho cai drasticamente, porque a parte difícil — o conhecimento tácito de como aquele domínio realmente funciona — já veio embutida na instrução.

É por isso que o ganho é maior nos domínios mais regulados. Saúde, jurídico e finanças têm convenção documentada, terminologia precisa e consequência real para erro de interpretação — contexto em que um modelo generalista, por mais capaz que seja em raciocínio abstrato, tem menos chance de acertar sozinho. Engenharia de software, em comparação, é domínio onde o modelo teve volume gigantesco de dado de treinamento público para aprender convenção por conta própria, então o ganho marginal de uma skill ali tende a ser mais moderado — não porque skill não ajude, mas porque a lacuna que ela precisa preencher é menor.

Essa lógica também explica por que a skill monolítica performa pior, como mostrou a linha negativa da tabela anterior. Quando uma única skill tenta cobrir domínio inteiro em vez de tarefa específica, ela reintroduz exatamente o tipo de ambiguidade que a especialização deveria eliminar — o agente precisa decidir, dentro do próprio documento de instrução, qual trecho se aplica à situação atual, tarefa que se parece perigosamente com a ambiguidade original que a skill deveria ter resolvido. Foco estreito não é limitação da skill de nicho: é o mecanismo que faz ela funcionar.


Isso Não É Sobre Compor Agentes — É Sobre O Valor Comercial Da Skill Em Si

Vale ser explícito aqui, porque os dois posts têm superfície parecida e tratam de coisa diferente. O post de julho sobre composição de agentes especializados versus generalista discutia uma decisão de arquitetura: dado um problema grande, você resolve com um agente único fazendo tudo, ou com múltiplos agentes especializados coordenados por uma camada de orquestração? A resposta daquele post apontava para composição, com o case da Fountain como evidência — mas o argumento inteiro girava em torno de como dividir responsabilidade entre atores de IA dentro do seu próprio sistema.

Este post não é sobre quantos agentes você usa nem sobre como eles se coordenam. É sobre uma pergunta anterior e mais comercial: dado que você (ou seu fornecedor) vai usar uma skill — seja num agente único, seja numa arquitetura composta — essa skill em si vale mais quando é construída para um nicho estreito do que quando é escrita para servir a qualquer caso de uso. Você pode ter um único agente generalista rodando uma skill vertical excelente, ou uma arquitetura de dez agentes especializados rodando skills genéricas medíocres. O ganho de 16,2 pontos percentuais mostrado pelo SkillsBench não depende de quantos agentes estão orquestrando a tarefa — depende da qualidade e da especificidade de domínio da skill que cada agente carrega.

Essa distinção importa porque as duas decisões acontecem em momentos diferentes do ciclo de um produto de IA. Composição é decisão de arquitetura, tomada por quem constrói o sistema. Especificidade de skill é decisão de mercado, tomada por quem escolhe o que instalar ou o que construir para vender. São eixos ortogonais: dá para errar a composição e acertar a skill, ou acertar a composição e povoar cada agente com skill genérica de baixa qualidade — que, como mostrou a linha negativa da tabela anterior, performa pior do que a versão sem skill nenhuma.


O Estudo De Caso Da Claudeforce: 37 Skills, Nenhuma Genérica

O exemplo mais concreto desse padrão apareceu neste mesmo blog na semana passada, ao tratar da parceria entre Salesforce e Anthropic batizada de Claudeforce. Vale reler aquele anúncio sob a lente deste post, porque ele funciona quase como ilustração didática do argumento de mercado que o SkillsBench sustenta com número.

O núcleo do produto anunciado, o plugin "Salesforce in Claude", vem com 37 skills construídas especificamente para vendedores. Segundo a cobertura do lançamento, a Salesforce descreve essas skills como baseadas em 27 anos de experiência da empresa desenhando processo comercial. Nenhuma delas é genérica no sentido de "ajude com vendas" — cada uma resolve uma tarefa de nicho reconhecível por qualquer profissional da área: preparação de reunião, revisão de saúde de negociação (deal health, no jargão do setor) e revisão de pipeline, entre outras. É a diferença entre uma skill que diz "ajude a vender mais" e uma que diz "verifique se o contato-chave desta negociação ficou sem resposta além do tempo médio do estágio, e sinalize antes da reunião".

Colocando isso ao lado do dado do SkillsBench, a lógica comercial da Claudeforce fica mais legível. Genérico teria efeito marginal pequeno sobre desempenho e, principalmente, não é defensável comercialmente: qualquer concorrente com acesso ao mesmo modelo replica uma skill de "ajude a escrever e-mail de vendas" numa tarde. O que a Salesforce não replica de um dia para o outro é o conhecimento de vinte e sete anos de processo comercial, codificado em skill específica para cada etapa do funil — o tipo de ativo que o SkillsBench sugere que deveria valer mais, em desempenho e, por extensão, em preço e retenção de cliente.


Para Quem Constrói Skills Como Produto: Ativo Defensável Versus Commodity

Se você lidera produto ou tecnologia numa empresa que constrói ou pretende vender skill como produto, o dado do SkillsBench deveria mudar a prioridade de investimento. A distribuição de skill, como problema técnico, está essencialmente resolvida: o padrão aberto SKILL.md, publicado no site agentskills.io, já roda hoje em Claude, Codex CLI, Cursor, Gemini CLI e dezenas de outras ferramentas — cerca de 40 produtos compatíveis segundo o próprio site da especificação. Publicar uma skill e fazer ela rodar em qualquer agente compatível deixou de ser obstáculo. O obstáculo, hoje, é qualidade — e é exatamente aí que a especialização vertical separa o que vale de o que não vale.

Essa leitura também aparece do lado do desenvolvedor individual, não só do corporativo. Levantamento sobre monetização de skills publicado pelo marketplace Agensi mostra que as mais vendidas no início de 2026 concentram receita: as top de cada categoria geram entre US$ 500 e US$ 3 mil por mês em vendas recorrentes, enquanto a skill mediana listada rende menos de US$ 50 por mês, com a maior parte da receita concentrada nos 10% melhores anúncios. O padrão é consistente com o argumento deste post: o que vende bem "codifica opinião específica que, de outra forma, exigiria vários prompts para extrair" — skill de teste que já segue a convenção do time, revisão de código com foco em OWASP, pipeline de deploy com a restrição específica daquele stack. O wrapper genérico em torno de um prompt óbvio não vende, porque qualquer comprador escreve aquele prompt sozinho em segundos.

Um cenário hipotético ajuda a tornar isso concreto — é exemplo ilustrativo, não relato de caso real. Imagine uma fintech brasileira que constrói uma skill de conformidade regulatória específica para o mercado local: conhece as resoluções do Banco Central e da CVM aplicáveis ao seu segmento, sabe quais cláusulas costumam gerar apontamento em auditoria, e distingue exigência formal de boa prática recomendada. Vendida para fintechs menores sem equipe jurídica dedicada, essa skill tem dois atributos que uma skill genérica de "ajude com compliance" nunca vai ter: desempenho mensuravelmente melhor, pela mesma lógica do ganho de 51,9 pontos em saúde, e barreira de replicação real, porque conhecimento regulatório específico não é trivial de copiar. Esse par — desempenho mensurável mais barreira de cópia — é o que transforma uma skill em ativo defensável, não em commodity reproduzível numa tarde.


Do outro lado da mesa, para quem avalia adotar skills — seja comprando de um marketplace, seja aceitando o pacote embutido num produto como a Claudeforce —, o dado do SkillsBench sugere um critério diferente do que a maioria dos times usa hoje. É tentador escolher com base em tamanho de catálogo: diretórios comunitários já indexam centenas de milhares, às vezes milhões, de skills públicas. Mas catálogo grande, como o próprio benchmark mostrou com a nota média de 6,2 em 12, é majoritariamente ruído. Volume não é proxy de qualidade — às vezes é o oposto, porque catálogo aberto tem menos revisão por unidade publicada.

O critério mais útil, à luz do que o SkillsBench mediu, é perguntar por especificidade antes de quantidade: essa skill foi escrita para o meu domínio exato, com as convenções e o jargão que minha operação realmente usa, ou foi escrita ampla o suficiente para caber em qualquer empresa do setor? A segunda tende a ficar perto do ganho moderado observado onde o modelo já tem bastante conhecimento geral; a primeira se aproxima dos ganhos de dois dígitos altos em domínios regulados. Essa lógica de escolher com critério já apareceu neste blog quando tratei de qual conjunto de skills um time deveria adotar primeiro, no post sobre as skills que valem a pena versionar antes de outras — ali a pergunta era sobre prioridade de adoção interna; aqui é sobre critério de compra num mercado que já vende produto.

Isso também dialoga com a portabilidade que já discuti quando tratei de como o padrão de plugins e skills se tornou interoperável entre ferramentas diferentes. Portabilidade resolve o problema de "essa skill roda na minha ferramenta". Não resolve o problema de "essa skill é boa o suficiente para confiar num fluxo de trabalho real". São camadas diferentes de decisão, e confundir uma com a outra é o erro mais comum que vejo times cometerem ao avaliar catálogo de skill hoje: perguntam se instala, não perguntam se foi escrita por alguém que entende o domínio de verdade. Vale uma ressalva: nenhum desses números resolve sozinho a questão de segurança que corre em paralelo à de qualidade — skill executa script, e catálogo aberto sem revisão é superfície de ataque, não só ruído de desempenho. É discussão para outro post, mas reforça o mesmo argumento: quando distribuição deixa de ser diferencial, curadoria é onde o valor do mercado de skills está migrando.


Conclusão

O número que abre este post — 16,2 pontos percentuais de ganho médio, chegando a 51,9 em saúde — não é curiosidade acadêmica de benchmark. É a primeira evidência sólida de que a intuição de qualquer profissional que já comparou uma instrução genérica com uma instrução escrita por alguém que entende o domínio tem base mensurável. O conhecimento de nicho, quando embutido numa skill, reduz a ambiguidade que o agente precisaria resolver sozinho — e essa redução aparece em taxa de sucesso, em disposição de pagar, e na diferença entre um ativo defensável e uma commodity que qualquer concorrente reproduz numa tarde.

Não tenho como afirmar que esse padrão vai se manter estável conforme os próprios modelos generalistas melhoram — é plausível que parte do ganho hoje atribuído a skills verticais encolha à medida que o conhecimento geral do modelo absorve mais convenção de domínio ao longo do tempo, especialmente nas áreas mais documentadas publicamente. O que parece mais resistente a essa erosão é justamente o que a Claudeforce ilustra: conhecimento proprietário, de processo real de uma empresa específica, que nunca esteve disponível para treinar modelo nenhum porque nunca foi publicado. Isso não desaparece com o próximo lançamento de modelo.

Fico com uma constatação mais modesta para fechar. O mercado de skills passou, em menos de um ano, de "distribuir isso é o problema" para "distribuir já está resolvido, qualidade é que não está" — e essa transição favorece estruturalmente quem tem profundidade de domínio real para codificar, e desfavorece quem só tem tempo livre para escrever markdown genérico. Se isso vai se traduzir em mercado maduro de compra e venda de skill como qualquer outro software, ou vai ficar concentrado dentro de parcerias como a Claudeforce, entre grandes fornecedores que já têm o domínio e o modelo na mesma mesa, é pergunta que ainda não tem resposta fechada — mas é a pergunta certa para levar para a próxima decisão de que skill construir, comprar ou instalar.

Fontes:

Newsletter

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

Um resumo semanal com os melhores posts sobre IA, engenharia de software e tecnologia, enviado no melhor momento para continuar a conversa depois da leitura.

Foto de Elton José

Escrito por

eltonjose

Engenheiro de software e estrategista de produtos digitais, focado em IA pragmática e em transformar experiências de trabalho remoto em aprendizados aplicáveis. Compartilho frameworks e decisões reais que uso em consultorias e projetos.

  • Principais temasSKILL.md, Estratégia De Produto
  • Formato do conteúdoGuia prático + insights de carreira