Technical overview
How Mergegleam reviews your PRs
From GitHub App installation to inline review comments in under 90 seconds. No new workflow, no configuration files, no tokens.
Step 01
Install the GitHub App once
Go to the GitHub Marketplace, install Mergegleam, and select which repositories to enable. That's it. No API keys, no YAML config files, no changes to your CI pipeline. Mergegleam uses GitHub App's native permission model: it requests read access to code and pull requests only.
Permissions requested: read:contents, read:pull_requests, write:reviews. Nothing else.
Step 02
PR opened or updated triggers analysis
Every pull_request event (opened, synchronize, reopened) sends a webhook to Mergegleam. The review is queued immediately and starts within seconds. For most PRs (under 400 changed lines), the review posts in under 90 seconds.
Large PRs (1,000+ changed lines) may take up to 3 minutes. Mergegleam posts a "review in progress" status check so reviewers know it's working.
What Mergegleam reads
Beyond the diff: context-aware analysis
Mergegleam doesn't only look at the changed lines. It reads the surrounding context to catch bugs that only appear when you understand how the code is used.
Changed files and their diff
The full diff context, not just the changed lines. Mergegleam reads surrounding function bodies to understand intent.
Callers of modified functions
If you change a function signature or behavior, Mergegleam finds other code that calls it and checks for downstream breakage.
Type definitions and interfaces
For TypeScript/typed Python, Mergegleam reads type declarations to verify null safety and type compatibility.
Test files for changed code
Existing test coverage is read to understand which paths are already tested, so coverage-gap comments are accurate, not noise.
Review comment types
Three severity tiers, all actionable
Every comment Mergegleam posts has a severity label. Critical issues block merge by default on Pro. Info is advisory only.
Integration detail
GitHub-native: no new tools for your team
Mergegleam posts comments using the GitHub Pull Request Review API. Every comment is inline on the diff, attributed to the Mergegleam bot, and dismissible by any reviewer. Your existing review workflow doesn't change.
On Pro, you can configure Mergegleam to set a status check (blocking merge when there are Critical findings) or keep it advisory-only. The default is advisory so you can evaluate signal quality before enforcing.
stripe.charge() can raise stripe.error.CardError and stripe.error.StripeError. Neither is caught here. A card decline will raise an unhandled exception and return a 500 to the caller.
Likely to cause a runtime error
Null dereferences, out-of-bounds access, unhandled promise rejections in async paths. These are things that will throw in production under the right conditions.
Probable bug or coverage gap
Missing test coverage for a new branch, a suspicious conditional, a return value that gets silently ignored. Worth addressing before merge, but not always a blocker.
Advisory and improvement suggestions
Patterns that work today but may cause problems at scale. Minor consistency issues. These are suggestions; reviewers decide whether to address them.