Nota do autor: Reuni 25 comandos de Code Review para o Claude Code, testados em cenários reais, cobrindo 7 áreas críticas como análise de segurança, performance, revisão de arquitetura, detecção de bugs e revisão de PR, além de uma fórmula para criar seus próprios comandos.
O Claude Code já vem com o comando /security-review e um sistema multi-agente para Code Review, mas a saída padrão costuma ser prolixa e focar em detalhes irrelevantes. Bons comandos de revisão devem ser precisos como casos de teste: definir o escopo, estabelecer prioridades e exigir números de linha específicos e sugestões de correção. Este artigo compila 25 comandos para 7 cenários de Code Review, prontos para você copiar e usar.
Valor principal: 25 comandos para os cenários mais frequentes de Code Review, com fórmula de criação e exemplos de "bom vs. ruim".
Fórmula para escrever comandos de Review
Um bom comando de Review é tão preciso quanto um caso de teste. Um comando de Review ruim parece uma mensagem vaga no Slack.
Fórmula de cinco elementos
[Papel] Como um engenheiro sênior de {linguagem/área}
[Escopo] Revise as {alterações} de {arquivo/diretório/PR}
[Foco] Concentre-se em {segurança/desempenho/lógica/arquitetura}
[Formato] Formato de saída: {lista numerada/tabela/comentários inline}
[Nível] Classifique a severidade: {Crítico/Alto/Médio/Baixo}
| Elemento | Exemplo ruim | Exemplo bom |
|---|---|---|
| Papel | (Não definido) | "Como um engenheiro backend sênior" |
| Escopo | "Dê uma olhada neste código" | "Revise o git diff recente de src/auth/" |
| Foco | "Dê algum feedback" | "Concentre-se em injeção de SQL e bypass de autenticação" |
| Formato | (Saída livre) | "Lista numerada, cada item contendo arquivo:número da linha, descrição do problema, sugestão de correção" |
| Nível | (Sem exigência) | "Classifique como Crítico/Alto/Médio/Baixo" |
Cenário 1: Revisão de segurança (4 comandos)
A revisão de segurança é o cenário de maior prioridade em um Code Review. O Claude Code já possui o comando /security-review, mas comandos personalizados podem ser muito mais profundos.
Comando #1: Varredura completa OWASP Top 10
Como um engenheiro de auditoria de segurança, revise todos os arquivos modificados recentemente no diretório src/.
Verifique item por item de acordo com o OWASP Top 10:
1. Injeção (SQL/NoSQL/Injeção de comando)
2. Falhas de autenticação
3. Exposição de dados sensíveis
4. XXE
5. Falhas de controle de acesso
6. Configurações incorretas de segurança
7. XSS
8. Desserialização insegura
9. Uso de componentes com vulnerabilidades conhecidas
10. Falhas de registro e monitoramento
Formato de saída: lista numerada, cada item contendo [arquivo:número da linha] [nível de severidade] [descrição do problema] [sugestão de correção].
Relate apenas problemas reais existentes, não reporte riscos teóricos.
Comando #2: Revisão de segurança de endpoints de API
Revise todos os arquivos de rotas de API (routes/, controllers/), concentrando-se em:
- Se existem endpoints sem middleware de autenticação
- Se os parâmetros passaram por validação de entrada e sanitização
- Se existe risco de atribuição em massa (mass assignment)
- Se o limite de taxa (rate limiting) está configurado
- Se as respostas de erro revelam informações internas
Formato de saída: Tabela | Caminho do endpoint | Problema | Nível de severidade | Solução de correção
Comando #3: Detecção de vazamento de informações sensíveis
Faça uma varredura em todo o projeto e verifique se as seguintes informações sensíveis estão hardcoded ou expostas acidentalmente:
- Chaves API, Segredos, Tokens
- Strings de conexão com banco de dados
- Chaves privadas e certificados
- IPs internos e nomes de domínio
- Senhas ou credenciais em comentários
O escopo da verificação inclui: código-fonte, arquivos de configuração, .env.example, docker-compose.yml, README
Marque o caminho do arquivo e o número da linha de cada descoberta.
Comando #4: Revisão de lógica de autenticação e autorização
Como um especialista em segurança, revise o código relacionado à autenticação e autorização:
1. A lógica de verificação de token JWT está completa (expiração, assinatura, adulteração)?
2. O armazenamento de senhas utiliza hash seguro (bcrypt/argon2)?
3. O gerenciamento de sessão possui risco de ataque de fixação de sessão?
4. A configuração de CORS está muito permissiva?
5. O callback OAuth valida o parâmetro state?
Relate apenas problemas de nível Crítico e Alto, anexando exemplos de código para correção.
Cenário 2: Detecção de Bugs (4 comandos)
Comando #5: Ponteiros nulos e condições de contorno
Examine os arquivos modificados recentemente em busca dos seguintes bugs potenciais:
- Acesso a propriedades sem verificar null/undefined
- Acesso a índices fora dos limites de arrays
- Erros de divisão por zero
- Strings vazias não tratadas
- parseInt/parseFloat sem tratamento para NaN
Para cada descoberta, forneça as condições de disparo (qual entrada causaria a falha) e o código de correção.
Comando #6: Problemas de assincronia e concorrência
Examine todo o código assíncrono do projeto (async/await, Promise, callbacks), verificando:
- Se há Promises sem tratamento de erro (.catch)
- Se há condições de corrida (race conditions)
- Se há await dentro de loops causando execução serial (deveria usar Promise.all)
- Se há callback hell que possa ser refatorado
- Se as transações trataram o rollback corretamente
Marque como [Arquivo:Número da linha] [Problema] [Impacto] [Solução de correção]
Comando #7: Caçador de erros lógicos
Leia atentamente a lógica de negócio das funções abaixo, procurando por:
- Se os ramos if/else cobrem todos os casos
- Se as condições de término de loops estão corretas
- Se os operadores de comparação estão corretos (== vs ===, > vs >=)
- Se o escopo das variáveis está correto
- Se o valor de retorno está definido em todos os caminhos
Não foque no estilo do código, apenas na correção lógica.
Comando #8: Revisão de tratamento de erros
Examine o mecanismo de tratamento de erros do projeto:
1. Os blocos try/catch capturam exceções específicas em vez de um Error genérico?
2. Os blocos catch apenas ignoram o erro (catch vazio)?
3. O erro é propagado corretamente para a camada superior?
4. As mensagens de erro visíveis ao usuário são amigáveis (não expõem informações internas)?
5. Operações críticas (pagamentos, alterações de dados) possuem mecanismos de rollback em caso de falha?
Ordene a saída por nível de severidade.
Cenário 3: Análise de desempenho (3 comandos)
Comando #9: Desempenho de consultas ao banco de dados
Examine todo o código de consulta ao banco de dados (models/, repositories/, chamadas ORM), verificando:
- Problemas de consulta N+1 (consultas executadas dentro de loops)
- Campos de consulta sem índice
- Se SELECT * deveria ser substituído por campos específicos
- Se consultas de grandes volumes de dados possuem paginação
- Se há consultas repetidas que podem ser otimizadas com cache
Para cada problema, estime o impacto no desempenho (baixo/médio/alto) e forneça o código otimizado.
Comando #10: Vazamento de memória e recursos
Examine possíveis vazamentos de memória e recursos no projeto:
- Se os ouvintes de eventos (event listeners) são removidos quando o componente é desmontado
- Se os temporizadores (setInterval/setTimeout) são limpos
- Se as conexões com o banco de dados são fechadas corretamente
- Se os manipuladores de arquivos são liberados no finally
- Se grandes arrays/objetos são desreferenciados após o uso
Foque especialmente na limpeza do useEffect em componentes React e no processamento de streams no Node.js.
Comando #11: Revisão de complexidade algorítmica
Examine as funções modificadas recentemente, analisando a complexidade de tempo e espaço:
- Se há implementações com complexidade O(n²) ou superior que podem ser otimizadas
- Se há locais onde tabelas hash podem substituir buscas lineares
- Se há cópias profundas (deep copies) desnecessárias
- Se a concatenação de strings deveria usar StringBuilder/join
- Se a ordenação está usando o algoritmo adequado
Marque como Complexidade atual → Complexidade otimizável → Solução de otimização específica.
Cenário 4: Revisão de Arquitetura (4 comandos)
Comando #12: Análise de dependência e acoplamento
Analise as dependências de módulo em src/:
1. Desenhe o gráfico de dependências entre módulos (qual módulo importa quais módulos)
2. Identifique dependências circulares
3. Identifique os módulos com maior acoplamento (aqueles que são mais dependidos por outros)
4. Sugira quais dependências devem ser desacopladas via interfaces/abstrações
Saída: Tabela de dependências + lista de dependências circulares + sugestões de desacoplamento
Comando #13: Verificação de conformidade de arquitetura em camadas
Verifique se o código segue os princípios de arquitetura em camadas:
- A camada Controller contém lógica de negócio? (deveria apenas fazer roteamento e validação de parâmetros)
- A camada Service opera diretamente no banco de dados? (deveria ser via Repository)
- A camada Model/Entity contém lógica relacionada a HTTP?
- Existem chamadas entre camadas cruzadas? (Controller chamando Repository diretamente)
Liste cada arquivo que viola os princípios de camadas e a localização específica do código.
Comando #14: Revisão de design de API
Sob a perspectiva das melhores práticas de design de API RESTful, revise todos os endpoints da API:
- A nomenclatura da URL segue as convenções REST (substantivos no plural, relações hierárquicas)?
- O uso dos métodos HTTP está correto (GET apenas leitura, POST criação, PUT atualização, DELETE exclusão)?
- O formato da resposta é consistente (códigos de erro, formato de paginação, formato de data)?
- O controle de versão da API está implementado?
- Existem endpoints redundantes que podem ser mesclados?
Saída: Tabela de sugestões de melhoria (Atual → Sugestão → Motivo)
Comando #15: Avaliação de dívida técnica
Realize uma avaliação abrangente da dívida técnica do projeto:
1. Pacotes de dependência e versões de framework obsoletos
2. Chamadas de API descontinuadas
3. Valores de configuração hardcoded (deveriam usar variáveis de ambiente)
4. Blocos de código duplicados (copiar e colar)
5. Módulos críticos sem testes unitários
6. Funções excessivamente complexas (complexidade ciclomática > 15)
Ordene pela urgência de correção: Bloqueante (deve ser corrigido imediatamente) > Alta > Média > Baixa
Cenário 5: Revisão de PR (4 comandos)
Comando #16: Revisão rápida de Diff de PR
Revise o diff da branch atual em relação à main e avalie como um engenheiro sênior:
1. Qual é o propósito deste PR (deduzido a partir do diff)?
2. As alterações estão completas (há arquivos ou lógicas esquecidas)?
3. Novos bugs ou regressões foram introduzidos?
4. A cobertura de testes é suficiente?
5. Existem alterações desnecessárias (código de depuração, ruído de formatação)?
Relate apenas problemas de nível Alto e Crítico. Não faça nit-picking sobre estilo de código.
Comando #17: Verificação de retrocompatibilidade
Revise todas as alterações do PR atual e verifique se há mudanças que quebram a retrocompatibilidade:
- A assinatura ou o valor de retorno de interfaces de API pública mudou?
- O esquema do banco de dados tem alguma mudança drástica (breaking change)?
- O formato do arquivo de configuração mudou?
- Funções que outros módulos estão usando foram removidas?
- O nome ou formato das variáveis de ambiente mudou?
Para cada item incompatível, avalie o escopo do impacto e o plano de migração.
Comando #18: Revisão de suficiência de testes
Compare as alterações de código do PR atual com as alterações nos testes:
1. As novas funções possuem testes unitários correspondentes?
2. A lógica modificada atualizou os testes existentes?
3. Condições de contorno e caminhos de exceção possuem cobertura de teste?
4. Os testes de integração cobrem os novos endpoints da API?
5. Os dados de teste são razoáveis (não são apenas 123, abc aleatórios)?
Liste sugestões de casos de teste ausentes: Nome da função | Cenário de teste ausente | Prioridade
Comando #19: Revisão de qualidade de Commit
Revise o histórico de commits do PR atual:
1. A mensagem de commit descreve claramente o conteúdo da alteração?
2. Cada commit é atômico (um commit para um propósito)?
3. Existem commits triviais que podem ser feitos squash?
4. Existem commits temporários como "fix typo", "wip", etc., que deveriam ser limpos?
5. A ordem dos commits segue uma lógica (primeiro infraestrutura, depois lógica de negócio)?
Sugira os commits que precisam ser organizados e a estrutura final dos commits.
Cenário 6: Legibilidade (3 comandos)
Comando #20: Revisão de Nomenclatura
Revise a nomenclatura de todas as variáveis, funções e classes nos arquivos modificados recentemente:
- Existem nomes com significado ambíguo (data, info, temp, res, obj)?
- Existem abreviações excessivas (usr → user, btn → button)?
- Existem nomes de valores booleanos que não começam com is/has/should?
- Os nomes das funções começam com verbos que descrevem o comportamento com precisão?
- Os nomes das classes começam com substantivos que descrevem a responsabilidade com precisão?
Para cada nome inadequado, sugira nomes alternativos melhores.
Comando #21: Revisão da Qualidade dos Comentários
Revise a qualidade dos comentários no código:
- Existem comentários do tipo "o quê" que deveriam ser comentários do tipo "por quê"?
- Existem comentários obsoletos (que não condizem com o código)?
- Existem comentários que deveriam ser extraídos para nomes de funções?
- Falta uma explicação em comentários para lógicas de negócio complexas?
- APIs públicas possuem JSDoc/docstring?
Não sugira adicionar comentários óbvios (como "// incrementa o contador").
Comando #22: Sugestão de Divisão de Funções
Revise todas as funções com mais de 30 linhas e avalie se devem ser divididas:
- A função possui múltiplas responsabilidades (faz várias coisas não relacionadas)?
- O nível de aninhamento excede 3 camadas?
- O número de parâmetros excede 4?
- Existe lógica repetida que pode ser extraída?
Forneça um plano de divisão específico: função original → lista de funções divididas → responsabilidade de cada função.
Cenário 7: Sugestões de Refatoração (3 comandos)
Comando #23: Detecção de Violação de DRY
Analise o código do projeto em busca de repetições:
- Identifique blocos de código repetidos com mais de 3 linhas.
- Identifique códigos com lógica semelhante, mas escrita diferente.
- Identifique padrões comuns que podem ser extraídos para funções utilitárias.
Para cada grupo de código repetido, forneça o código de implementação específico para extração como uma função comum.
Comando #24: Otimização de Padrões de Projeto
Revise o código sob a perspectiva de um especialista em padrões de projeto:
- Muitos if/else ou switch deveriam usar o padrão Strategy?
- A criação de objetos complexos deveria usar o padrão Factory/Builder?
- Código de template repetido deveria usar o padrão Template Method?
- Callbacks com múltiplos níveis de aninhamento deveriam usar o padrão Chain of Responsibility?
- O gerenciamento de estado global deveria usar o padrão Observer?
Sugira apenas se a melhoria do padrão reduzir significativamente a complexidade; evite o design excessivo.
Comando #25: Modernização de Código Legado
Revise o código legado do projeto e identifique partes que podem ser reescritas com sintaxe moderna:
- var → const/let
- Funções de callback → async/await
- Loop for → map/filter/reduce
- Concatenação de strings → template strings
- require → import
- Class → Componentes de função + Hooks (React)
Forneça uma comparação de código antes e depois da refatoração e avalie o risco da refatoração (baixo/médio/alto).
🎯 Dicas de uso: Recomendamos salvar os comandos de revisão mais usados em um arquivo
CLAUDE.mdou em.claude/skills/para padronizar na equipe. Através do/loop, você pode automatizar as revisões de segurança e PRs.
Se você estiver construindo um sistema de revisão automatizado via API, recomendamos usar o APIYI (apiyi.com) para acessar o Claude Opus 4.6 com 20% de desconto.
Perguntas Frequentes
Q1: O que fazer se o /code-review padrão for muito prolixo?
Crie um arquivo REVIEW.md na raiz do projeto ou adicione regras de revisão ao CLAUDE.md, instruindo claramente o Claude sobre o que focar e o que ignorar. Por exemplo: "Relate apenas problemas de nível Crítico e Alto. Não faça observações minuciosas sobre estilo de código ou nomenclatura. Não sugira a adição de comentários." O Claude Code lerá este arquivo automaticamente a cada revisão.
Q2: Como salvar um comando como uma Skill reutilizável?
Salve seu comando de revisão de segurança em .claude/skills/security-review/SKILL.md e defina user-invocable: true. Isso o registrará como um comando de barra /security-review. A partir daí, basta digitar /security-review para executá-lo, sem precisar copiar e colar toda vez. Você pode salvar vários comandos como Skills diferentes.
Q3: A revisão de PR pode ser postada automaticamente nos comentários do GitHub?
Sim. Existem duas maneiras: 1) Digite @claude review em um comentário de PR; o Claude analisará o diff automaticamente e publicará as descobertas como comentários inline. 2) Use o comando /code-review --comment, e o Claude publicará o resultado da revisão como um comentário no PR. Em março de 2026, a Anthropic lançou um sistema multi-agente dedicado a Code Review, capaz de coordenar um grupo de agentes especializados para revisar PRs sob diversas perspectivas, como segurança, lógica e testes.
Q4: Quantos tokens um comando de revisão consome?
Depende do escopo da revisão. Uma revisão de arquivo único consome cerca de 2.000 a 5.000 tokens, enquanto uma varredura de segurança de todo o projeto pode consumir de 10.000 a 30.000 tokens. Recomendamos limitar o escopo da revisão a arquivos ou diretórios específicos para evitar o desperdício de tokens com uma "varredura de todos os arquivos". Ao acessar o Claude Opus 4.6 via APIYI (apiyi.com) com 20% de desconto, você pode reduzir significativamente os custos de revisão.
Resumo
Pontos principais sobre os comandos de Code Review do Claude Code:
- 25 comandos cobrindo 7 cenários: Revisão de segurança (4), detecção de bugs (4), análise de desempenho (3), revisão de arquitetura (4), revisão de PR (4), legibilidade (3) e sugestões de refatoração (3) — prontos para copiar e usar.
- A fórmula dos cinco elementos para um bom comando: Papel + Escopo + Foco + Formato + Nível de severidade. Seja preciso como em um caso de teste, não vago como em uma mensagem de Slack.
- Sistema de revisão em três camadas: Comandos integrados (
/security-review) → Comandos personalizados (os 25 deste artigo) → Automação de revisão contínua com/loop.
Recomendamos acessar a API do Claude Opus 4.6 via APIYI (apiyi.com) com 20% de desconto para construir seu sistema automatizado de Code Review.
📚 Referências
-
Documentação oficial do Claude Code Code Review: Explicação completa da funcionalidade de revisão integrada
- Link:
code.claude.com/docs/en/code-review - Descrição: Inclui revisão de PR, sistemas multi-agente e métodos de personalização
- Link:
-
Claude Code Security Review: Solução oficial de revisão de segurança da Anthropic
- Link:
github.com/anthropics/claude-code-security-review - Descrição: Contém a implementação completa do comando /security-review
- Link:
-
7 comandos de revisão de PR para Claude: Comandos de revisão validados pela comunidade
- Link:
rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026 - Descrição: Inclui modelos de comando estruturados para revisão de PR
- Link:
-
Central de Documentação APIYI: Acesso ao Claude Opus 4.6 com 20% de desconto
- Link:
docs.apiyi.com - Descrição: A melhor solução de API para construir sistemas de revisão automatizados
- Link:
Autor: Equipe técnica da APIYI
Troca de conhecimentos: Sinta-se à vontade para discutir na seção de comentários. Para mais materiais, visite a central de documentação da APIYI em docs.apiyi.com
