/caveman-review vale a pena? Como funciona a revisão de código em uma linha do Claude Code

Uma revisão de código que responde assim:

L<line>: <severity> <problema>. <fix>.

Uma linha por achado, sem introdução, sem "eu percebi que", sem repetir o que o diff já está te mostrando na tela

Esse é o formato do /caveman-review, um comando do plugin caveman, definido no arquivo commands/caveman-review.toml do repositório

E aí vem a pergunta que interessa de verdade pra quem revisa PR todo dia: em que momento cortar texto acelera o teu trabalho, e em que momento esse corte tira justamente a parte que você precisava ler?

Como funciona a revisão em uma linha do /caveman-review

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

O mecanismo é simples de entender, e é aí que mora a graça

Cada achado vira uma linha só, no padrão L<line>: <severity> <problema>. <fix>.

Ou seja: onde está, o que está errado, e o que fazer

As severidades são quatro, marcadas por emoji:

• 🔴 bug
• 🟡 risk
• 🔵 nit
• ❓ question

Legal né? 🙂 Bate o olho e tu já sabe o que é urgente e o que é frescura de estilo

O que ele corta e o que ele preserva:

A revisão descarta preâmbulo (o clássico "I noticed that…"), hesitação e repetição do que o diff já mostra

E mantém três coisas: a linha exata, o símbolo entre crases e uma correção concreta

Pensa assim: se você já usou linter, a sensação é bem parecida, saída densa, apontando lugar e conserto, só que com um agente lendo o contexto do teu diff em vez de uma regra fixa

E quando o assunto é sério demais pra uma linha?

A própria skill prevê isso, e chama de auto-clarity

Ela desliga o modo terso em achado de segurança classe CVE, em discordância de arquitetura e em contexto de onboarding

No resto, ela retoma o modo terso

Ou seja, o formato compacto não é dogma dentro da ferramenta, ele tem exceção declarada

Comando, skill e agente: três portas pro mesmo assunto

Vale saber que o mesmo recurso também existe como skill, com skills/caveman-review/SKILL.md e README próprios dentro do repositório

E o repositório ainda traz um agente de revisão separado do comando, em agents/cavecrew-reviewer.md

A skill também é acionada por frases de revisão, não só pela chamada explícita: "review this PR", "code review", "review the diff" e o próprio /caveman-review

Revisão em uma linha x revisão com contexto longo: o que muda

Bora colocar os dois formatos lado a lado, com critérios que importam pra quem está com o PR aberto esperando aprovação:

Um aviso honesto sobre a última linha: esses números são do plugin como um todo, não do comando de revisão isolado

Não existe, entre o que dá pra conferir, um consumo medido só do /caveman-review

Quando o formato terso acelera e quando você ainda precisa de contexto

Aqui é onde a conversa fica prática

Acelera quando o achado é localizável:

• PR pequeno e médio, com o diff aberto do lado, porque o contexto já está na tua frente e o texto explicativo viraria redundância
• Varredura de nits, aquele 🔵 que você quer resolver em bloco antes de gastar atenção com o que é bug
• Segunda passada antes do merge, quando você já leu tudo uma vez e só quer checar se sobrou coisa
• Revisão do código que você mesmo escreveu, situação em que o "porquê" já está na tua cabeça

Repara no padrão: em todos esses casos o contexto não some, ele só sai do texto porque já está com você

Ainda pede texto longo quando a decisão é grande:

• Decisão de arquitetura, onde discordar em uma linha é praticamente impossível (e a própria skill reconhece isso no auto-clarity). Se o teu caso é escolher o caminho antes de escrever código, o papo é outro, e vale ler sobre decisões de arquitetura em projeto novo
• Achado de segurança classe CVE, onde a explicação é a entrega, não o enfeite
• PR de pessoa em onboarding, porque revisão ali também é ensino. É a crítica mais forte ao formato numa análise publicada no LinkedIn: o texto cortado é justamente a parte que ensina, e por isso o ganho aparece mais claro pra quem já é sênior. Se a pessoa está começando agora e nem programa direito ainda, o caminho passa por outro tipo de conversa com o agente, tipo usar o Claude sem programar
• Código de domínio desconhecido, onde "o que fazer" sem "por que" te deixa aplicando patch no escuro

