A pull request that merges clean can still change what your company owes a framework: a widened role, a dropped log line, a new place personal data lands. Cursor Bugbot's job, as Cursor states it, is to flag likely bugs and code-quality problems before they merge. heygrc's job is the other question: which control does this change touch, cited to the clause. This guide is the practical version of running both, because neither replaces the other.
What each one is for
Keep the division of labor explicit for your team. Bugbot is a code reviewer: correctness, quality, the change itself. heygrc is a compliance reviewer: it reads the diff against the frameworks you selected (ISO 27001, SOC 2, GDPR, and others) plus your company context, and when a change touches a control it says which one and why, as a review comment with the clause attached. We make no claim about what Bugbot flags or misses on any given change; the point is that it is answering a different question.
Set up the pair
Bugbot is set up through Cursor, per Cursor's own documentation. heygrc is a GitHub App: install it from github.com/apps/heygrc on the repositories you want reviewed (it asks for read access to code, metadata, and issues, and write access only to Checks and Pull requests, never your code). Then configure it as code: one PUT to api.heygrc.com/v1/config with your company profile and framework list, which your coding agent can do for you in about three minutes.
The order does not matter and neither tool needs to know the other exists. Each posts its own review and its own check status on the same pull request.
Tune the volume before anyone gets annoyed
Two bots commenting on every push is where teams sour on the whole idea, so decide heygrc's cadence on day one. It ships three review modes: auto reviews every pull request when it is opened, reopened, or pushed to; auto_once reviews on open only, not on every commit; and mention_only stays silent until someone comments /heygrc on the PR. If your team is already used to a code reviewer's rhythm, auto_once is the low-friction start: one compliance read per PR, on demand after that.
heygrc also posts one consolidated review per pass, inline findings batched into a single review rather than a comment per finding, so the compliance lens adds one voice to the thread, not a flood.
Decide what blocks a merge
By default heygrc posts a neutral check: it informs, and the merge decision stays with your team. Once you trust the signal, you can make the compliance check required through GitHub branch protection the same way you would any CI job, so a control-relevant change needs an explicit human acknowledgment before it merges. Most teams run informational for a few weeks first; the guide on making compliance a required check walks through the exact settings.
What adding the lens costs
heygrc bills per review, not per seat: free for 25 private-repo reviews a month, then $19 per organization per month with 100 reviews included and $0.49 per review after that, with public repositories always free and a 14-day unlimited trial on install. If you want to see that next to what each review tool publishes about its own pricing at your volume, the cost comparison page runs the arithmetic from the vendors' published rates.