heygrc revisa tus pull requests frente a los marcos de cumplimiento que tu empresa debe cumplir, basándose en el contexto específico de tu compañía. La configuración toma aproximadamente tres minutos y tiene una estructura deliberada: instala la aplicación de GitHub una vez y luego configura todo lo demás como código a través de una pequeña API REST, lo que significa que tu agente de codificación puede hacer la mayor parte por ti.
Esta guía cubre el flujo de principio a fin: instalación, configuración, frecuencia de revisión y la pregunta que todo ingeniero hace primero: ¿puede esto bloquear mis fusiones? El contrato exacto de la API y las cargas útiles están disponibles en https://docs.heygrc.com/docs/setup-with-an-agent y https://docs.heygrc.com/docs/api-reference; esta página es el mapa.
Paso uno: instalar la aplicación de GitHub
Instalar una aplicación de GitHub suele ser una acción del propietario de la organización o cuenta, aunque en algunas organizaciones un administrador de repositorio puede instalarla para los repositorios que gestiona. De cualquier manera, es el único paso que ningún agente o API puede hacer por ti. Desde github.com/apps/heygrc, elige tu organización o cuenta, selecciona los repositorios que deseas revisar e instala. Puedes empezar con un solo repositorio.
heygrc solicita el mínimo necesario: acceso de lectura al código, metadatos e issues, y acceso de lectura y escritura en Checks y Pull requests para poder publicar una revisión y un estado. Nunca necesita acceso de escritura a tu código, y nunca realiza commits.
Paso dos: configurar tu contexto y marcos como código
Esta es la parte que convierte a heygrc en un especialista en lugar de un linter genérico. Describes tu empresa, qué construyes, los datos que manejas, dónde alojas, las obligaciones bajo las que estás y seleccionas los marcos aplicables. Esa configuración se escribe en heygrc con una única llamada a la API. Al ser una llamada REST estándar, puedes delegar la tarea a tu agente de codificación: pide a Claude Code o Cursor que configure heygrc para tu organización con tu contexto y marcos, y realizará la llamada.
El perfil de la empresa es contexto de forma libre, y cuanto más relevante sea, más precisas serán las revisiones. heygrc inyecta tu perfil y el conocimiento de los marcos seleccionados en cada revisión, por lo que un cambio en autenticación, manejo de datos, registro o una dependencia se evalúa frente a tus controles específicos en lugar de una lista de verificación genérica. Puedes leer la configuración en cualquier momento.
Paso tres: elegir la frecuencia de revisión
heygrc admite tres modos de revisión. En automático (el predeterminado), revisa cada pull request al abrirse, reabrirse o al recibir un push. En automático-una-vez, revisa solo al abrir o reabrir, no en cada nuevo commit. En solo-mención, permanece en silencio hasta que alguien comente un comando de barra en el pull request, lo cual es útil cuando deseas revisiones bajo demanda en lugar de en cada cambio.
Estableces el modo por organización y puedes anularlo por repositorio. Las revisiones bajo demanda están restringidas a personas que sean propietarias, miembros o colaboradoras del repositorio, por lo que un comentarista ocasional no puede activarlas.
¿heygrc bloquea tus fusiones? No por sí mismo
heygrc publica su revisión como comentarios más un estado de GitHub Checks, y ese estado siempre es neutral o éxito, nunca un fallo por hallazgos. Nunca envía una revisión de solicitud de cambios. Por lo tanto, por defecto, heygrc no puede detener una fusión; informar a las personas y agentes que envían el código en lugar de interponerse entre ellos y el botón de fusión.
Hay una configuración que puede cambiar esto, y es tuya, no de heygrc. Si tu repositorio requiere la resolución de conversaciones antes de fusionar, GitHub exige que todos los hilos de revisión no resueltos, incluidos los comentarios en línea de un bot, se resuelvan primero. heygrc deja comentarios en línea anclados a la línea exacta de un hallazgo, y esos son hilos resolubles. En un repositorio con esa regla activada, resuelves cada hallazgo antes de fusionar, lo cual para un flujo de trabajo de cumplimiento suele ser deseable: es un reconocimiento ligero y registrado de que el equipo vio y abordó el impacto del control. Si no deseas esto, desactiva la regla de la rama y los comentarios de ningún revisor, ya sean de heygrc o de una persona, bloquearán una fusión.