O que o HeyDeer lê
Uma revisão lê as alterações do pull request no contexto do repositório inteiro, junto com a discussão do PR e as orientações que você dá ao HeyDeer. Esta página mostra onde cada tipo de orientação deve ficar e qual delas um pull request pode alterar.
O código e a discussão
O HeyDeer revisa o que o pull request altera e pode ler e pesquisar qualquer arquivo no head do PR e no histórico de commits. Um problema encontrado pode apontar para código fora do diff que a alteração quebra.
Ele também lê o título, a descrição e a discussão do PR.
Issues e pull requests relacionados
Com Ler issues e PRs relacionados ativado (o padrão), o HeyDeer pode ler issues e pull requests do mesmo repositório quando eles explicam a alteração, como uma issue que o PR corrige. Altere essa opção em Regras de revisão → Como revisar; consulte Referência de configurações.
Onde cada tipo de orientação deve ficar
Você não precisa de nenhuma orientação para começar: o HeyDeer revisa com base no repositório inteiro desde a primeira revisão. Adicione orientações para as lacunas que suas primeiras revisões mostrarem.
Escreva só o que é específico do seu código. O HeyDeer já conhece as práticas comuns de engenharia, e toda revisão procura bugs e problemas de segurança, então orientações que repetem isso não acrescentam nada.
| O que você quer dizer ao HeyDeer | Coloque em |
|---|---|
| Como seu código funciona e as convenções que ele segue. Os agentes de código também as seguem. | AGENTS.md |
| O que as revisões devem procurar, o que devem ignorar e qual a gravidade de um problema | REVIEW.md |
| Um requisito que o HeyDeer precisa verificar em todo pull request que altera determinados arquivos | .agents/checks/ |
| Um procedimento que várias verificações compartilham | .agents/skills/ |
| Orientações de revisão que um pull request não pode alterar, ou que valem para todos os repositórios | Instruções de revisão |
| Contexto fora do repositório, como tickets ou documentos internos | Conectores |
Uma verificação ou o REVIEW.md
As revisões seguem o AGENTS.md e o REVIEW.md enquanto examinam a mudança inteira. Além disso, cada verificação correspondente tem um revisor próprio, que verifica só aquele requisito, então uma verificação é mais minuciosa, mas usa mais créditos.
Transforme em verificação um requisito caro de deixar passar e fácil de ignorar, como o controle de acesso das suas rotas de API. Coloque o resto no REVIEW.md. Veja Escrever uma verificação eficaz.
Quando as orientações entram em conflito
As instruções de revisão têm precedência sobre o REVIEW.md, o AGENTS.md, o CLAUDE.md e as skills, e as instruções do repositório têm precedência sobre as instruções do espaço de trabalho. Nem as instruções nem nada no repositório podem impedir que uma verificação do repositório correspondente seja executada.
Se o HeyDeer parecer ignorar suas orientações, consulte Solução de problemas.
O que um pull request pode alterar
O HeyDeer lê o AGENTS.md, o CLAUDE.md, o REVIEW.md, as verificações do repositório e as skills a partir do commit head do pull request. Um pull request que os edita é revisado com a versão que ele mesmo contém, então pode alterar as orientações usadas para revisá-lo. O HeyDeer nunca aprova automaticamente um pull request assim.
As instruções de revisão e os conectores ficam salvos no HeyDeer, então um pull request não pode alterá-los. Coloque nas instruções de revisão as orientações que um pull request não deve poder alterar.
O HeyDeer lê o .gitattributes da branch base, então um pull request não pode marcar os próprios arquivos como gerados para deixá-los fora da revisão. Para saber onde fica cada configuração e quem pode alterá-la, consulte Referência de configurações.
Arquivos gerados
No .gitattributes, marque como linguist-generated os arquivos gerados, como clientes gerados. O HeyDeer os ignora nas revisões e nas verificações do repositório, e lê o atributo da branch base.
Os lockfiles que a branch base já tem são ignorados sem precisar de atributo. Para revisar um, marque-o como -linguist-generated. O HeyDeer trata estes nomes de arquivo como lockfiles em qualquer pasta: package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bun.lock, bun.lockb, deno.lock, Cargo.lock, go.sum, Gemfile.lock, composer.lock, poetry.lock, Pipfile.lock, uv.lock, pdm.lock, pubspec.lock, Podfile.lock, Package.resolved, mix.lock, packages.lock.json, gradle.lockfile, flake.lock, MODULE.bazel.lock, .terraform.lock.hcl
# .gitattributes
src/generated/** linguist-generated
# Review this lock file anyway
Cargo.lock -linguist-generatedQuando todos os arquivos alterados são ignorados, a verificação HeyDeer Review mostra Nenhum arquivo para revisar e nenhum crédito é usado.
O que o HeyDeer deixa de fora
Além dos arquivos gerados, o HeyDeer não lê:
- Issues e pull requests de outros repositórios.
- Arquivos importados pelo AGENTS.md ou pelo CLAUDE.md. Consulte AGENTS.md.
- Configurações de agentes no repositório, como
.claude/settings.json,.mcp.jsonou hooks. Para dar às revisões contexto de fora do repositório, use conectores. - A saída do seu código. O HeyDeer lê o código e os testes, mas não os compila nem os executa.
O HeyDeer mantém o contexto da discussão dentro de cerca de 180 KB e 200 conversas sobre o código. Primeiro deixa de fora revisões antigas e conversas resolvidas e, se necessário, outras partes da discussão. Uma discussão extensa não impede a revisão.
Para ver os limites de tamanho do AGENTS.md, das verificações do repositório, das skills, das instruções de revisão e dos conectores, consulte Referência de configurações.