GitHub Quick Review for enterprise repos in 2026: what ghqr should check before an AI code review

Posted on by

AI code review should not start with the diff.

That sounds wrong at first.

The diff is where the change lives.

The pull request is where the conversation happens.

The review bot is usually wired to the pull request.

So it feels natural to point an AI reviewer at the patch and ask, “What is risky here?”

For a small repository, that may be enough.

For an enterprise GitHub estate, it is often too late.

The risk may not be inside the patch.

It may be in the repository settings around the patch.

It may be in branch protection.

It may be in Actions permissions.

It may be in default member privileges.

It may be in missing CODEOWNERS.

It may be in Dependabot, secret scanning, code scanning, or audit log coverage.

It may be in the fact that the AI reviewer is about to comment on a repository where the basic guardrails are not visible.

That is where GitHub Quick Review, or ghqr, becomes interesting.

As of April 29, 2026, Microsoft’s public microsoft/ghqr repository describes GitHub Quick Review as a CLI tool for analyzing GitHub enterprises, organizations, and repositories against GitHub best practices and security recommendations.

The latest release page shows v.0.2.1 published on April 28, 2026.

The README says ghqr checks areas such as security, access control, branch protection, Copilot, governance, audit logs, community files, Actions, dependencies, and metadata.

That is exactly the kind of pre-review context an AI code review workflow often lacks.

This post is not a tutorial for every ghqr flag.

I already treat that as a separate operational topic.

This field note asks a narrower question:

what should ghqr check before an AI code review is trusted in an enterprise repository?

The answer is not “everything.”

The answer is “the settings that change whether the AI review has a safe operating surface.”

That is less flashy than another prompt template.

It is also much more useful.

The short answer

Before using AI code review on an enterprise repo, run a GitHub hygiene pass that answers five questions:

  • Can risky changes bypass human review?
  • Can automation write more than it needs?
  • Are security signals enabled and visible?
  • Are ownership and escalation paths clear?
  • Can the AI reviewer call tools without leaking sensitive context?

ghqr is useful because it turns many of those questions into a repeatable scan.

It should not be treated as an automatic fix list.

It should be treated as a pre-review evidence packet.

The packet should go to the human reviewer, the repo owner, and the AI review workflow.

The goal is not to make the AI reviewer sound confident.

The goal is to make confidence harder to fake.

Why this matters before AI review

Most AI code review discussions focus on the reviewer.

Which model?

Which prompt?

Which coding agent?

Which approval mode?

Which comments are too noisy?

Those are real questions.

But they skip the repo environment.

An AI reviewer can identify a suspicious authentication change.

That does not mean the repo has required reviews.

It can suggest adding tests.

That does not mean status checks are required before merge.

It can flag secret-looking strings.

That does not mean secret scanning is enabled.

It can recommend ownership review.

That does not mean CODEOWNERS exists.

It can warn about workflow permissions.

That does not mean GitHub Actions is configured with least privilege.

The review comment and the repository control plane are different layers.

If the control plane is weak, AI review becomes a polite suggestion box.

Suggestion boxes are nice.

They are not guardrails.

Enterprise repositories need guardrails before suggestions.

That is the niche ghqr fits.

What ghqr checks that matters for AI review

The official ghqr README lists multiple check areas.

For AI code review, I would group them into six review-surface categories.

ghqr area Why it matters before AI review Review question
Branch protection Prevents review bypass Can a risky PR merge without required review or checks?
Access control Limits who can change repo state Who can push, invite, administer, or change defaults?
Security features Creates baseline signals Are Dependabot, secret scanning, code scanning, and GHAS posture visible?
Actions Controls automation blast radius Can workflows write broadly or run untrusted paths?
Governance Shapes org-level defaults Are repo creation, forking, and IP allow policies intentional?
Metadata/community Improves routing Can humans and agents find owners, contribution rules, and repo purpose?

This is the useful reframing.

ghqr does not replace AI code review.

It gives the AI review workflow a better floor.

Without that floor, AI review can be technically accurate and operationally weak.

That is a very annoying combination.

It looks smart in the pull request.

It fails in the process.

The pre-review checklist

Here is the checklist I would run before trusting AI review on a repository.

First, branch protection.

Check whether default branches require pull requests.

Check required approving reviews.

Check required status checks.

Check whether administrators can bypass protections.

Check whether force pushes and deletions are restricted.

AI review is much less useful if the repo can merge around it.

Second, ownership.

Check CODEOWNERS.

Check who owns security-sensitive paths.

Check whether generated code, infrastructure, authentication, payment, and deployment files route to the right humans.

An AI reviewer can say “this looks risky.”

It cannot be the final owner of the risk.

Third, security signals.

Check secret scanning.

Check code scanning.

Check Dependabot alerts.

Check Dependabot security updates.

Check whether alerts are ignored, untriaged, or invisible to the people doing review.