Tome cuidado com o efeito colateral clássico: lista curta dá sensação de revisão completa

Achado enxuto não é sinônimo de cobertura maior, e não existe benchmark independente comparando qualidade, cobertura ou falso positivo do /caveman-review contra a revisão convencional do agente

Como instalar o caveman e acionar o /caveman-review

Bora ver na prática? São poucos passos

1. Instale o plugin no Claude Code, pelo terminal:

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

O erro comum deste passo: sair digitando /caveman-review na sessão antes de instalar o plugin

O comando não existe sozinho, ele vem junto com o caveman

2. Confira o selo do caveman na statusline do Claude Code, a palavra CAVEMAN com o ícone ⛏

Ele aparece depois que o plugin está instalado, e serve como confirmação visual rápida

3. Silencie o selo, se ele te incomodar, com a variável de ambiente:

CAVEMAN_STATUSLINE_SAVINGS=0

O erro comum deste passo: achar que sumir com o selo significa desinstalar alguma coisa

É só a exibição da statusline

4. Acione a revisão

Pode ser pelo comando direto, /caveman-review, ou pelos gatilhos em linguagem natural que a skill reconhece: "review this PR", "code review" e "review the diff"

5. Não confunda o comando de revisão com o resto do plugin

O caveman traz também /caveman <modo>, /caveman-commit, /caveman-stats, /caveman-compress e /caveman off

E o modo tem níveis de intensidade: lite, full (padrão), ultra, wenyan-lite, wenyan-full e wenyan-ultra

O erro comum deste passo: chamar /caveman ultra esperando revisão de código

São comandos diferentes, com propósitos diferentes

Veredito: para quem o /caveman-review compensa

Vou ser direto, e separando por perfil

Compensa se você é a pessoa que revisa PR do próprio time, conhece o código, e o gargalo é tempo de leitura

O formato de uma linha por achado com severidade em emoji foi desenhado exatamente pra esse cenário

Pensa duas vezes se você revisa código de gente em onboarding, ou se o PR toca decisão estrutural

O auto-clarity ajuda nos casos que ele cobre, mas quem decide o que é "discordância de arquitetura" é a ferramenta, não você

O que ainda não dá pra afirmar:

Sobre os números, transparência total

Os 65% de redução média de tokens de saída (com faixa de 22% a 87% entre os prompts) são benchmark do próprio projeto, com 10 prompts, restrito à saída

O dado de 33,2% menos tokens de entrada vem de benchmark fixado do Claude Code, também reportado pelo projeto

São números declarados pelo projeto, e uma análise publicada em andrew.ooo já apontou essa limitação do benchmark de 10 prompts

E este post não traz teste próprio, então não vou te vender conclusão de performance que eu não medi

Sobre o estado atual do projeto: a versão mais recente publicada é a v2.1.0, de 16/08/2026

Os projetos irmãos (cavekit, cavemem e caveman-code) estão marcados como "Frozen", com o desenvolvimento movido pro caveman

Isso é bom sinal de foco, e vale ter no radar

Conclusão

A regra prática cabe numa frase: terso pra achado localizável, longo pra decisão

Quando o problema mora numa linha específica e o conserto é objetivo, o /caveman-review te entrega exatamente isso, sem rodeio

Quando o problema é arquitetura, segurança ou gente aprendendo, você ainda quer o texto por extenso

Próximo passo? Instala, roda em um PR pequeno que você JÁ conhece de cor, e compara a saída com a tua própria leitura do diff

Se bater, aí sim leva pro fluxo do time

até o próximo post! 😀