Skills estáticas são skills mortas

Ontem à noite enviei uma seção Settings Reference para o guia do Claude Code. Quinze entradas. Cada citação verificada com grep contra um número de linha. Enviei por convicção, depois que o loop de crítica voltou limpo. Quando eu estava fazendo commit do arquivo .md, já sabia que precisaria de uma v3 — não porque tivesse feito algo errado, mas porque o guia muda, o produto subjacente muda, as consultas dos usuários mudam, e a seção que eu acabara de enviar começaria a derivar no minuto em que eu me afastasse dela.

Uma skill, seja uma seção de referência em Markdown ou uma definição de skill de agente em .claude/skills/, só está viva enquanto alguém está observando sua trajetória. No minuto em que você para de observar, ela se torna estática. Skills estáticas decaem no lugar.

Um novo paper no arxiv de Ma, Yang, Ji, Wang e Wang (“SkillClaw: Let Skills Evolve Collectively with Agentic Evolver”, abril de 2026) formaliza esse problema no nível da pesquisa.¹ O enquadramento inicial deles, citado diretamente: “Large language model (LLM) agents such as OpenClaw rely on reusable skills to perform complex tasks, yet these skills remain largely static after deployment. As a result, similar workflows, tool usage patterns, and failure modes are repeatedly rediscovered across users, preventing the system from improving with experience.”¹

Venho vivendo esse modo de falha há meses. Você também, se está construindo skills para qualquer harness de agente.

TL;DR

Skills de agente são enviadas e param de melhorar. Usuários descobrem os mesmos modos de falha de forma independente e nunca alimentam essas descobertas de volta para a própria skill. Ma et al. enquadram isso como um problema de inteligência coletiva: interações entre usuários e ao longo do tempo são sinais sobre quando uma skill funciona ou falha, mas nenhum mecanismo no nível do ecossistema existe para agregá-las em atualizações de skill. O framework SkillClaw deles propõe tratar trajetórias agregadas como o sinal de evolução, executando um evolver autônomo que identifica padrões comportamentais recorrentes e os traduz em refinamentos ou extensões de capacidade.¹ O resumo cita “OpenClaw” como exemplo de agente LLM que usa skills reutilizáveis — eu não consegui identificar o OpenClaw como um produto específico em produção apenas pelo resumo, e não vou especular sobre ele neste post. O que vou afirmar é que o problema estrutural descrito pelo paper se aplica a qualquer pessoa que construa skills para Claude Code, Codex, Cursor ou seu próprio harness. A tese: se sua biblioteca de skills não está ingerindo continuamente trajetórias de uso real, ela está morta desde o dia em que foi enviada.

Principais lições

• Autores de skills: O trabalho não termina quando a skill é enviada. O trabalho termina quando você tem um loop que observa como a skill é usada, captura modos de falha recorrentes e os alimenta de volta na definição da skill. Enviar é o começo da vida da skill, não o fim.
• Construtores de harness: Faça log de toda invocação de skill com sua trajetória — os inputs, as tool calls, os outputs, o estado de erro. Esse log é o sinal de evolução. Se você não está fazendo log, não está melhorando suas skills; está apenas mantendo-as.
• Praticantes de mentalidade Jiro: O paper SkillClaw é linguagem acadêmica para o padrão Shokunin aplicado a skills. A skill é o ofício. As trajetórias são a prática. A evolução é a busca pela maestria. Estático = morto.

O que o paper realmente diz

Vou passar pelas afirmações do resumo com cuidado, e depois marcar claramente onde estou estendendo o enquadramento.

A declaração do problema (do resumo). Agentes LLM dependem de skills reutilizáveis para realizar tarefas complexas. Essas skills permanecem em grande parte estáticas após o deployment. Workflows semelhantes, padrões de uso de ferramentas e modos de falha são repetidamente redescobertos entre usuários. O sistema não melhora com a experiência.¹

Essa é uma afirmação sobre um modo de falha específico, não uma afirmação de que todas as skills decaem. Uma skill que nunca é invocada não decai. Uma skill invocada por um único usuário que nunca reporta problemas não decai visivelmente. O decaimento aparece quando você tem múltiplos usuários, cada um encontrando sua própria versão da mesma falha, e o sistema não tem como agregar esses encontros em uma única atualização. (Essa última frase é meu enquadramento, não do paper.)

