Como revisar um pull request grande com o Claude Opus 5.5 sem receber só elogios?

Fala aí, beleza? Existe coisa mais inútil num PR de 40 arquivos do que um review que responde "boa, o código está limpo e bem organizado"?

A cena é sempre a mesma: PR grande, você revisou os três primeiros arquivos com atenção e os outros trinta no modo scroll, então joga o diff pra IA esperando socorro

E ela devolve um resumo do diff, com elogio de brinde 🙂

A Anthropic lançou o Claude Opus 5.5 em 22 de setembro de 2026, primeiro modelo da família 5.5, com foco em coding agêntico, uso de computador e trabalho de conhecimento

Modelo forte ajuda, mas não é ele que separa review útil de review bajulador

O que separa é COMO o pedido é montado: contexto do projeto, critério de aceite, o que ignorar e severidade por achado

Bora montar isso na prática?

O que você precisa antes de começar:

• Acesso ao Opus 5.5: ele está disponível para usuários Pro, Max, Team e Enterprise, além das plataformas de API
• Claude Code instalado e um repositório de verdade aberto: a revisão local olha os commits da branch que estão à frente do upstream mais as mudanças não commitadas, então precisa existir trabalho na branch ou na árvore de trabalho, senão não há nada a relatar
• Um CLAUDE.md no projeto: é o arquivo lido no início de cada sessão, onde moram padrões de código, decisões de arquitetura, bibliotecas preferidas e checklists de revisão
• Os critérios de aceite do PR na mão: se você não sabe dizer o que esse PR precisa cumprir, o modelo vai inventar um critério genérico e te elogiar em cima dele

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Um aviso importante antes de você planejar o fluxo todo em cima do GitHub: o Code Review integrado ao GitHub App está em research preview, disponível em Team e Enterprise, e fica indisponível para organizações com zero data retention ativado

Se o seu fluxo de PR já vive no terminal, vale decidir antes se você vai mexer nos PRs com gh CLI ou GitHub MCP, porque isso muda de onde você dispara a revisão

E se o plano da sua conta não bate com o research preview, sem drama: o /code-review roda no próprio terminal, sem instalar o GitHub App

Passo a passo para pedir um code review que aponta problemas:

1. Fixe o modelo antes de pedir qualquer coisa. Dentro da sessão dá pra trocar com /model, e aliases de família como opus são aceitos. A mudança vale para a próxima requisição da vez

/model opus

Se preferir já subir a sessão no modelo certo, use a flag na abertura (o model ID do Opus 5.5 na plataforma é claude-opus-5-5):

claude --model claude-opus-5-5

Erro comum deste passo: trocar de modelo no meio da revisão e esperar continuidade de raciocínio. Os blocos de thinking ficam vinculados ao modelo e à conversa, então troca no meio é troca de cabeça, não de marcha

2. Suba o esforço de raciocínio. O Claude Code tem o comando /effort com os níveis low, medium, high e xhigh, e rodar ele numa sessão interativa salva o nível para o modelo ativo em modelSettings

/effort high

Detalhe que muita gente não sabe: o padrão do Opus 5.5 no Claude Code é medium, um nível abaixo do padrão do Opus 5, que era high. Nos testes da Anthropic, o Opus 5.5 em medium iguala ou supera o Opus 5 em high em avaliações de código e trabalho de conhecimento

Ou seja: medium não é "modo econômico ruim". Mas em PR grande, subir compensa

Pra ter noção do que muda entre os níveis, a página viva do modelo no Artificial Analysis registra pontuações diferentes por esforço:

Erro comum deste passo: pedir pra desligar o thinking achando que fica mais rápido. No Opus 5.5 o thinking está sempre ativo e não pode ser desativado, e uso forçado de ferramenta retorna erro

3. Escreva o contexto do projeto e os critérios de aceite no CLAUDE.md, não no chat. Regra persistente vai pro arquivo, em vez de depender do histórico da conversa

Pensa assim: se você conhece aquele checklist de PR que o time cola no template do GitHub, o CLAUDE.md é o lugar equivalente pro Claude Code, com a diferença de que ele é lido em toda sessão

## Checklist de revisão

- Toda rota nova de API precisa de teste de integração
- Erro de domínio sobe como exceção tipada, nunca string
- Migration destrutiva exige script de rollback no mesmo PR

## Critérios de aceite deste ciclo

- Nenhuma query nova sem índice na coluna de filtro
- Nada de leitura de env fora da camada de config

Erro comum deste passo: criar um REVIEW.md e achar que a revisão local vai obedecer. A revisão local segue o CLAUDE.md como qualquer sessão e NÃO lê o REVIEW.md. O REVIEW.md na raiz é o arquivo de regras específicas de revisão quando o Code Review roda pelo GitHub App

