Skills estáticas são skills mortas

Ontem à noite, enviei uma seção de 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 eu 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 tinha acabado de enviar começaria a desviar no momento 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 observa sua trajetória. No momento em que você para de observar, ela se torna estática. Skills estáticas decaem no lugar. O post abaixo faz parte da série AI engineering que documenta como a infraestrutura de agentes evolui em produção.

As skills estáticas de agentes de AI falham porque param de aprender no momento em que são enviadas. Sem um loop de feedback que ingira trajetórias reais de invocação (as entradas, chamadas de ferramentas, saídas e estados de erro do uso real), as skills não conseguem se adaptar a produtos em mudança, consultas de usuários em deslocamento ou modos de falha recorrentes. Vários usuários redescobrem independentemente as mesmas soluções alternativas enquanto a definição da skill permanece congelada. A correção: agregação contínua de trajetórias que converte padrões de uso em atualizações automáticas das skills.

Um novo paper do 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 framework de agente.

TL;DR

As skills dos agentes são enviadas e depois param de melhorar. Os usuários descobrem os mesmos modos de falha independentemente e nunca alimentam essas descobertas de volta na 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 não existe mecanismo em nível de ecossistema para agregá-las em atualizações de skills. O framework SkillClaw deles propõe tratar as trajetórias agregadas como o sinal de evolução, executando um evoluidor autônomo que identifica padrões comportamentais recorrentes e os traduz em refinamentos ou extensões de capacidade.¹ O abstract cita “OpenClaw” como exemplo de agente LLM que usa skills reutilizáveis. Não consegui identificar o OpenClaw como um produto específico em operação apenas a partir do abstract, e não vou especular sobre isso neste post. O que vou afirmar é que o problema estrutural descrito pelo paper se aplica a qualquer pessoa que esteja construindo skills para Claude Code, Codex, Cursor ou seu próprio framework de agente. A conclusão: se sua biblioteca de skills não está ingerindo continuamente trajetórias do uso real, ela está morta desde o dia em que você a envia.

Principais conclusõ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, detecta 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 frameworks: Registre cada invocação de skill com sua trajetória: as entradas, as chamadas de ferramenta, as saídas, o estado de erro. Esse log é o sinal de evolução. Se você não está registrando, não está melhorando suas skills; está mantendo-as.
• Praticantes com 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 percorrer as afirmações do abstract com cuidado e depois marcar claramente onde estou estendendo o enquadramento.

A declaração do problema (do abstract). Os agentes LLM dependem de skills reutilizáveis para executar tarefas complexas. Essas skills permanecem em grande parte estáticas após a implantação. 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.¹

Os autores miram um modo de falha específico, não uma afirmação universal de que todas as skills decaem. Uma skill que nunca é invocada não decai. Uma skill que um único usuário invoca sem relatar problemas não decai visivelmente. O decaimento aparece quando vários usuários encontram cada um 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 abstract). O abstract afirma que, embora as 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.”¹ A afirmação mais importante está aqui. A lacuna não é que ninguém tenha pensado em melhorias nas skills. A lacuna é que nenhum mecanismo em nível de ecossistema agrega trajetórias, identifica padrões recorrentes e os traduz em atualizações.

O pipeline do SkillClaw (do abstract). O abstract 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.”¹ O sistema mantém skills atualizadas em um repositório compartilhado e as sincroniza entre os usuários, de modo que melhorias descobertas em um contexto se propagam por todo o sistema sem exigir esforço do usuário.¹

A avaliação (do abstract). O paper avalia o SkillClaw em um benchmark chamado WildClawBench usando o Qwen3-Max como modelo subjacente. A própria frase do abstract 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 assim: com interação e feedback limitados, o SkillClaw ainda produz melhorias significativas de desempenho em relação à baseline. O abstract não publica números específicos; presumivelmente o paper completo sim.

