heygrc reviews your pull requests against the compliance frameworks your company must meet, grounded in your own company context. Setting it up takes about three minutes and has a deliberate shape: install the GitHub App once, then configure everything else as code through a small REST API, which means your coding agent can do most of it for you.
This walkthrough covers the flow end to end, install, configuration, and how often it reviews, plus the question every engineer asks first: can this thing block my merges. The exact API contract and payloads live in the heygrc docs and API reference; this page is the map.
Step one: install the GitHub App
Installing a GitHub App is usually an org or account owner action, though in some orgs a repo admin can install it for repositories they administer. Either way it is the one step no agent or API can do for you. From github.com/apps/heygrc, choose your org or account, select the repositories you want reviewed, and install. You can start with a single repository.
heygrc asks for the minimum it needs: read access to code, metadata, and issues, and read and write on Checks and Pull requests so it can post a review and a status. It never needs write access to your code, and it never pushes commits.
Step two: configure your context and frameworks as code
This is the part that makes heygrc a specialist rather than a generic linter. You describe your company, what you build, the data you handle, where you host, the obligations you are under, and you select the frameworks that apply, and that configuration is written to heygrc with a single API call. Because it is a plain REST call, you can hand the task to your coding agent: tell Claude Code or Cursor to configure heygrc for your org with your context and frameworks, and it makes the call.
The company profile is free-form context, and the more relevant it is, the sharper the reviews. heygrc injects your profile and the knowledge for your selected frameworks into every review, so a change to authentication, data handling, logging, or a dependency gets read against your specific controls rather than a generic checklist. You can read the configuration back at any time.
Step three: choose how often it reviews
heygrc supports three review modes. In auto, the default, it reviews every pull request when it is opened, reopened, or pushed to. In auto-once, it reviews on open or reopen only, not on every new commit. In mention-only, it stays silent until someone comments a slash command on the pull request, which is useful when you want reviews on demand rather than on every change.
You set the mode per organization, and can override it per repository. On-demand reviews are gated to people who are an owner, member, or collaborator on the repo, so a drive-by commenter cannot make it run.
Does heygrc block your merges? Not on its own
heygrc posts its review as comments plus a GitHub Checks status, and that status is only ever neutral or success, never a failure on findings. It never submits a request-changes review. So by default heygrc cannot stop a merge; it informs the people and agents shipping the code rather than standing between them and the merge button.
There is one setting that can change this, and it is yours, not heygrc's. If your repository requires conversation resolution before merging, then GitHub itself requires every unresolved review thread, including a bot's inline comments, to be resolved first. heygrc leaves line-anchored inline comments on the exact lines of a finding, and those are resolvable threads. In a repo with that rule on, you resolve each finding before merging, which for a compliance workflow is often desirable: it is a lightweight, recorded acknowledgment that the team saw and addressed the control impact. If you do not want that, turn the branch rule off, and no reviewer's comments, heygrc's or a human's, will gate a merge.