4. Rode a revisão escolhendo o nível de cobertura. O comando aceita low, medium, high e max

Atenção pra não confundir: essa escala é do /code-review e tem nível max, coisa que a escala do /effort (low, medium, high e xhigh) não tem. São dois comandos diferentes, cada um com a sua régua

/code-review high

O que muda: em low e medium só saem os achados de maior confiança, e de high a max a cobertura aumenta, podendo entrar achados menos certos. É a troca clássica entre pegar tudo e conviver com falso positivo

Se você está acostumado com /review, ele é apelido de /code-review hoje. Antes da versão v2.1.223 era um comando separado que fazia revisão single-pass e read-only de um pull request do GitHub

Erro comum deste passo: passar o nível numa execução não interativa com -p e achar que ficou salvo como padrão. Nível passado com -p não atualiza o padrão salvo

5. Declare o que é Important e o que é no máximo Nit. Aqui é onde o review para de ser resumo e passa a ter hierarquia: os achados saem marcados por severidade, com Important em marcador vermelho e Nits em marcador amarelo, deduplicados e ordenados por severidade

Dá pra declarar quais classes de achado contam como Important e quais são no máximo Nit, escalar violações de CLAUDE.md para Important (o padrão delas é nit) e impor um teto, tipo reportar no máximo cinco nits e citar o resto como contagem no resumo

Esse teto é o que evita o review de PR grande virar uma parede de "faltou espaço aqui"

Erro comum deste passo: não declarar nada e reclamar que tudo veio no mesmo peso. Sem regra, o modelo não tem como saber que quebrar sua convenção de erro tipado é mais grave que nomear variável diferente

6. Declare o que ignorar. As regras por repositório permitem listar caminhos, padrões de branch e categorias de achado sem findings: código gerado, lockfiles, dependências vendorizadas, branches de máquina e o que o CI já cobre, tipo lint e spellcheck

E permitem adicionar regras próprias, do tipo "nova rota de API precisa de teste de integração"

Se você está na revisão local, é no CLAUDE.md que essas convenções ficam vivas; quando a revisão roda pelo GitHub App, o REVIEW.md na raiz guarda o que sempre sinalizar ou ignorar

Erro comum deste passo: deixar o lockfile e o código gerado dentro do escopo. O modelo gasta atenção em arquivo que ninguém revisa e sobra menos pra lógica

7. Em PR crítico, vai de ultra. O /code-review ultra lança uma frota de agentes revisores em sandbox na nuvem, na infraestrutura da Anthropic. Cada achado é reproduzido e verificado de forma independente, e vem com localização do arquivo e explicação

/code-review ultra

Quando o recurso está disponível pra conta, /ultrareview funciona como alias. E fora da sessão interativa existe o subcomando de linha de comando, que bloqueia até a revisão remota terminar e imprime os achados no stdout:

claude ultrareview

Erro comum deste passo: rodar ultra em todo PR. É revisão profunda em nuvem, faz sentido guardar pro que dói se quebrar

Uma coisa que explica porque isso funciona: no Code Review, cada agente procura uma classe de problema (erros de lógica, vulnerabilidades, edge cases quebrados, regressões sutis) e existe um passo de verificação que confere os candidatos contra o comportamento real do código, filtrando falso positivo. Os achados saem como comentários inline nas linhas, com resumo no corpo da revisão

Repare na ordem: primeiro procura problema, depois checa se o problema existe mesmo. Bem diferente de ler o diff e comentar o que achou bonito 😀

Por isso a documentação oficial de Code Review do Claude Code é leitura obrigatória antes de brigar com o resultado

Quando a revisão ainda volta só com elogios: sintoma, causa e correção

Sintoma: a revisão devolve um resumo do diff

Causa provável: nada foi declarado como Important e o nível está em low ou medium, onde só saem os achados de maior confiança

Correção: sobe pra /code-review high e escreve as classes de achado que contam como Important

Como prevenir: deixa o checklist de revisão no CLAUDE.md e escala violação de CLAUDE.md para Important, em vez de aceitar ela como nit

Sintoma: só vem nit de estilo

Causa provável: o que o CI já cobre continua no escopo da revisão, então lint e spellcheck ocupam a vaga do achado que importa

Correção: declara essas categorias como skip nas regras do repositório

Como prevenir: junta o skip com o teto de nits (reportar no máximo cinco e citar o resto como contagem no resumo)

Sintoma: nenhum achado, nenhum comentário, nada

Causa provável: não há commits à frente do upstream nem mudanças não commitadas. A revisão olha exatamente isso, então não existe diff pra relatar

