Buenas prácticas
Dónde va cada regla
Elige dónde poner una regla según para qué sirve y quién debería poder cambiarla.
Elige un lugar
| Qué quieres decirle a HeyDeer | Ponlo en | Dónde lo lee HeyDeer |
|---|---|---|
| Convenciones del equipo y contexto del proyecto: estructura, nombres, qué utilidades usar | AGENTS.md | El pull request. Un archivo anidado se aplica a su directorio. |
| Una regla que debe cumplir cada pull request que toque ciertos archivos | .agents/checks/ | La rama base |
| Un método o conocimiento del dominio que comparten varias comprobaciones | .agents/skills/ | El pull request |
| Prioridades de revisión, qué dejar tal cual y tono para todos los repositorios | Instrucciones de la organización | Configuración de la organización → Instrucciones de revisión |
| Lo mismo para un repositorio | Instrucciones del repositorio | Repositorios → (un repositorio) → Instrucciones de revisión |
| Contexto fuera del repositorio, como tickets o documentación interna | Servidores MCP | Configuración de la organización → Servidores MCP, o los Servidores MCP de un repositorio |
| Qué pull requests se revisan automáticamente | Filtros de revisión automática | Reglas de revisión |
| Cuántos hallazgos se publican | Alcance de los comentarios | Reglas de revisión |
| El idioma en el que escribe HeyDeer | Idioma de la revisión | Reglas de revisión |
Las instrucciones de revisión prevalecen sobre AGENTS.md cuando ambos entran en conflicto.
Rama base o pull request
Las comprobaciones vienen de la rama base, así que un pull request no puede debilitar una comprobación que sus propios cambios incumplirían. Una comprobación nueva se aplica a los pull requests revisados después de fusionarla.
AGENTS.md y las skills vienen del pull request, así que siempre coinciden con el código revisado, y cualquiera que abra un pull request puede editarlos. Pon en una comprobación o en las instrucciones de revisión las reglas que deben cumplirse diga lo que diga un pull request.