Cavecrew: para que serve cada subagente do caveman (investigator, builder e reviewer)?

Fala aí, beleza? Você joga a tarefa inteira numa sessão só do Claude Code e fica vendo o contexto encher antes mesmo da coisa ficar pronta

Achar o arquivo, editar, revisar, tudo na mesma thread, e cada resposta comprida fica morando ali dentro pra sempre

O cavecrew é a skill do projeto caveman que ataca justamente isso: ela define três subagentes prontos, cavecrew-investigator, cavecrew-builder e cavecrew-reviewer, cada um com um trabalho só

Bora ver pra que serve cada um, o que cada um aceita fazer (e o que ele recusa na cara dura), e como quebrar uma tarefa entre os três em vez de empurrar tudo pra uma sessão só?

O que é o cavecrew e onde ele vive no projeto caveman

Antes do cavecrew, o pai da criança

O caveman é uma skill de Claude Code que corta 65% dos tokens de saída fazendo o agente falar em estilo caveman: derruba artigo, encheção de linguiça e formalidade, mas mantém o conteúdo técnico

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

É tipo pedir pro dev responder por telegrama: some o "claro, com certeza, vamos analisar juntos", fica o que interessa

Ele tem níveis de intensidade: lite, full (o padrão), ultra, e ainda as variantes wenyan-lite, wenyan-full e wenyan-ultra

E o cavecrew, onde entra nisso? Ele é uma skill DENTRO do projeto

A definição mora em skills/cavecrew/SKILL.md, e ela também vem empacotada em plugins/caveman/skills/cavecrew/SKILL.md

Já os três subagentes são arquivos separados, na pasta agents/ do repositório: agents/cavecrew-investigator.md, agents/cavecrew-builder.md e agents/cavecrew-reviewer.md

O repositório é do Julius Brussee (conta JuliusBrussee no GitHub) e a licença é MIT

Sinal de tração pra quem gosta de olhar isso antes de instalar coisa nova: o caveman bateu #1 no GitHub Trending em 02/07/2026, e apareceu pela primeira vez nas listas diária, semanal e mensal do Trendshift (todas as linguagens) em 11/04/2026

Se tu curte esse formato de plugin que chega empacotando várias skills de uma vez, dá uma olhada também em quais skills o Superpowers traz, a lógica de organização é bem parecida

Veja o caveman funcionando em vídeo

Pra começar do zero com cavecrew-investigator, builder e reviewer, ajuda ver antes o projeto que embala os três

Este vídeo do canal mostra o caveman no Claude Code:

cavecrew-investigator: quando você precisa achar o código

Esse é o primeiro da fila, e o mais fácil de entender

Ele é um localizador de código somente leitura (read-only code locator), ou seja: acha, aponta e não encosta em nada

As perguntas que ele foi feito pra responder são bem específicas:

• onde X está definido?
• o que chama Y?
• liste todos os usos de Z
• mapeie este diretório

As ferramentas liberadas pra ele são Read, Grep, Glob e Bash

O Bash entra pros casos em que a linha de comando resolve mais rápido, tipo git log -S, git grep e find

E tem um detalhe que faz diferença no contexto: ele lê apenas trechos específicos dos arquivos, não despeja o arquivo inteiro na sua cara

A saída em tabela file:line:

O formato de resposta dele é fixo, e isso é MUITO bom

Os achados voltam em tabela file:line, sempre com o caminho do arquivo primeiro, número de linha anexado e símbolos entre crases

A ordenação também é definida: por arquivo, e dentro de cada arquivo por linha ascendente

E a saída é segura para grep com o padrão path:\d+

"Por que eu deveria me importar com isso?"

Porque saída previsível é saída que outra ferramenta consegue consumir

Você (ou o próprio agente) pega aquele bloco e joga num grep pra filtrar, sem ter que ler prosa e adivinhar qual linha era qual 🙂

cavecrew-builder: edições cirúrgicas de 1 a 2 arquivos

O builder é o oposto do agente ambicioso

Ele é um editor cirúrgico de escopo limitado: 1 a 2 arquivos, com faixas de mudança pequenas

Os casos previstos pra ele são bem diretos:

• correção de typo
• reescrita de uma única função
• renomeações mecânicas

Agora se liga na parte mais interessante: ele recusa de forma dura escopo de 3 ou mais arquivos

Não é sugestão, é regra da definição dele

Também não é a ferramenta pra feature nova, pra criar arquivo novo (a menos que você peça) nem pra refatoração cross-file

Pra 3+ arquivos ou mudança transversal, o indicado é a thread principal ou um agente de arquitetura

A regra de ordem que ninguém deveria pular:

Tem uma orientação na definição do builder que vale tatuar: não use ele quando você ainda não sabe o arquivo

Nesse caso, dispara o investigator primeiro

O motivo é econômico: sem o alvo em mãos, a thread principal acaba gastando token passando contexto pro builder entender onde ele está pisando

Tome cuidado! Esse é o erro clássico de quem começa: chamar o editor achando que ele vai "dar uma olhada geral" antes de editar

cavecrew-reviewer: a passada adversarial sobre o diff

O terceiro entra depois que a mudança já existe

O cavecrew-reviewer varre diffs ou arquivos em busca de defeitos, numa passada adversarial sobre as mudanças

