Las cinco primeras tablas siguen las secciones de Configuración del espacio de trabajo → Reglas de revisión. Los valores predeterminados son los que tiene un espacio de trabajo nuevo, y cada ajuste enlaza a la página que lo explica. Un repositorio sigue el valor del espacio de trabajo hasta que lo personalizas; consulta Cómo funciona la configuración.
Cuándo revisar
| Ajuste | Predeterminado | Qué hace |
|---|
| Frecuencia de revisión | Solo manual | Si HeyDeer revisa los pull requests por su cuenta: Una vez por PR, En cada push o Solo manual. |
| Máximo de revisiones automáticas por PR | 5 | Con En cada push, deja de revisar automáticamente un pull request tras este número de revisiones completadas correctamente: 1, 2, 3, 5, 10, 20 o Sin límite. |
| Detener las revisiones automáticas cuando se cierre un PR | Activada | Detiene las revisiones automáticas en cola y en curso cuando un pull request se cierra o se fusiona. |
| Filtros de revisión automática | Estado del PR → No es borrador, Origen del PR → Es cualquiera de → Mismo repositorio, y Autor → No es ninguno de → dependabot[bot], renovate[bot], pre-commit-ci[bot], snyk-io[bot], snyk-bot | Qué pull requests abarcan las revisiones automáticas, según las etiquetas, el autor, el equipo, el tipo de cuenta, el estado de borrador y el origen. Un pull request debe coincidir con todas las filas. |
Cómo revisar
| Ajuste | Predeterminado | Qué hace |
|---|
| Profundidad de revisión predeterminada | Estándar | Estándar o Profunda. La revisión Profunda dedica más tiempo a cada paso, usa más créditos y requiere un plan de pago. |
| Revisar solo los cambios nuevos | Activada | Las revisiones siguientes solo cubren lo que cambió desde la última y vuelven a comprobar los problemas anteriores. |
| Alcance de los comentarios | Equilibrado | Qué hallazgos comunica HeyDeer, según la confianza y la gravedad: Conciso, Equilibrado o Detallado. |
| Idioma de la revisión | English | El idioma de todo lo que HeyDeer publica en GitHub, incluidos los hallazgos, la comprobación HeyDeer Review y las respuestas a comandos: English, 简体中文, 日本語, Español, 한국어, Português (Brasil), Deutsch. El código y las rutas de archivo se mantienen tal cual. |
| Leer issues y PR relacionados | Activada | Permite que HeyDeer lea issues y pull requests del mismo repositorio que explican el cambio. |
| Recorrido | Activada | Añade una guía del cambio: agrupa las ediciones relacionadas y destaca las importantes. |
| Conservar una instantánea del repositorio | Activada | Las revisiones de repositorios grandes empiezan más rápido a partir de una instantánea de su rama predeterminada. La instantánea se elimina un día después de su último uso o cuando desactivas esta opción. |
Publicar resultados
| Ajuste | Predeterminado | Qué hace |
|---|
| Aprobación automática | Desactivada | Permite que HeyDeer apruebe los pull requests que cumplen las dos condiciones siguientes. Solo funciona mientras Publicar comentarios de revisión en el PR está activado. |
| PR que HeyDeer puede aprobar | PR de riesgo bajo y medio | El nivel de riesgo más alto que aprueba HeyDeer: PR de riesgo bajo, PR de riesgo bajo y medio o PR de cualquier nivel de riesgo. |
| Problemas que pueden quedar pendientes | Ningún problema pendiente | Si HeyDeer puede aprobar aunque queden hallazgos o problemas anteriores de gravedad baja: Ningún problema pendiente o Permitir problemas de gravedad baja. |
| Publicar comprobación de GitHub | Activada | Muestra el progreso y los resultados de la revisión en la comprobación HeyDeer Review. |
| Marcar la comprobación como fallida si se detectan problemas | Desactivada | Marca la comprobación como fallida si hay hallazgos, problemas anteriores abiertos o sin confirmar, o revisiones incompletas. Solo se aplica mientras Publicar comprobación de GitHub está activado. |
| Publicar comentarios de revisión en el PR | Activada | Publica cada revisión en el pull request. Desactivarlo también desactiva la aprobación automática y la resolución de conversaciones. |
| Marcar como resueltas las conversaciones de HeyDeer atendidas | Activada | Resuelve las conversaciones de HeyDeer cuando una revisión posterior comprueba que el problema está corregido o acepta una decisión de no actuar. |
Acceso a revisiones manuales
| Ajuste | Predeterminado | Qué hace |
|---|
| Quién puede solicitar revisiones | Cualquiera con acceso de escritura al repositorio | Quién puede solicitar revisiones a HeyDeer, en comentarios del PR o desde la comprobación. La otra opción, Usuarios o equipos seleccionados con acceso de escritura, admite hasta 100 nombres de usuario y, en organizaciones, 30 equipos. |
Configurado en HeyDeer
Una revisión usa las reglas de revisión, las instrucciones y los conectores guardados cuando HeyDeer la pone en cola. Un pull request no puede cambiarlos.
| Configuración | Dónde | Quién puede cambiarla | Reglas y límites |
|---|
| Reglas de revisión | Configuración del espacio de trabajo → Reglas de revisión, o Repositorios → (un repositorio) → Reglas de revisión | Administradores del espacio de trabajo | Un repositorio sigue cada valor predeterminado del espacio de trabajo hasta que lo personalizas. |
| Instrucciones de revisión | Configuración del espacio de trabajo → Instrucciones de revisión, o Repositorios → (un repositorio) → Instrucciones de revisión | Administradores del espacio de trabajo | Texto sin formato o Markdown, hasta 12.000 caracteres en cada nivel. Las instrucciones del repositorio prevalecen en caso de conflicto. |
| Conectores | Configuración del espacio de trabajo → Conectores | Los administradores del espacio de trabajo que también son propietarios de la organización o la cuenta de GitHub | Los conectores están incluidos en los planes de pago. Hasta 50 por espacio de trabajo, cada uno un servidor Streamable HTTP en un punto final HTTPS público. |
Los administradores solo pueden cambiar la configuración de un repositorio si tienen acceso a él en GitHub. Consulta Miembros del espacio de trabajo.
Archivos del repositorio
HeyDeer también lee estos archivos del repositorio que se revisa. Cualquiera que pueda subir cambios a la rama de un pull request puede cambiar los archivos que se leen de ella; consulta Qué puede cambiar un pull request.
| Archivo | Se lee desde | Reglas y límites |
|---|
AGENTS.md, CLAUDE.md | La propia versión del pull request | Cualquier directorio. Se aplica a su directorio y sus subdirectorios; prevalecen los archivos más profundos. En los directorios sin AGENTS.md se lee CLAUDE.md. Hasta 32 KiB en total desde la raíz hasta un directorio; el resto se omite. |
REVIEW.md | La propia versión del pull request | Cualquier directorio. Se aplica a los cambios de su directorio y sus subdirectorios; prevalecen los archivos más profundos. No se lee un enlace simbólico. |
.agents/checks/*.md | La propia versión del pull request | Un archivo Markdown por comprobación, directamente en .agents/checks, con files en su frontmatter. Los nombres empiezan por una letra o un dígito y usan letras, dígitos, ., _ y -. Hasta 16.000 bytes por archivo. Una revisión ejecuta como máximo 10 comprobaciones aplicables, por orden de nombre de archivo. |
.agents/skills/ | La propia versión del pull request | Se usa cuando una comprobación la incluye. Cada skill es una carpeta con un SKILL.md, con un nombre de hasta 64 caracteres formado por letras minúsculas, dígitos y guiones simples. |
.gitattributes | La rama base | Los archivos marcados como linguist-generated, y los archivos de bloqueo que ya tiene salvo que estén marcados como -linguist-generated, se excluyen de la revisión. Cualquiera que pueda fusionar en la rama base puede cambiarlo. |
Frontmatter de las comprobaciones
Cada comprobación empieza con un frontmatter YAML entre dos líneas ---. HeyDeer ignora las demás claves.
| Clave | Valor | Efecto |
|---|
files | Un patrón o una lista de patrones | Obligatorio; sin esta clave, HeyDeer ignora el archivo. Los archivos modificados que abarca la comprobación. Pon ! delante de un patrón para excluir archivos; las exclusiones requieren al menos un patrón de inclusión. |
skills | Un nombre de skill o una lista de nombres | Opcional. Skills que usa la comprobación, cargadas desde el pull request. Si falta una skill, la revisión no se detiene. |
