heygrc prüft deine Pull Requests gegen die Compliance-Frameworks, die dein Unternehmen erfüllen muss, basierend auf deinem eigenen Unternehmenskontext. Die Einrichtung dauert etwa drei Minuten und folgt einem klaren Ablauf: Installiere die GitHub-App einmal, dann konfiguriere alles andere als Code über eine kleine REST-API. Das bedeutet, dass dein Coding-Agent den Großteil für dich übernehmen kann.
Diese Anleitung behandelt den gesamten Ablauf von der Installation über die Konfiguration bis hin zur Häufigkeit der Reviews und beantwortet die Frage, die jeder Entwickler zuerst stellt: Kann dieses Tool meine Merges blockieren? Der genaue API-Vertrag und die Payloads findest du unter https://docs.heygrc.com/docs/setup-with-an-agent und https://docs.heygrc.com/docs/api-reference. Diese Seite dient als Übersicht.
Schritt eins: GitHub-App installieren
Die Installation einer GitHub-App ist in der Regel eine Aktion für Org- oder Account-Besitzer, obwohl in einigen Orgs ein Repo-Admin sie für die von ihm verwalteten Repositories installieren kann. In jedem Fall ist dies der einzige Schritt, den kein Agent oder keine API für dich übernehmen kann. Gehe zu github.com/apps/heygrc, wähle deine Org oder dein Account, wähle die Repositories aus, die du prüfen lassen möchtest, und installiere die App. Du kannst mit einem einzelnen Repository beginnen.
heygrc fragt nur die minimalen Berechtigungen an: Lesezugriff auf Code, Metadaten und Issues sowie Lese- und Schreibzugriff auf Checks und Pull Requests, um Reviews und Status zu posten. Es benötigt niemals Schreibzugriff auf deinen Code und führt niemals Commits aus.
Schritt zwei: Kontext und Frameworks als Code konfigurieren
Dies ist der Teil, der heygrc zu einem Spezialisten und nicht zu einem generischen Linter macht. Du beschreibst dein Unternehmen, was du entwickelst, welche Daten du verarbeitest, wo du hostest, welchen Verpflichtungen du unterliegst, und wählst die relevanten Frameworks aus. Diese Konfiguration wird mit einem einzigen API-Aufruf an heygrc übermittelt. Da es sich um einen einfachen REST-Aufruf handelt, kannst du die Aufgabe an deinen Coding-Agent delegieren: Sage Claude Code oder Cursor, sie sollen heygrc für deine Org mit deinem Kontext und deinen Frameworks konfigurieren, und sie führen den Aufruf aus.
Das Unternehmensprofil ist ein freier Kontext, und je relevanter es ist, desto präziser sind die Reviews. heygrc integriert dein Profil und das Wissen zu den ausgewählten Frameworks in jedes Review. So wird eine Änderung an Authentifizierung, Datenverarbeitung, Logging oder einer Abhängigkeit gegen deine spezifischen Kontrollen und nicht gegen eine generische Checkliste geprüft. Du kannst die Konfiguration jederzeit abrufen.
Schritt drei: Häufigkeit der Reviews festlegen
heygrc unterstützt drei Review-Modi. Im Modus auto (Standard) wird jeder Pull Request bei Öffnung, erneuter Öffnung oder Push geprüft. Im Modus auto-once wird nur bei Öffnung oder erneuter Öffnung geprüft, nicht bei jedem neuen Commit. Im Modus mention-only bleibt heygrc still, bis jemand einen Slash-Befehl als Kommentar zum Pull Request hinzufügt. Dies ist nützlich, wenn du Reviews auf Anfrage und nicht bei jeder Änderung durchführen möchtest.
Du legst den Modus pro Organisation fest und kannst ihn pro Repository überschreiben. On-Demand-Reviews sind auf Personen beschränkt, die Owner, Member oder Collaborator des Repos sind. Ein zufälliger Kommentator kann sie nicht auslösen.
Blockiert heygrc deine Merges? Nicht eigenständig
heygrc postet sein Review als Kommentare sowie einen GitHub-Checks-Status, und dieser Status ist immer neutral oder erfolgreich, niemals ein Fehler bei Befunden. Es sendet niemals ein Review mit der Anforderung nach Änderungen. Daher kann heygrc standardmäßig keinen Merge blockieren. Es informiert die Personen und Agenten, die den Code bereitstellen, statt sich zwischen sie und die Merge-Schaltfläche zu stellen.
Es gibt eine Einstellung, die dies ändern kann, und diese liegt in deiner Hand, nicht bei heygrc. Wenn dein Repository die Auflösung von Gesprächen vor dem Merge erfordert, verlangt GitHub selbst, dass alle nicht aufgelösten Review-Threads, einschließlich der Inline-Kommentare eines Bots, zuerst aufgelöst werden müssen. heygrc hinterlässt zeilenbezogene Inline-Kommentare genau an den Zeilen eines Befunds, und diese sind auflösbare Threads. In einem Repo mit dieser Regel musst du jeden Befund vor dem Merge auflösen. Für einen Compliance-Workflow ist dies oft wünschenswert: Es ist eine leichte, dokumentierte Bestätigung, dass das Team die Auswirkungen auf die Kontrollen gesehen und behandelt hat. Wenn du das nicht möchtest, deaktiviere die Branch-Regel, und keine Review-Kommentare, weder von heygrc noch von einem Menschen, werden einen Merge blockieren.