Adversarial aqui significa o seguinte: ele não está lá pra dizer que ficou bonito, está lá pra tentar achar problema

E o formato da saída deixa isso explícito: uma linha por achado, marcada por severidade, sem elogio e sem scope creep

O padrão é esse:

path:line: <emoji> <severidade>: <problema>

Uma linha por achado parece detalhe bobo, mas é o que permite revisar em lote

Você bate o olho, ordena por severidade, ignora o que é ruído e vai direto no que dói

Sem parágrafo de introdução, sem "ótimo trabalho, apenas alguns pontos de atenção", sem sugestão de reescrever meio projeto que você nem pediu

investigator, builder e reviewer lado a lado

Resumo dos três, só com o que está documentado no projeto:

O que muda no consumo de contexto ao delegar

Aqui mora o pulo do gato, e é bom deixar claro pra não vender fumaça

Os subagentes do cavecrew fazem o MESMO trabalho dos agentes padrão da Anthropic (Explore, agentes de edição, reviewer)

A diferença não é inteligência, é embalagem: a saída volta comprimida em estilo caveman, e o tool-result injetado no contexto principal fica bem menor que o equivalente sem compressão

A documentação do cavecrew dá um exemplo de conta pra ficar concreto

Um Explore padrão que devolve 2k tokens de prosa custa 2k tokens do orçamento do contexto principal a cada chamada

O mesmo achado, vindo do cavecrew-investigator, volta em cerca de 700 tokens

Multiplica isso por uma sessão longa, com dez, quinze delegações, e você entende por que a thread principal encolhe MUITO menos por delegação

E quando comprimir é perigoso?

Boa pergunta, porque texto picotado pode virar ambiguidade

O próprio projeto trata disso: o estilo caveman é descartado em avisos de segurança, em confirmações de ação irreversível e em qualquer saída em que a ambiguidade de fragmento possa ser mal lida

Ou seja, na hora dos rm -rf da vida, o agente volta a falar igente gente

O que você precisa antes de usar o cavecrew

O básico: Claude Code instalado e o plugin caveman adicionado

A instalação é esta:

claude plugin marketplace add JuliusBrussee/caveman && claude plugin install caveman@caveman

Caso a instalação trave ou apareça um marketplace not found, a orientação oficial é rodar de novo só o primeiro comando:

claude plugin marketplace add JuliusBrussee/caveman

A causa costuma ser o registro de marketplaces do Claude Code lento, ou o primeiro comando não ter concluído de fato

E só isso, beleza? Nada de next, next e finish com dez configurações extras que eu não vi documentadas

Vale lembrar que skill que chega por plugin é diferente de skill que mora dentro de um repositório específico, um papo que eu já levantei aqui no post sobre skill de design entre projetos

Como dividir uma tarefa entre os três subagentes

A SKILL.md do cavecrew funciona como guia de decisão: ela diz pra thread principal QUANDO disparar cada subagente em vez de fazer o trabalho inline ou usar o Explore padrão

Na prática, o fluxo de uma correção pequena fica assim:

1. Dispare o cavecrew-investigator pra achar arquivo e linha. Pergunta do tipo "onde essa função está definida" ou "liste todos os usos desse símbolo" é o feijão com arroz dele, e a resposta já volta em tabela file:line. O erro comum deste passo: pedir análise de qualidade pra ele, que é localizador, não revisor

2. Passe o alvo pro cavecrew-builder, respeitando o teto de 2 arquivos. Com caminho e linha em mãos, a edição é cirúrgica: typo, uma função, renomeação mecânica. O erro comum deste passo é duplo: chamar o builder sem saber o arquivo (aí a thread principal queima token passando contexto) e empurrar mudança transversal pra um agente que recusa 3 ou mais arquivos

3. Rode o cavecrew-reviewer sobre o diff resultante. Ele faz a passada adversarial e devolve uma linha por achado marcada por severidade. O erro comum deste passo: mandar revisar antes de ter diff nenhum, sendo que o trabalho dele é justamente em cima da mudança

4. Use as frases que acionam a skill. As documentadas são delegate to subagent, use cavecrew, spawn investigator/builder/reviewer, save context e compressed agent output

5. Escale pra thread principal quando o escopo cresce. Se a tarefa virou feature nova ou refatoração cross-file no meio do caminho, o caminho indicado é a thread principal ou um agente de arquitetura, não insistir no builder

Conclusão

O cavecrew não inventa capacidade nova, e é bom encarar isso com honestidade: localizar, editar e revisar já existiam nos agentes padrão

O que ele faz é dividir esses três papéis em presets com escopo estreito e devolver o resultado comprimido, pra que a thread principal encolha menos a cada delegação

cavecrew-investigator acha, cavecrew-builder mexe em 1 a 2 arquivos, cavecrew-reviewer aponta defeito, e cada um sabe quando dizer não

Próximo passo é bem simples: instala o plugin, abre o skills/cavecrew/SKILL.md e os arquivos da pasta agents/ pra ler as definições com seus próprios olhos, e começa por uma tarefa pequena, de 1 arquivo só

Depois tu vê se o contexto da sua sessão aguenta mais que antes 😀

até o próximo post!