A lacuna existente (do resumo). O resumo afirma que, embora interações entre usuários “provide complementary signals about when a skill works or fails, existing systems lack a mechanism to convert such heterogeneous experiences into reliable skill updates.”¹ Essa é a afirmação que sustenta o argumento. Não é que ninguém tenha pensado em melhoria de skills. É que nenhum mecanismo no nível do ecossistema agrega trajetórias, identifica padrões recorrentes e os traduz em atualizações.

O pipeline do SkillClaw (do resumo). O resumo descreve um pipeline contínuo: o SkillClaw “aggregates trajectories generated during use and processes them with an autonomous evolver, which identifies recurring behavioral patterns and translates them into updates to the skill set by refining existing skills or extending them with new capabilities.”¹ As skills atualizadas são mantidas em um repositório compartilhado e sincronizadas entre usuários, então melhorias descobertas em um contexto se propagam pelo sistema sem exigir esforço do usuário.¹

A avaliação (do resumo). O paper avalia o SkillClaw em um benchmark chamado WildClawBench usando o Qwen3-Max como modelo subjacente. A própria redação do resumo está gramaticalmente quebrada na versão publicada: “experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios.”¹ Eu leio isso como: com interação e feedback limitados, o SkillClaw ainda produz melhorias significativas de desempenho em relação ao baseline. O resumo não publica números específicos — o paper completo presumivelmente publica.

Esse é o paper conforme o resumo descreve. Os autores propõem que ecossistemas de agentes multiusuário com skills compartilhadas se beneficiam da agregação automatizada de trajetórias alimentando atualizações automatizadas de skills, e relatam que sua implementação melhora significativamente o desempenho do Qwen3-Max em condições de feedback limitado.

O que o paper não diz (e o que estou acrescentando)

O resumo cita “OpenClaw” como um exemplo (“LLM agents such as OpenClaw”) de um agente que usa skills reutilizáveis. Eu não sei o que é o OpenClaw apenas pelo resumo — não consegui identificá-lo rapidamente como um produto específico em produção. O framework do paper (SkillClaw) é apresentado como uma solução para ecossistemas de agentes multiusuário em geral, não para o OpenClaw especificamente, então a pergunta “o que é o OpenClaw” é majoritariamente tangencial ao argumento. Estou sinalizando isso para que ninguém leia este post e saia achando que o paper é sobre Claude Code. Não é. Ele cita o OpenClaw como um exemplo e propõe o SkillClaw como um mecanismo geral.

O que estou afirmando — separadamente do paper — é que o problema estrutural descrito pelo paper se aplica a um problema real que venho vivendo no ecossistema de skills do Claude Code. Essa afirmação é minha, não do paper. Eis por que acho que se aplica.

Skills no ecossistema do Claude Code são enviadas como artefatos estáticos. Uma skill é um arquivo SKILL.md (ou um bundle de arquivos de suporte) que descreve como uma tarefa deve ser realizada. Você escreve uma vez. Faz commit. Referencia com um slash command ou via typeahead @skill-name. Uma vez enviada, é um artefato estático. Não há mecanismo automático que observe como a skill é usada na prática e atualize a definição da skill com base no que funciona e no que falha.

Usuários diferentes atingem os mesmos modos de falha de forma independente. Toda skill que enviei tem pelo menos um modo de falha recorrente que só aparece sob condições específicas. Alguém invoca a skill com um input que eu não antecipei, atinge o edge case, contorna manualmente e segue em frente. Outra pessoa, em algum outro lugar, atinge o mesmo edge case e faz seu próprio contorno. A skill em si permanece inalterada.

O sinal agregado é real, mas não é usado. Se eu pudesse ver cada trajetória de cada invocação de cada skill que enviei, poderia identificar os modos de falha recorrentes em uma tarde. Esse sinal existe — está no histórico de sessão de cada usuário. Simplesmente não é agregado em lugar nenhum, então ninguém age sobre ele.

A correção é manual ou inexistente. Hoje, o único mecanismo de melhoria de skill é eu perceber um problema no meu próprio uso, ou alguém abrir uma issue, ou alguém abrir um PR. Todos esses são caminhos que exigem esforço do usuário. O insight central do paper SkillClaw — que os dados de trajetória já existem e deveriam ser convertidos em atualizações de skill automaticamente — é exatamente o mecanismo que está faltando.

Essa é minha afirmação sobre como o enquadramento do paper se aplica ao Claude Code. Não é o que o paper diz. É como estou lendo o paper contra meu próprio trabalho.

O padrão Shokunin, aplicado a skills

