heygrc beoordeelt je pull requests tegen de compliance-kaders die je bedrijf moet naleven, gebaseerd op de eigen context van je bedrijf. Het instellen duurt ongeveer drie minuten en heeft een bewuste opzet: installeer de GitHub App één keer en configureer daarna alles als code via een kleine REST API, wat betekent dat je codeeragent het grootste deel voor je kan doen.
Deze handleiding behandelt de volledige flow van begin tot eind: installatie, configuratie, hoe vaak het beoordeelt, plus de vraag die elke ontwikkelaar als eerste stelt: kan dit ding mijn merges blokkeren. De exacte API-contracten en payloads vind je op https://docs.heygrc.com/docs/setup-with-an-agent en https://docs.heygrc.com/docs/api-reference; deze pagina is de wegwijzer.
Stap één: installeer de GitHub App
Het installeren van een GitHub App is meestal een actie voor een organisatie- of accountbeheerder, hoewel in sommige organisaties een repo-beheerder deze voor de repositories die zij beheren kan installeren. Hoe dan ook, het is de enige stap die geen agent of API voor je kan uitvoeren. Ga naar github.com/apps/heygrc, kies je organisatie of account, selecteer de repositories die je wilt laten beoordelen en installeer. Je kunt beginnen met één repository.
heygrc vraagt om de minimale toegang die het nodig heeft: leestoegang tot code, metadata en issues, en lees- en schrijftoegang tot Checks en Pull requests, zodat het een beoordeling en een status kan plaatsen. Het heeft nooit schrijftoegang tot je code nodig en voert nooit commits uit.
Stap twee: configureer je context en kaders als code
Dit is het deel dat heygrc tot een specialist maakt in plaats van een generieke linter. Je beschrijft je bedrijf, wat je bouwt, de gegevens die je verwerkt, waar je host, de verplichtingen waaraan je onderhevig bent, en je selecteert de kaders die van toepassing zijn. Deze configuratie wordt naar heygrc geschreven met één API-aanroep. Omdat het een eenvoudige REST-aanroep is, kun je de taak overlaten aan je codeeragent: vertel Claude Code of Cursor om heygrc voor je organisatie te configureren met je context en kaders, en het voert de aanroep uit.
Het bedrijfsprofiel is vrije-vormcontext, en hoe relevanter het is, hoe scherper de beoordelingen. heygrc injecteert je profiel en de kennis voor je geselecteerde kaders in elke beoordeling, zodat een wijziging in authenticatie, gegevensverwerking, logging of een afhankelijkheid wordt beoordeeld tegenover je specifieke controles in plaats van een generieke checklist. Je kunt de configuratie op elk moment teruglezen.
Stap drie: kies hoe vaak het beoordeelt
heygrc ondersteunt drie beoordelingsmodi. In auto, de standaardmodus, beoordeelt het elke pull request wanneer deze wordt geopend, heropend of naar gepusht. In auto-once beoordeelt het alleen bij openen of heropenen, niet bij elke nieuwe commit. In mention-only blijft het stil tot iemand een slash-command in de pull request plaatst, wat handig is als je beoordelingen op aanvraag wilt in plaats van bij elke wijziging.
Je stelt de modus in per organisatie en kunt deze per repository overschrijven. Beoordelingen op aanvraag zijn beperkt tot personen die eigenaar, lid of medewerker zijn van de repo, zodat een willekeurige opmerkinggever het niet kan laten uitvoeren.
Blokkeert heygrc je merges? Niet op eigen kracht
heygrc plaatst zijn beoordeling als opmerkingen plus een GitHub Checks-status, en die status is altijd neutraal of succes, nooit een mislukking bij bevindingen. Het verzendt nooit een beoordeling met verzoek om wijzigingen. Dus standaard kan heygrc een merge niet stoppen; het informeert de mensen en agenten die de code leveren in plaats van tussen hen en de merge-knop te staan.
Er is één instelling die dit kan veranderen, en die is van jou, niet van heygrc. Als je repository vereist dat gesprekken zijn opgelost voordat er wordt gemerged, dan vereist GitHub zelf dat elke onopgeloste beoordelingsdraad, inclusief inline-opmerkingen van een bot, eerst moet worden opgelost. heygrc plaatst inline-opmerkingen gekoppeld aan de exacte regels van een bevinding, en die zijn oplosbare draden. In een repo met die regel aan, los je elke bevinding op voordat je mergt, wat voor een compliance-workflow vaak wenselijk is: het is een lichtgewicht, geregistreerde erkenning dat het team de impact van de controle heeft gezien en aangepakt. Als je dat niet wilt, schakel dan de branch-regel uit, en geen beoordelaarsopmerkingen, van heygrc of een mens, zullen een merge blokkeren.