Esse é o paper conforme descrito pelo abstract. Os autores propõem que ecossistemas de agentes multiusuário com skills compartilhadas se beneficiam de 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 abstract cita “OpenClaw” como um exemplo (“LLM agents such as OpenClaw”) de um agente que usa skills reutilizáveis. Não sei o que é o OpenClaw apenas pelo abstract; não consegui identificá-lo rapidamente como um produto específico em operação. O framework do paper (SkillClaw) mira ecossistemas de agentes multiusuário em geral, não o OpenClaw especificamente, então a pergunta “o que é o OpenClaw” é em grande parte tangencial ao argumento. Estou sinalizando isso para que ninguém leia este post e saia pensando que o paper é sobre Claude Code. Não é. Ele nomeia o OpenClaw como exemplo e propõe o SkillClaw como mecanismo geral.

O que estou afirmando, separadamente do paper, é que o problema estrutural descrito pelo paper mapeia um problema real que venho vivendo no ecossistema de skills do Claude Code. Essa afirmação é minha, não do paper. Aqui está por que acho que ela se encaixa.

As skills no ecossistema Claude Code são enviadas como artefatos estáticos. Uma skill é um arquivo SKILL.md (ou um conjunto de arquivos de suporte) que descreve como uma tarefa deve ser executada. Você escreve uma vez. Faz commit. Referencia com um slash command ou via typeahead @skill-name; a mecânica de construir skills customizadas é simples. Uma vez enviada, é um artefato estático. Nenhum mecanismo automático observa como a skill é usada na prática ou atualiza a definição da skill com base no que funciona e no que falha.

Usuários diferentes encontram os mesmos modos de falha independentemente. Cada skill que enviei tem pelo menos um modo de falha recorrente que só aparece em condições específicas. Alguém invoca a skill com uma entrada que eu não antecipei, bate no edge case, contorna manualmente e segue em frente. Outra pessoa, em outro lugar, bate no mesmo edge case e faz sua própria solução alternativa. A skill em si nunca muda.

O sinal agregado é real, mas não utilizado. 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 no histórico de sessão de cada usuário individual. Só não está agregado em lugar nenhum, então ninguém age sobre ele.

A correção é manual ou inexistente. Neste momento, o único mecanismo para melhorar uma skill é eu perceber um problema no meu próprio uso, ou alguém abrir uma issue, ou alguém abrir um PR. Todos esses caminhos exigem esforço do usuário. O insight central do paper SkillClaw, de que os dados de trajetória já existem e deveriam alimentar as atualizações de skills 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 o meu próprio trabalho.

O padrão Shokunin, aplicado a skills

Um enquadramento continua emergindo quando penso em ofício. Jiro Ono, o mestre de sushi, é o exemplo canônico. Sessenta anos do mesmo trabalho. Todo dia, ele observa o que acontece no balcão, ajusta a técnica, refina 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á algum tempo. A ideia central: o ofício é o loop de feedback. Você faz o trabalho, observa o trabalho, percebe 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 centenas de 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, percebe o que quebrou entre sessões e propõe atualizações de volta na definição da skill. A ambição não é maluca. Na verdade, é a barra mínima se você quer que uma skill sobreviva à própria implantação.

Como isso fica na prática

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

1. Um log de trajetória para cada invocação de skill. Toda vez que uma skill roda, as entradas, as chamadas de ferramenta que faz, as saídas, os estados de erro e a disposição final (o usuário aceitou o resultado? reverteu? reescreveu?). O logging em nível de sessão já existe no Claude Code; a pergunta é se ele é 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órias e identifica padrões recorrentes: mesma classe de entrada levando à mesma falha, mesma chamada de ferramenta falhando da mesma forma, mesmo edge case aparecendo em contextos de usuário diferentes. O requisito é clustering sobre dados estruturados de trajetória, não AGI.

3. Um gerador de propostas. Dado um padrão detectado, redigir uma atualização candidata para a skill: um novo 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 já enviada.

4. Um gate. Cada atualização proposta passa por revisão humana, verificação factual (o mesmo gate rigoroso que aplico a tudo mais) 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 cada usuário dessa skill. Em um ecossistema centralizado isso é trivial (atualiza a skill canônica, todos puxam). Em um ecossistema distribuído isso é mais difícil.

A maior parte já existe no Claude Code: logging de sessão, definições de skill versionadas, um loop operacional de crítica. A peça que falta é a camada de agregação e detecção de padrões que conecta as trajetórias de sessão às atualizações de skills. A taxonomia organizacional de comandos, skills, subagents e regras já fornece a base estrutural; o que falta é o canal de feedback que mantém cada categoria viva após a implantação.