Correção: confere em que branch você está e se o trabalho foi commitado ou está na árvore de trabalho

Como prevenir: rodar a revisão na branch do PR, não na base já sincronizada

Sintoma: achado genérico, sem localização, impossível de agir

Causa provável: falta de critério de aceite escrito, então o modelo comenta no nível do conceito, não da linha

Correção: em PR crítico, o /code-review ultra verifica cada achado de forma independente e entrega localização do arquivo com explicação

Como prevenir: critério de aceite específico no CLAUDE.md ("query nova sem índice na coluna de filtro" gera achado apontável, "código performático" não)

Sintoma: a sugestão ignora a convenção do time

Causa provável: a convenção existe só na cabeça das pessoas e no histórico de conversas antigas

Correção: escrever a convenção e reclassificar aquela classe de achado como no máximo Nit

Como prevenir: toda vez que você discordar do review, a resposta não é discutir no chat, é registrar a regra. Falo disso na próxima seção

Como tratar sugestões que não cabem no padrão do time

Tem três destinos possíveis pra cada sugestão que você recebeu e não gostou. Escolhe um:

1. Aceitar. Às vezes o modelo pegou algo que o time faz errado por hábito. Dói, mas é achado válido

2. Rebaixar pra nit. Quando a sugestão é legítima em geral, mas não é prioridade no seu projeto. Aí declara essa classe de achado como no máximo Nit e segue a vida

3. Virar regra permanente. Quando é convenção do time mesmo. Vai pro CLAUDE.md, que é o lugar de padrões de código, decisões de arquitetura, bibliotecas preferidas e checklists de revisão

O ponto chave: regra persistente mora em arquivo, não em conversa. Se você repete a mesma correção em três reviews seguidos, o problema não é o modelo, é o arquivo vazio 😛

Quando a revisão roda pelo GitHub App, o REVIEW.md na raiz do repositório guarda as regras específicas de revisão, o que sempre sinalizar ou ignorar. E o Code Review também lê os CLAUDE.md do repositório, tratando violações novas como achados nível nit (por isso o escalonamento pra Important faz tanta diferença)

Isso pesa dobrado quando o PR mexe em código em linguagem que você não domina: sem critério escrito, você fica sem base pra discordar do review e sem base pra aprovar o diff

Checklist recorrente virando comando:

Se existe um roteiro de revisão que você repete sempre (checklist de segurança antes de release, por exemplo), transforma em slash command

Um arquivo em .claude/commands/<nome>.md cria /<nome>, e aceita argumentos dinâmicos como $ARGUMENTS, $0 e $1. Pra comandos novos, o formato recomendado é .claude/skills/<nome>/SKILL.md, e o formato legado em .claude/commands/ continua funcionando

E se você desconfiar que alguma regra antiga está brigando com a nova, dá pra listar os arquivos de memória e seus escopos:

/memory

Ele lista os locais de CLAUDE.md, CLAUDE.local.md e outros arquivos de memória nos escopos de usuário e de projeto. Já me ferrei com regra de escopo de usuário sobrescrevendo decisão do projeto, então vale a conferida

Conclusão

O diferencial num code review com o Claude Opus 5.5 não é o modelo sozinho, é o pedido bem definido

O modelo dá o combustível: a Anthropic afirma que o Opus 5.5 entrega nível de Claude Fable 5.1 na maior parte do trabalho custando 40% menos para rodar que o Opus 5, com geração de saída mais de 30% mais rápida, e cita um teste interno em que ele ajudou a concluir uma migração de 680.000 linhas de código em menos de um dia

Mas quem decide se a revisão aponta risco ou distribui elogio é você, no CLAUDE.md e nas regras do repositório

Próximo passo prático, na ordem:

1. Escrever o bloco de checklist de revisão no CLAUDE.md, com os critérios de aceite do seu ciclo atual
2. Declarar os skips óbvios (código gerado, lockfiles, vendored, o que o CI já cobre)
3. Rodar /code-review high no próximo PR e comparar com uma rodada /code-review ultra em algo crítico

E se a sua revisão passa pela API, o custo entra na conta: o Opus 5.5 está em US$ 4 por milhão de tokens de entrada e US$ 20 por milhão de tokens de saída, 20% abaixo do Opus 5, com batch pela metade (US$ 2 e US$ 10). Cache read fica em US$ 0,20 por milhão, o que muda bastante o cálculo quando o contexto do projeto é reaproveitado em várias revisões

PR grande com review honesto é uma das poucas coisas que economiza tempo de verdade em vez de empurrar problema pra produção

Até o próximo post!