Há um enquadramento ao qual sempre volto quando penso em ofício. Jiro Ono, o mestre do sushi, é o exemplo canônico. Sessenta anos do mesmo trabalho. Todos os dias, observando o que acontece no balcão, ajustando a técnica, refinando a temperatura do arroz, o ângulo da faca, o timing do shari. O próprio trabalho é o sinal de treinamento. O praticante é o agregador.

Escrevi sobre o enquadramento Shokunin / quality-loop há um tempo. A ideia central: o ofício é o feedback loop. Você faz o trabalho, observa o trabalho, nota o que quebrou, ajusta, faz o trabalho de novo. Repetidamente. A maestria vive no delta entre o que você pretendia e o que realmente aconteceu, e na sua disposição de carregar esse delta para a próxima tentativa.

Uma skill estática quebra esse loop. Você envia a skill. Para de observar. O delta entre o que a skill pretendia e o que realmente acontece se acumula em cem sessões diferentes que você nunca vê. A skill não melhora porque o artesão não está no balcão.

O paper SkillClaw propõe um agregador automatizado — não um substituto para o humano, mas um mecanismo que observa todas as trajetórias, nota o que quebrou entre sessões e propõe atualizações de volta na definição da skill. Isso não é uma ambição maluca. Na verdade, é o mínimo exigido se você quer que uma skill sobreviva ao seu próprio deployment.

Como isso se parece na prática

Se eu quisesse construir o padrão SkillClaw contra as skills do Claude Code que mantenho hoje, eis o que precisaria:

1. Um log de trajetória para toda invocação de skill. Toda vez que uma skill roda: os inputs, as tool calls que ela faz, os outputs, os estados de erro e a disposição final (o usuário aceitou o resultado? reverteu? reescreveu?). Isso já existe no nível de sessão no Claude Code — a questão é se é agregado entre sessões e extraído para o dono da skill.

2. Um detector de padrões. Algo que lê o log de trajetória e identifica padrões recorrentes: a mesma classe de input levando à mesma falha, a mesma tool call falhando da mesma forma, o mesmo edge case aparecendo sob diferentes contextos de usuário. Isso não é AGI — é clustering em dados de trajetória estruturados.

3. Um gerador de propostas. Dado um padrão detectado, rascunhar uma atualização candidata para a skill: uma nova branch de tratamento, um exemplo adicional, uma restrição extra no corpo do SKILL.md. A atualização é uma proposta, não uma mudança enviada.

4. Um gate. Toda atualização proposta passa por revisão humana, verificação factual (o mesmo hard gate que aplico a tudo) e um loop de crítica antes de ser enviada. A automação faz a agregação, não o envio.

5. Distribuição. Quando uma atualização proposta é aceita, ela se propaga para todo usuário daquela skill. Em um ecossistema centralizado, isso é trivial (atualize a skill canônica, todos fazem pull). Em um ecossistema distribuído, é mais difícil.

A maior parte já está presente no Claude Code — session logging existe, definições de skill são versionadas, o loop de crítica é operacional — a peça faltante é a camada de agregação e detecção de padrões que conecta trajetórias de sessão a atualizações de skill.

A implicação desconfortável

Toda skill que enviei nos últimos seis meses está morta exatamente no sentido que o paper SkillClaw descreve. Eu escrevo a skill. Eu mesmo uso. Noto problemas. Corrijo nas skills que eu uso. As skills melhoram para mim. Não melhoram para mais ninguém, a menos que essa pessoa note independentemente o mesmo problema e abra alguma coisa.

O trabalho que fiz ontem à noite na Settings Reference é exatamente esse padrão. O guia do Claude Code é um artefato compartilhado. Usuários o consultam buscando chaves de config específicas. Posso ver os dados do GSC me dizendo quais chaves de config estão sendo pesquisadas. Isso é dado de trajetória agregado — está literalmente me dizendo quais skills no guia estão sendo invocadas e onde os resultados estão pousando. E até eu ir olhar esses dados, o guia estava estático. Tinha ficado estático por semanas. Não porque ninguém estava observando as trajetórias, mas porque eu era a única pessoa que podia observá-las, e eu tinha outras coisas para fazer.

O paper SkillClaw é a formalização acadêmica do problema. O mecanismo prático é mais simples: se você não tem um pipeline automático de dados de trajetória para atualizações de skill, suas skills estão envelhecendo no lugar. Podem ainda funcionar para alguns usuários sob algumas condições. Não estão melhorando.

A única questão é se você aceita que suas skills estão mortas no momento em que são enviadas, ou se constrói o observador que as mantém vivas.

O agregador mínimo viável

