The automated reviewer just became configurable in the way that actually matters. As of July 29, 2026, GitHub Copilot's code review can run your team's agent skills and read from your MCP servers — the feature is out of preview and generally available for Copilot Pro, Pro+, Business, and Enterprise (GitHub Changelog). The short version: the reviewer stops giving generic advice and starts checking every pull request against the standards you keep repeating and the context that lives outside the diff.

Here's the move before the detail: encode the three rules you comment on most as a SKILL.md today; wire MCP only once a review genuinely needs context from outside the repo.

What actually shipped#

Two levers, previously in preview, are now GA:

This lands two weeks after the same desk shipped customization and configurability improvements on July 17, and a week after GitHub's MCP Server picked up the next MCP specification. The direction is clear: the built-in reviewer is being pushed from "generic linter with opinions" toward "reviews the way your team reviews."

How to set it up#

The skill is just a file. Create a subdirectory under .github/skills and drop a SKILL.md in it:

.github/
  skills/
    api-conventions/
      SKILL.md

Inside, write the rules you're tired of typing in review comments — plainly, the way you'd brief a new engineer:

# API conventions

When reviewing changes under `src/api/`:
- Every list endpoint MUST be paginated (cursor-based). Flag any handler
  that returns an unbounded array.
- User-facing error strings MUST be i18n keys, not literals.
- New endpoints MUST have a corresponding entry in `openapi.yaml`.

Commit it, and Copilot loads the matching skill on the next review. Put the skill at the org level to cover every repo, or in a single repo to keep it local. Because it's a versioned file, your review rules get reviewed like any other code — which is the whole point.

MCP is the second layer, and it's narrower on purpose. Connect an MCP server (your issue tracker, your docs) to Copilot code review, and it can pull a linked issue's acceptance criteria into the review to check the PR actually does what the ticket asked. It cannot write back, comment, or change anything through that server — read-only is the hard boundary.

Skills are how you tell the reviewer what "good" means here. MCP is how you let it see the context that never fit in the diff. Neither can touch anything — the review still only suggests.

When the built-in reviewer is enough — and when it isn't#

The reason teams reached for a dedicated reviewer like CodeRabbit was almost always customization and repo-specific context. That's exactly the gap skills and MCP close. If you already pay for Copilot, the honest first step is to encode your standards as skills and see how far the built-in review gets before you add another tool and another invoice.

A separate reviewer still earns its keep when you need cross-repo policy at real scale, configurability beyond what a SKILL.md can express, or review coverage on platforms Copilot doesn't reach. But that's now a smaller, more specific set of cases than it was a month ago.

What it means for how you ship: if you're a solo founder or a tiny team, this is free leverage you've already bought. Every convention you currently enforce by hand in review — and forget to enforce when you're tired — becomes a check that runs on every PR. Start with the rules you repeat most; they're the ones costing you the most attention. For the human half of the loop, pair this with a deliberate pre-merge review of AI-authored PRs, and if your agents open the PRs too, see how we set up code review for Claude Code. Which Copilot tier you actually need is a separate question we work through in the Copilot billing guide for solo founders.