Revisão Pré-Push
Simule o trabalho de revisão automatizada de CI localmente antes de fazer push ou abrir um PR.
Como funciona
Os critérios de revisão são definidos no workflow de CI, não duplicados aqui. Leia o prompt de revisão diretamente da fonte da verdade:
.github/workflows/bots.yml— encontre o campoprompt:do jobreview(o bloco YAML iniciando comReview this pull request). Este contém os critérios completos de revisão, prioridades e diretrizes que o CI usa.
Adapte esses critérios para uma revisão local (pré-PR) conforme descrito abaixo.
Passos
1. Leia o prompt de revisão do CI
Leia .github/workflows/bots.yml e extraia o prompt de revisão do
passo anthropics/claude-code-action no job review. Esta é sua referência principal
para o que procurar e como priorizar os achados.
2. Reúna o contexto local
Como ainda não há PR, reúna o contexto equivalente localmente:
# Determine a branch base (padrão: main)
git merge-base main HEAD
# Arquivos alterados
git diff main...HEAD --stat
# Diffs com contexto de função (mesmo flag -W usado pelo script de CI)
git diff main...HEAD -W
Para o diff, leia em partes gerenciáveis — não tente carregar tudo de uma vez
se for grande. Priorize arquivos de "implementação principal" sobre testes e arquivos gerados
(como uv.lock e cassetes).
3. Leia arquivos AGENTS.md relevantes
Leia o CLAUDE.md raiz (já está no seu prompt de sistema) mais quaisquer arquivos
AGENTS.md específicos de diretórios que contenham arquivos alterados. O script de CI verifica
estes caminhos:
docs/AGENTS.mdpydantic_ai_slim/pydantic_ai/models/AGENTS.mdtests/AGENTS.md
Leia apenas os relevantes para os diretórios alterados.
4. Revise
Aplique os critérios de revisão do prompt de CI, com estas adaptações locais:
- Pule verificações específicas de PR: sem descrição de PR, issues vinculadas, verificações de PR duplicado ou comentários de revisão anteriores a considerar.
- Pule a verificação "este PR deveria existir": assuma que o usuário pretende fazer essas alterações.
- Produza achados como texto em vez de postar comentários inline.
Áreas de foco (em ordem de prioridade, conforme o prompt de CI):
- API pública — abstrações, hierarquia de classes, assinaturas de métodos, segurança de tipos, compatibilidade retroativa
- Conceitos e comportamento — decisões de design, trade-offs que precisam de discussão
- Documentação — tom, padrões, completeza
- Testes — cobertura, estilo, integração vs unitários
- Estilo de código — conformidade com regras do AGENTS.md, Python idiomático
Se houver problemas de alto nível que exijam retrabalho significativo, foque neles e segure os detalhes de nível inferior.
5. Apresente os achados
Organize os achados por nível de prioridade. Para cada achado:
- Referencie o arquivo e linha específicos (
file:line) - Explique o problema de forma concisa
- Sugira uma correção, se apropriado
Se não houver achados, diga isso.
Qualidade do comentário
Cada achado deve merecer seu lugar. Sua revisão nunca deve adicionar ruído:
- Apenas acionável: cada achado deve solicitar uma alteração específica, sinalizar uma preocupação que precisa de discussão ou sugerir uma melhoria concreta. Não comente aspectos positivos ("design excelente", "boa escolha") — isso é ruído.
- Conciso: 1 a 3 frases por achado é quase sempre suficiente. Sem listas desnecessárias, subtítulos ou emojis.
- Não repetitivo: não sinalize o mesmo problema várias vezes, a menos que apareça em contextos significativamente diferentes.
- Sem enchimento: não encha a revisão com observações que não exigem ação. Se uma escolha está correta, não a mencione. Se o código segue os padrões do projeto, não o elogie. Foque exclusivamente no que precisa mudar ou ser discutido.
- Amigável, mas não bajulador: use o tom de um mantenedor de projeto prestativo. Sem elogios, sem "ótimo trabalho", apenas feedback claro e direto.
Se houver problemas de alto nível que exijam retrabalho significativo, foque neles e pule completamente os detalhes de nível inferior — eles precisarão ser revisitados de qualquer forma.