AI review should not be the only security signal in the room.

Fourth, Actions permissions.

Check default workflow token permissions.

Check allowed actions.

Check self-hosted runner exposure.

Check whether workflows can write when they only need read.

AI code review often sits near automation.

That makes Actions policy part of the review surface.

Fifth, Copilot and AI tooling policy.

The ghqr README includes Copilot-related checks such as seat usage, content exclusions, policy configuration, and MCP settings.

That matters because AI review is not just another comment bot anymore.

It may be connected to tools, repositories, and context providers.

If content exclusions or MCP boundaries are unclear, your AI reviewer may see too much, too little, or the wrong thing.

Sixth, auditability.

Check audit log streaming coverage where relevant.

Check whether enterprise and organization-level changes are traceable.

When AI review becomes part of a formal engineering workflow, you need to know who changed the settings around it.

The review bot is only one actor.

The platform is the stage.

If the stage moves, the review changes.

Where ghqr fits in the AI review pipeline

I would not run ghqr on every pull request.

That is usually the wrong level.

ghqr is better as a scheduled or event-driven posture check.

For example:

  • before enabling AI review on a repo
  • before onboarding a new organization
  • before a security-sensitive migration
  • after changing GitHub Enterprise policy
  • before connecting MCP tools to an AI assistant
  • before expanding AI review from pilot repos to production repos
  • monthly or quarterly for enterprise posture drift

The output should become a pre-review packet.

That packet can contain:

  • repository posture summary
  • branch protection findings
  • Actions permission findings
  • missing ownership signals
  • security feature coverage
  • AI/MCP policy notes
  • open decisions for humans

Then the AI code reviewer gets a narrower job.

It reviews the diff inside a known environment.

That is much better than asking the AI reviewer to infer platform posture from file contents.

File contents do not tell the whole truth.

Sometimes the important truth lives in settings.

The minimum ghqr runbook

The ghqr README shows a basic flow:

set GITHUB_TOKEN, scan an organization with ghqr scan -o my-org, or scan an enterprise with ghqr scan -e my-enterprise.

It also documents required token scopes such as read:org, read:enterprise, repo, read:audit_log, read:user, and copilot.

Do not treat those scopes casually.

A token that can read enterprise, organization, repository, audit, and Copilot information deserves a handling plan.

For an enterprise runbook, I would require:

  • a dedicated token owner
  • minimum required scopes
  • SSO authorization where needed
  • expiry or rotation policy
  • storage location
  • no token in shell history
  • output classification
  • access rules for generated reports
  • cleanup policy for old reports

This is not bureaucracy for fun.

ghqr output can include sensitive posture information.

It can tell someone where the organization is weak.

That is useful for defenders.

It is also useful for people you do not want helping themselves.

Handle the report like security evidence, not like a casual README screenshot.

MCP makes this more interesting

The ghqr README says ghqr includes an MCP server.

It can run in stdio mode with ghqr mcp, or HTTP/SSE mode with an address.

It also shows a VS Code MCP configuration that passes GITHUB_TOKEN through environment input.

That is interesting because it means an AI assistant can call ghqr functionality directly.

It is also exactly where the review boundary matters.

An MCP server connected to enterprise GitHub posture data should not be treated like a toy helper.

Before exposing ghqr through MCP, ask:

  • Which assistant can call it?
  • Which token does it use?
  • Which organizations can it scan?
  • Are outputs logged?
  • Are outputs persisted?
  • Can the assistant trigger broad scans?
  • Is HTTP mode necessary?
  • Who reviews generated findings?
  • What happens when a scan fails or rate limits?

My default is simple:

start with CLI scans.

Use MCP only after the team knows which findings matter.

MCP should serve an existing workflow.

It should not invent the workflow in production.

That sentence saves pain in many places.

Not just here.

Rate limits and enterprise scale

The ghqr README notes GitHub API rate limits and says ghqr handles rate limiting automatically with exponential backoff for large organizations or enterprises.

GitHub’s REST API best-practices documentation also emphasizes rate-limit handling, conditional requests, avoiding concurrent bursts, and pausing between mutative requests.

This matters because enterprise scans can create operational noise.

Even read-heavy tooling can compete with other internal automation.

CI, inventory collectors, security scanners, custom dashboards, and AI assistants may all touch GitHub APIs.

If they share tokens or run without coordination, debugging becomes annoying fast.

So the AI review runbook should include scan scheduling.

Do not run broad scans at random.

Do not make every assistant run its own full scan.

Do not let humans copy-paste large scans into ad hoc workflows without knowing who else depends on the same API budget.

This is not glamorous engineering.

It is the kind that stops Slack from becoming a small incident channel at 4:57 p.m.

What the AI reviewer should receive

The AI reviewer should not receive the raw ghqr dump by default.

That can be too much context.

Instead, give it a short posture summary.

For example:

# repo-posture.md