Antes de começar este post, eu tinha zero agregação de trajetórias nas minhas skills. Nenhuma. Tinha histórico de sessão que podia ler manualmente, mas nada que trouxesse padrões entre sessões. Essa é exatamente a patologia da skill estática que o paper descreve, e eu estava rodando ela.

Eis a menor coisa real que posso enviar contra isso agora, hoje: um único arquivo de texto que faz log de toda invocação de skill nas minhas próprias sessões, append-only, com timestamp + nome da skill + formato do input + disposição final (aceita / revisada / revertida). Sem detector de padrões. Sem evolver autônomo. Apenas o log.

Esse arquivo é o agregador mínimo viável. Não é o SkillClaw. É a camada de input que o SkillClaw precisaria se existisse, e é a camada de input que eu preciso antes mesmo de poder ver se minhas skills têm modos de falha recorrentes. Sem ele, estou chutando. Com ele, posso pelo menos escanear o log à mão quando estou revisando uma skill e perguntar: essa coisa quebrou da mesma forma três vezes este mês?

Esse é o compromisso. Um arquivo. Append-only. Logado por invocação. Revisado quando eu revisar a skill.

Se isso funcionar, a próxima camada é o detector de padrões. Se o detector de padrões funcionar, a próxima camada é o gerador de propostas. A ambição do paper é um evolver autônomo completo rodando através de um ecossistema multiusuário. A minha ambição é não rodar no escuro.

FAQ

O “OpenClaw” no paper é o mesmo que Claude Code?

Não, e também não posso dizer o que é o OpenClaw. O resumo menciona “LLM agents such as OpenClaw” como um exemplo de agente que usa skills reutilizáveis, sem defini-lo. Não consegui identificá-lo rapidamente como um produto específico em produção apenas pelo resumo. O importante é que o framework SkillClaw do paper é apresentado como uma solução geral para ecossistemas de agentes multiusuário, não como uma solução especificamente para o OpenClaw ou o Claude Code. Seja lá o que o OpenClaw for, o paper não é um paper sobre Claude Code, e minhas afirmações sobre Claude Code neste post são minhas, não do paper.¹

Qual é a contribuição realmente nova do paper?

Segundo o resumo: um framework para evolução coletiva de skills em ecossistemas de agentes multiusuário que (1) agrega trajetórias entre usuários e ao longo do tempo, (2) roda um evolver autônomo para detectar padrões recorrentes e (3) traduz padrões em atualizações de skills em um repositório compartilhado que sincroniza entre usuários.¹ A novidade não é “skills podem ser melhoradas” — isso é óbvio. A novidade é propor que o loop de melhoria deva ser autônomo e guiado por trajetórias, não guiado por humanos.

O paper reporta números específicos de melhoria?

O resumo descreve a melhoria como “significativa” em um benchmark chamado WildClawBench usando o Qwen3-Max, sob condições de feedback limitado, mas não publica números específicos.¹ Para números, o paper completo é a fonte.

Como isso é diferente de um pull request no Git contra uma definição de skill?

Um PR é um mecanismo iniciado por humano. Alguém tem que notar o problema, escrever a correção, abrir o PR, revisar, fazer merge. Cada passo exige esforço humano. O framework SkillClaw que o paper propõe é agregação autônoma — o sistema nota o padrão entre muitos usuários, propõe a correção por conta própria e sincroniza a atualização sem que nenhum usuário único tenha que abrir nada.¹ Se essa versão autônoma é desejável ou segura para algum ecossistema específico é uma questão separada. A contribuição do paper é mostrar que é tecnicamente coerente.

Isso se aplica às minhas skills personalizadas do Claude Code?

O paper não faz afirmações sobre nenhum ecossistema de skills específico do Claude Code. Minha afirmação — separada do paper — é que o problema estrutural (skills enviadas como artefatos estáticos, modos de falha redescobertos por cada usuário de forma independente, sem mecanismo de agregação) se aplica sim às skills do Claude Code, e que qualquer pessoa construindo skills para Claude Code ou qualquer harness similar deveria estar pensando em como construir um loop de melhoria guiado por trajetórias. Essa é minha opinião, não uma descoberta do paper.

Qual é a conexão com o Shokunin?

O enquadramento Shokunin / quality-loop argumenta que a maestria vem do delta entre o que você pretendia e o que realmente aconteceu, carregado para a próxima tentativa. Skills estáticas quebram esse loop porque os deltas se acumulam em sessões que o artesão nunca vê. O SkillClaw é a versão acadêmica de fechar esse loop — automatizar a coleta de deltas e alimentá-los de volta na skill. A disciplina é a mesma; o mecanismo é diferente.

Referências