GitHub Copilot code review uses both skills and MCP

Did GitHub Copilot code review start using team skills or MCP context

Yes. GitHub Copilot code review can use repository skills and MCP context, and it is more likely to do so when your PR or repo gives clear signals. GitHub documents both features as part of code review, not as separate experiments.

The part people get wrong is the word “or”. It is not an either-or change. GitHub says code review can use repository-level agent skills and MCP servers when they are relevant to the review, and the review may combine them with the normal code diff and other repository context.

Agent skills are the repository-side instructions and context you place under .github/skills with a SKILL.md file. GitHub says Copilot code review can automatically use relevant skills, and it reads skills from the head branch, not the base branch. That detail matters when you test new instructions in the same pull request that will use them.

MCP context is the other path. GitHub says Copilot code review can use MCP servers to pull read-only context from third-party platforms and internal systems such as issue tracking, documentation, service catalogs, and incident tooling. GitHub also says the GitHub MCP server and Playwright MCP server are enabled by default for code review.

The inconvenient part is that neither feature is unconditional. GitHub says Copilot code review is more likely to use skills and MCP context when the repository or pull request gives clear signals, such as review-focused skill directory names, custom instructions that reference MCP context, and pull request descriptions that include identifiers tied to configured MCP servers, like issue keys or incident IDs.

That means setup alone is not the whole story. A skill file in the wrong place, a vague PR description, or a missing identifier can reduce the chance that Copilot pulls the context you expected. GitHub’s wording is explicit: the features are available, but relevance and signaling control whether they get used in a specific review.

GitHub also ties this to review quality, not just feature availability. The docs say the more Copilot knows about the code in your repository, the tools you use, and your coding standards and practices, the more accurate and useful its reviews become. That is the practical reason skills and MCP exist in code review.

There is another detail worth keeping straight. GitHub says code review uses GitHub Actions for agentic capabilities, including full project context gathering and passing suggestions to the Copilot cloud agent. If Actions is unavailable or the workflow fails, reviews still happen, but they lose those additional agentic features. So a review can still exist without the richer context path.

For a team, the clean setup is simple. Put review guidance in a skill under .github/skills, keep the SKILL.md focused on the standard you want enforced, and make your PR description mention the external system or identifier that connects to your MCP source. GitHub’s own docs say those signals are what make the review more likely to use the added context.

A concrete example helps. If your team reviews incident-related changes, a PR that mentions the incident ID and a repository skill that explains rollback criteria gives Copilot two obvious cues. GitHub says that combination is the kind of clear signal that helps code review reach for MCP context and skills instead of relying only on the diff.

The failure mode is also predictable. If your review comments look thin, first check whether the repo actually contains the skill files on the head branch, whether MCP is configured in the repository settings, and whether the PR description gives Copilot something to anchor on. GitHub says repository MCP settings apply to both Copilot cloud agent and code review, so changes there affect both features at once.

GitHub also says Copilot code review is not guaranteed to catch everything, and you should validate its feedback carefully with human review. That matters here because skills and MCP improve context, they do not turn the review into a complete policy engine or a replacement for a reviewer who knows the codebase.

If you want the shortest accurate answer, it is this: yes, Copilot code review started using both team skills and MCP context, and GitHub made that explicit in the product docs and changelog. The detail people miss is that it uses them when relevant, not on every pull request in the same way.

For teams already using GitHub Copilot, this is mostly a configuration and hygiene problem. The review gets better when your skills are named and written for review, your MCP sources are connected in repository settings, and your pull requests say enough for Copilot to recognize the right context. That is the practical line between a generic AI review and one that knows your team’s rules.

If you are documenting this inside DevConnect, keep the page focused on the exact setup question and link out to the relevant GitHub docs once. DevConnect is free to use, and the platform page is the place for your own workflow, while GitHub’s documentation is the source for the review behavior itself. https://devconnectplatform.com

What to check in your repo

1. Whether agent skills exist under .github/skills with a SKILL.md file. GitHub says review can automatically use relevant skills when they are present on the head branch.
2. Whether MCP servers are configured in repository settings. GitHub says those settings apply to both Copilot cloud agent and code review.
3. Whether the pull request description names the external system or identifier Copilot should connect to, such as an issue key or incident ID. GitHub says those signals increase the chance that skills and MCP context are used.

What not to assume

Do not assume the feature is all-or-nothing. GitHub says code review can still run without the richer agentic path, and it can fall back to a more limited review if Actions or runners are unavailable. Do not assume a skill file alone is enough either, because GitHub calls out signal quality and relevance as part of the decision.

Practical reading of the change

The release means Copilot code review can now read more of your team’s own context, not just the code in front of it. The important part is that GitHub made that context explicit and controllable. Skills carry your standards, MCP carries outside context, and the review decides whether those inputs are relevant to the pull request in front of it.

FAQ

Does Copilot code review use skills and MCP on every pull request? No. GitHub says it uses them when they are relevant, and it is more likely to use them when the repo or PR gives clear signals.

Do I need to turn on GitHub Actions to use the new review context? No. GitHub says you do not need GitHub Actions enabled in the organization or enterprise to use the agentic capabilities, although the richer path depends on Actions runners being available.

Can Copilot code review read MCP data that changes the pull request? No. GitHub says MCP tool calls for code review are read-only.

Where should I put team instructions for code review? GitHub says to create a skill-specific directory under .github/skills and add a SKILL.md file with the context and instructions you want used.

Will Copilot catch every issue if I add skills and MCP? No. GitHub says Copilot is not guaranteed to spot all problems, so human review still matters.