🔍 Code Review Prompt
O Code Review Prompt transforma o Claude em um reviewer rigoroso que avalia seu codigo com os mesmos criterios de um code review profissional. Cada issue encontrada recebe uma classificacao de severidade para facilitar a priorizacao.
🎯 Template do Prompt
Faca um code review profissional dos arquivos que acabei de modificar. Para cada issue encontrada, use este formato: [SEVERITY: Critico/Alto/Medio/Baixo] [ARQUIVO:LINHA] Problema: [descricao] Sugestao: [como corrigir] Categorias a verificar: 1. CORRETUDE: Bugs, logica errada, edge cases 2. SEGURANCA: Injecao, exposicao de dados, auth bypass 3. PERFORMANCE: N+1 queries, loops desnecessarios, memory leaks 4. MANUTENCAO: Codigo duplicado, complexidade desnecessaria, naming 5. TESTES: Cobertura insuficiente, testes frageis, mocks excessivos 6. PADROES: Violacoes das convencoes do projeto (ver CLAUDE.md) No final, de uma nota geral: APROVADO / APROVADO COM RESSALVAS / REPROVADO
💡 Dica Pratica
Use git diff --staged antes do review para que o Claude veja exatamente o que sera commitado. Isso foca o review apenas nas mudancas, nao no codigo inteiro.
✓ O que FAZER
- ✓Rodar review antes de cada PR ou commit importante
- ✓Corrigir todos os itens Critico e Alto antes de merge
- ✓Usar a nota final como gate de qualidade
✗ O que NAO fazer
- ✗Ignorar issues marcadas como Critico
- ✗Fazer merge com status "REPROVADO"
- ✗Usar review como substituto de testes automatizados
🛡️ Refactor Guardrails
O Refactor Guardrails e o prompt que garante que refatoracoes nao quebrem o comportamento existente. A regra de ouro e: refatoracao NUNCA muda comportamento, apenas melhora estrutura.
🎯 Template do Prompt
Refatore [AREA/ARQUIVO] com estas guardrails obrigatorias: REGRA #1: ZERO mudanca de comportamento. O output deve ser identico. REGRA #2: Testes existentes DEVEM continuar passando sem modificacao. REGRA #3: Se precisar mudar uma interface publica, PARE e me avise. Processo: 1. Liste o que sera refatorado e POR QUE (motivo tecnico) 2. Para cada mudanca, explique: [ANTES] → [DEPOIS] → [POR QUE e melhor] 3. Rode os testes apos cada mudanca incremental 4. Se algum teste falhar, REVERTA e me avise Tipo de refatoracao: [extrair funcao | renomear | simplificar | remover duplicacao]
💡 Dica Pratica
A regra "ZERO mudanca de comportamento" e a guardrail mais importante. Se o Claude diz "precisei ajustar o comportamento para melhorar", isso NAO e refatoracao - e uma mudanca funcional. Insista na separacao.
⚡ Sistema de Severity Ratings
O sistema de severity ratings padroniza como o Claude classifica problemas encontrados em reviews. Usar a mesma escala consistentemente permite comparar qualidade entre sessoes e medir progresso.
🎯 Escala de Severidade
💡 Dica Pratica
Coloque essa escala no CLAUDE.md para que o Claude use a mesma classificacao em todo review. Isso cria consistencia e permite rastrear metricas de qualidade ao longo do tempo.
🔒 Principio No-Behavior-Change
O principio No-Behavior-Change e a guardrail mais importante para refatoracoes seguras. Ele garante que qualquer mudanca estrutural preserve o comportamento externo identico. Se o output muda, nao e refatoracao.
🎯 Como Garantir No-Behavior-Change
Para QUALQUER refatoracao, siga esta verificacao: ANTES de refatorar: 1. Rode todos os testes - anote os resultados 2. Capture o output de endpoints/funcoes criticas 3. Documente o estado atual DURANTE a refatoracao: 4. Faca mudancas incrementais (1 por commit) 5. Rode testes apos CADA mudanca 6. Se um teste falhou → REVERTA → investigue DEPOIS de refatorar: 7. Rode todos os testes - compare com resultados iniciais 8. Compare outputs dos endpoints/funcoes criticas 9. Se qualquer output mudou → investigue antes de commitar
💡 Dica Pratica
Use git stash antes de refatorar e compare o output antes/depois. Se houver diferenca, o stash permite voltar instantaneamente ao estado anterior.
📝 Edicoes Incrementais
Edicoes incrementais sao a pratica de pedir ao Claude que faca mudancas pequenas e verificaveis em vez de reescritas massivas. Cada edicao e um passo commitavel que pode ser revertido independentemente.
🎯 Template do Prompt
Melhore este codigo em edicoes incrementais. Cada edicao deve ser: - Uma unica mudanca logica (nao misture rename com refactor) - Commitavel isoladamente - Verificavel com testes existentes Edicao 1: [descreva a mudanca] → PARE Edicao 2: [descreva a mudanca] → PARE ... Para cada edicao, mostre APENAS o diff (o que mudou), nao o arquivo inteiro. Espere meu "ok" entre edicoes.
💡 Dica Pratica
Pedir "apenas o diff" economiza tokens significativamente e facilita o review. Voce ve exatamente o que mudou sem precisar comparar arquivos inteiros mentalmente.
📋 Review Checklist Completa
A Review Checklist e uma lista definitiva que voce pode adicionar ao CLAUDE.md para que o Claude verifique automaticamente antes de considerar qualquer tarefa como concluida.
🎯 Checklist para CLAUDE.md
# Review Checklist Obrigatoria ## Corretude - [ ] Todos os testes passam - [ ] Edge cases tratados (null, empty, overflow) - [ ] Error handling em todos os pontos de falha ## Seguranca - [ ] Inputs validados e sanitizados - [ ] Sem segredos hardcoded (use env vars) - [ ] Auth verificada em rotas protegidas ## Performance - [ ] Sem N+1 queries - [ ] Sem loops desnecessarios ou duplicados - [ ] Recursos liberados (connections, files, streams) ## Manutencao - [ ] Naming claro e consistente com o projeto - [ ] Sem codigo morto ou comentado - [ ] Funcoes com responsabilidade unica ## Padroes - [ ] Segue convencoes do CLAUDE.md - [ ] Imports organizados - [ ] Sem TODO/FIXME sem issue associada
💡 Dica Pratica
Customize essa checklist para o seu projeto. Adicione itens especificos do seu stack (ex: para React: "sem re-renders desnecessarios", para APIs: "rate limiting configurado"). A checklist mais eficaz e a que reflete os problemas reais do seu projeto.
📋 Resumo do Modulo
Proximo Modulo:
4.6 - Prompts de Arquitetura