Como as skills derivam

Um time trabalhava em vários repositórios de produto. Tinha passado as sessões de refinamento do trimestre anterior lapidando sua skill de revisão, adicionando verificações de estratégias de rollback de migrações e outras convenções combinadas na sala. A skill atualizada vivia em um repositório. Cópias antigas ficavam nos outros, nunca atualizadas desde que haviam sido copiadas e coladas meses antes. Um engenheiro que entrou no time depois daquelas sessões revisava merge requests em um dos repositórios que ainda guardava a skill antiga. A skill parecia o padrão atual do time. Era o do trimestre passado.

Ninguém estava errado. O novato rodava a versão da skill que vivia no repositório designado. Os padrões tinham sido combinados em uma sala e commitados em um repositório. Os outros ainda guardavam a versão antiga. A prática atual vivia com os membros do time que estavam na sala. Os repositórios guardavam a do trimestre passado. O novato trabalhava com a de ontem.

Não é um problema novo. Configs de editor derivam, regras de lint derivam, formatadores derivam. O motivo de importar mais para o Claude Code é que o artefato deixou de ser cosmético. Uma skill muda o código que o Claude escreve. Um subagent muda quais ferramentas ele pode chamar. Um hook muda o que roda em volta de cada chamada de ferramenta. Quando os setups do time divergem entre repositórios, as saídas do modelo divergem junto, e você descobre na próxima vez que o time cruza repositórios.

Por que compartilhar dotfiles falha aqui

Quatro padrões se repetem em times que usam o Claude Code em vários repositórios. Isolados, não surpreendem. O que surpreende é que todos têm a mesma solução.

Deriva entre colegas. A mesma skill, duas versões, nenhum diff para comparar. As recomendações se contradizem. O líder do time vira a fonte de verdade humana, o que significa que o conhecimento está a um pedido de demissão de precisar ser reconstruído.

Custo de onboarding. Um engenheiro novo entra no meio do projeto e reconstrói o setup do time rolando o histórico do chat e perguntando: "quais skills vocês estão usando?" Não há um bundle canônico para instalar. O primeiro dia é artesanal.

Skills presas a um repositório de projeto. Uma skill útil escrita para o projeto A vira atrito no projeto B. Reutilizar significa copiar arquivos, consertar caminhos relativos e lembrar qual versão é a boa. A infraestrutura de IA do time acaba moldada pelo projeto onde cada peça foi escrita, não pela prática coletiva do time.

Nenhuma governança. Alguém adiciona um hook que roda um scanner de segredos antes de escritas de arquivo. Útil. E nunca revisado. Duas semanas depois você descobre que a regex tem um falso negativo, e outro colega vem deixando valores vazarem por ela sem perceber.

Um marketplace de plugins resolve os quatro. O marketplace é um repositório git. Cada artefato vive em código, cada mudança passa por revisão, cada colega roda /plugin marketplace update e recebe as mesmas versões. O padrão não é novo: times que esbarram nesses problemas costumam construir uma versão caseira (um repo de dotfiles compartilhado, um script de setup, uma wiki de convenções). O marketplace é o mecanismo formal.

Marketplace vs repositório

Disso decorre uma separação limpa de responsabilidades. Skills, subagents e hooks codificam "como o time trabalha" e permanecem constantes entre os projetos que o time toca. O lugar deles é no marketplace: agnósticos a projeto, instalados uma vez, disponíveis em todo lugar. Rules codificam "o que é este sistema" (a stack, a estrutura de arquivos, as convenções deste codebase) e pertencem ao repositório do projeto, no seu próprio diretório .claude/.

O erro conveniente é colocar uma skill útil no repositório do projeto onde você por acaso a escreveu. A skill deixa de ser reutilizável, começa a acumular suposições específicas do projeto e força um copia-e-cola quando você começa o próximo projeto. Quando você tem dois projetos, tem duas cópias. Elas derivam uma da outra pelo mesmo motivo que todo artefato compartilhado deriva: não existe fonte canônica.

O marketplace evita o erro dando aos "artefatos de time" um lar diferente dos "artefatos de projeto". Uma skill que vive no marketplace pode ser usada em todo codebase em que o time trabalha, sem modificação. Uma rule que vive no repositório do projeto fica onde é necessária, com escopo no sistema que descreve.

O que continua humano

O marketplace dá ao time um setup de IA versionado e revisável. O que entra nele continua sendo decisão do time.

Um bundle revisado vence cópias que derivam. O time consegue ver o que tem dentro. É isso que permite pensar a respeito.

Esse argumento não é específico do Claude. A mesma separação vale para qualquer CLI agêntica: convenções de time em um bundle versionado e agnóstico a projeto; regras de projeto no repositório. O Claude Code é uma implementação, ergonômica e fácil de distribuir. Ferramentas como opencode permitem ir além, roteando partes diferentes do fluxo para LLMs diferentes: um modelo mais barato para commits de rotina, um raciocinador mais forte para revisão de arquitetura, um modelo local para código sensível. A arquitetura continua a mesma. A implementação fica mais granular e mais hiperotimizada.

Se o seu time tem três ou mais pessoas usando assistentes de código com IA, você tem um problema de deriva, tenha dado esse nome a ele ou não. Publique um marketplace. O ganho vai além da consistência: é uma única fonte de verdade sobre como o time trabalha, acessível a qualquer um que saiba rodar um comando. O que eram quatro assistentes diferentes em quatro máquinas diferentes vira um bundle compartilhado. Versionado. Revisável. Instalado uma vez.