## Repository
- name: payments-api
- default branch: main
- risk tier: high

## Review surface
- branch protection: required reviews and status checks enabled
- CODEOWNERS: present, missing coverage for deployment scripts
- secret scanning: enabled
- code scanning: enabled, 3 open alerts
- Actions: default token read-only, 2 workflows request write permission
- Dependabot: alerts enabled, security updates enabled

## AI review instructions
- treat auth, payment, infra, and workflow files as high-risk
- flag changes touching uncovered deployment scripts
- do not suggest bypassing required checks
- ask for human owner review on CODEOWNERS gaps

This is the bridge.

ghqr produces posture evidence.

Humans triage it.

The AI reviewer receives the part that should shape diff review.

That keeps the AI reviewer focused.

It also keeps sensitive scan details from being sprayed into every review context.

What humans should decide

ghqr findings should not all become immediate tickets.

That is a common failure mode.

A scan produces many findings.

The team dumps them into an issue tracker.

Everyone feels responsible.

No one feels ownership.

Three months later, the report is a fossil.

Instead, turn findings into decisions.

Decision one: which findings block AI review rollout?

Decision two: which findings block merge?

Decision three: which findings become backlog cleanup?

Decision four: which findings are accepted risk?

Decision five: which findings require platform-owner action rather than repo-owner action?

That decision layer matters.

AI review should not turn every posture issue into noisy comments.

It should route risk.

Routing is not the same as yelling.

Many tools yell.

Good workflows route.

Where this can go wrong

The first failure mode is treating ghqr as a pass/fail gate too early.

A new scan will surface old platform debt.

If every finding blocks all work, teams will route around the tool.

The second failure mode is dumping raw findings into AI review prompts.

That burns context and may expose sensitive posture details unnecessarily.

The third failure mode is using a broad PAT without an owner.

If no one owns the token, no one owns the blast radius.

The fourth failure mode is connecting MCP before the CLI workflow is understood.

Now the assistant can call a tool, but the team does not know what to do with the output.

That is automation theater with enterprise settings.

Spicy, but not in a good way.

The fifth failure mode is ignoring rate limits.

If the scan competes with production automation, the security workflow becomes a source of operational friction.

The sixth failure mode is letting AI review compensate for missing branch protection.

It cannot.

An AI comment is not a required check.

The seventh failure mode is failing to separate repo-owner decisions from platform-owner decisions.

Some findings belong to the repository team.

Some belong to the GitHub platform team.

Some belong to security.

The report should make that clear.

A rollout plan I would trust

Start with ten repositories.

Not one.

Not one thousand.

Ten is enough to expose patterns without making a governance bonfire.

Pick:

  • two high-risk production repos
  • two internal service repos
  • two frontend repos
  • two automation or workflow-heavy repos
  • two low-risk utility repos

Run ghqr.

Summarize findings into repo-posture.md files.

Ask human owners to classify findings.

Then enable AI review with posture-aware instructions.

Watch three things:

  • Did AI review comments improve?
  • Did noise increase?
  • Did platform gaps become clearer?

If the answer is yes, expand.

If the answer is no, fix the packet before expanding the bot.

The packet matters.

The bot is not the strategy.

The bot is a worker inside the strategy.

FAQ

Is ghqr an AI code review tool?

No.

ghqr is a GitHub posture and best-practice review tool.

Its value before AI code review is that it checks the repository and organization environment around the diff.

That environment can determine whether review findings are enforceable.

Should ghqr run on every pull request?

Usually no.

It is better suited for scheduled scans, onboarding checks, enterprise policy changes, or pre-rollout review before enabling AI review on a repository.

PR-level AI review should receive a summarized posture packet, not a full enterprise scan every time.

Should ghqr findings automatically block merges?

Not at first.

Start by classifying findings into rollout blockers, merge blockers, backlog cleanup, accepted risk, and platform-owner actions.

Only promote a finding to a hard gate after the team agrees it is stable, high-signal, and owned.

Is the ghqr MCP server safe to expose to an AI assistant?

It can be useful, but treat it as a privileged integration.

Start with CLI scans first.

Before MCP, define token ownership, scope, logging, allowed organizations, output handling, and review ownership.

HTTP mode should need a stronger reason than curiosity.

What is the minimum output an AI reviewer needs?

A short repo-posture.md is enough.

Include branch protection status, ownership gaps, security feature status, Actions permission notes, high-risk paths, and review instructions.

Do not dump the raw scan into every PR.

Related reading

Sources

Closing note

AI code review is easier to trust when the repository around it is visible.

ghqr helps make that repository posture visible.

Use it before the AI reviewer becomes a formal part of the workflow.

Summarize the findings.

Route the decisions.

Keep tokens scoped.

Treat MCP as a second step, not the opening move.

The enterprise question is not whether an AI reviewer can read a diff.

It can.

The better question is whether the repository is ready for that review to matter.