A implicação incômoda

Cada skill que enviei nos últimos seis meses está morta exatamente no sentido que o paper SkillClaw descreve. Escrevo a skill. Uso eu mesmo. Percebo problemas. Corrijo nas skills que eu uso. Minhas skills ficam melhores para mim. Elas não ficam melhores para mais ninguém, a menos que essa pessoa perceba independentemente o mesmo problema e registre algo.

O trabalho que fiz ontem à noite no Settings Reference é exatamente esse padrão. O guia do Claude Code é um artefato compartilhado. Os usuários o consultam em busca de chaves de config específicas. Posso ver os dados do GSC me dizendo quais chaves de config são pesquisadas. Isso é dado de trajetória agregado, literalmente me dizendo quais skills do guia estão sendo invocadas e onde os resultados estão aterrissando. E até eu ir olhar esses dados, o guia estava estático. Estava estático há semanas. Não porque ninguém observasse 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 dos dados de trajetória para as atualizações de skills, suas skills estão envelhecendo no lugar. Podem continuar funcionando para alguns usuários em algumas condições. Não estão ficando melhores.

A única pergunta é se você aceita que suas skills morrem no momento em que são enviadas ou se constrói o observador que as mantém vivas. O princípio de contexto composto se aplica aqui: cada observação de trajetória se compõe com a próxima, e o valor da skill cresce não linearmente com o feedback que ela ingere. Por outro lado, tratar contexto como arquitetura significa reconhecer que a estrutura de uma skill determina sua capacidade de absorver novas informações, antes de tudo.

O agregador mínimo viável

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

Aqui está a menor coisa real que posso enviar agora, hoje: um único arquivo de texto que registra cada invocação de skill entre minhas próprias sessões, append-only, com timestamp + nome da skill + shape da entrada + disposição final (aceito / revisado / revertido). Sem detector de padrões. Sem evoluidor autônomo. Apenas o log.

Esse arquivo é o agregador mínimo viável. Não é o SkillClaw. É a camada de entrada que o SkillClaw precisaria se existisse, e a camada de entrada que eu preciso antes mesmo de conseguir ver se minhas skills têm modos de falha recorrentes. Sem ele, estou adivinhando. Com ele, posso pelo menos escanear o log manualmente quando estiver revisando uma skill e perguntar: a mesma quebra aconteceu três vezes este mês?

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

Se 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 evoluidor autônomo completo rodando em um ecossistema multiusuário. Minha ambição é não estar rodando no escuro.

FAQ

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

Não, e também não posso te dizer o que é o OpenClaw. O abstract 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 operação apenas pelo abstract. O importante: o framework SkillClaw do paper mira ecossistemas de agentes multiusuário em geral, não o OpenClaw ou o Claude Code especificamente. 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 inovadora do paper?

Conforme o abstract: 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) executa um evoluidor 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 os usuários.¹ A novidade não é “skills podem ser melhoradas” (isso é óbvio). A novidade é propor que o loop de melhoria seja autônomo e orientado por trajetórias, não orientado por humanos.

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

O abstract descreve a melhoria como “significant” 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.

Em que isso difere de um pull request no git contra uma definição de skill?

Um PR é um mecanismo iniciado por humano. Alguém tem que perceber o problema, escrever a correção, abrir o PR, revisar, fazer o merge. Cada etapa exige esforço humano. O framework SkillClaw que o paper propõe é agregação autônoma — o sistema percebe o padrão entre muitos usuários, propõe a correção sozinho e sincroniza a atualização sem nenhum usuário individual ter que abrir nada.¹ Se essa versão autônoma é desejável ou segura para algum ecossistema específico é uma questão à parte. A contribuição do paper é mostrar que isso é tecnicamente coerente.

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

O paper não faz afirmações sobre nenhum ecossistema específico de skills 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 independentemente, nenhum mecanismo de agregação) se aplica sim às skills do Claude Code, e que qualquer pessoa construindo skills para Claude Code ou qualquer framework de agente semelhante deveria pensar em como construir um loop de melhoria orientado por trajetórias. Essa é minha opinião, não um achado 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, levado 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