Qué lee HeyDeer
Una revisión lee los cambios del pull request en el contexto de todo el repositorio, junto con la discusión del PR y las pautas que le das a HeyDeer. Esta página muestra dónde va cada tipo de pauta y cuáles puede cambiar un pull request.
El código y la discusión
HeyDeer revisa lo que cambia el pull request y puede leer y buscar en cualquier archivo del commit más reciente del PR y en el historial de commits. Un hallazgo puede señalar código fuera del diff que el cambio rompe.
También lee el título, la descripción y la discusión del PR.
Issues y pull requests relacionados
Con Leer issues y PR relacionados activado, la opción predeterminada, HeyDeer puede leer issues y pull requests del mismo repositorio cuando explican el cambio, como un issue que el PR corrige. Cámbialo en Reglas de revisión → Cómo revisar; consulta la Referencia de configuración.
Dónde va cada tipo de pauta
No necesitas ninguna pauta para empezar: HeyDeer revisa teniendo en cuenta todo el repositorio desde la primera revisión. Añade pautas para cubrir las carencias que muestren tus primeras revisiones.
Escribe solo lo que es propio de tu código. HeyDeer ya conoce las prácticas de ingeniería habituales, y cada revisión busca errores y problemas de seguridad, así que las indicaciones que los repiten no aportan nada.
| Qué quieres decirle a HeyDeer | Ponlo en |
|---|---|
| Cómo funciona tu código y qué convenciones sigue. Los agentes de programación también las siguen. | AGENTS.md |
| Qué deben buscar las revisiones, qué deben dejar pasar y qué gravedad tiene un problema | REVIEW.md |
| Un requisito que HeyDeer debe verificar en cada pull request que cambie ciertos archivos | .agents/checks/ |
| Un procedimiento que comparten varias comprobaciones | .agents/skills/ |
| Indicaciones de revisión que un pull request no debe poder cambiar, o que se aplican a todos los repositorios | Instrucciones de revisión |
| Contexto fuera del repositorio, como tickets o documentación interna | Conectores |
¿Una comprobación o REVIEW.md?
Las revisiones siguen AGENTS.md y REVIEW.md mientras examinan todo el cambio. Además, cada comprobación aplicable tiene su propio revisor, que verifica solo ese requisito, así que una comprobación es más exhaustiva pero usa más créditos.
Convierte en comprobación un requisito fácil de pasar por alto y caro si se pasa por alto, como el control de acceso de tus rutas de API. Pon el resto en REVIEW.md. Consulta Escribir una comprobación eficaz.
Cuando las pautas se contradicen
Las instrucciones de revisión prevalecen sobre REVIEW.md, AGENTS.md, CLAUDE.md y las skills, y las instrucciones del repositorio prevalecen sobre las del espacio de trabajo. Ni las instrucciones ni nada del repositorio pueden impedir que se ejecute una comprobación del repositorio aplicable.
Si parece que HeyDeer ignora tus pautas, consulta Solución de problemas.
Qué puede cambiar un pull request
HeyDeer lee AGENTS.md, CLAUDE.md, REVIEW.md, las comprobaciones del repositorio y las skills del commit más reciente del pull request. Un pull request que los modifica se revisa con su propia versión, así que puede cambiar las pautas con las que se revisa. HeyDeer nunca aprueba automáticamente un pull request así.
Las instrucciones de revisión y los conectores se guardan en HeyDeer, así que un pull request no puede cambiarlos. Pon en las instrucciones de revisión las pautas que un pull request no debe poder cambiar.
HeyDeer lee .gitattributes de la rama base, así que un pull request no puede marcar sus propios archivos como generados para dejarlos fuera de la revisión. Para saber dónde se guarda cada configuración y quién puede cambiarla, consulta la Referencia de configuración.
Archivos generados
Marca los archivos generados, como los clientes generados, con linguist-generated en .gitattributes. HeyDeer los omite en las revisiones y en las comprobaciones del repositorio, y lee el atributo de la rama base.
Los archivos de bloqueo que la rama base ya tiene se omiten sin necesidad de un atributo. Para revisar uno, márcalo con -linguist-generated. HeyDeer trata estos nombres de archivo como archivos de bloqueo en cualquier carpeta: 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-generatedCuando se omiten todos los archivos modificados, la comprobación HeyDeer Review muestra No hay archivos para revisar y no se usan créditos.
Qué deja fuera HeyDeer
Además de los archivos generados, HeyDeer no lee:
- Issues y pull requests de otros repositorios.
- Archivos importados desde AGENTS.md o CLAUDE.md. Consulta AGENTS.md.
- La configuración de agentes del repositorio, como
.claude/settings.json,.mcp.jsono hooks. Para dar a las revisiones contexto externo, usa conectores. - La salida de tu código. HeyDeer lee el código y las pruebas, pero no los compila ni los ejecuta.
HeyDeer mantiene el contexto de la discusión dentro de unos 180 KB y 200 conversaciones sobre el código. Omite primero las revisiones antiguas y las conversaciones resueltas, y después otras partes de la discusión si hace falta. Una discusión extensa no impide la revisión.
Para conocer los límites de tamaño de AGENTS.md, las comprobaciones del repositorio, las skills, las instrucciones de revisión y los conectores, consulta la Referencia de configuración.