GitHub’s Copilot code review support for agent skills and MCP servers reached general availability on July 29, 2026. The useful part is not “AI reviews more code.” It is the boundary: repository instructions and external context can shape a review, while MCP calls made by Copilot code review remain read-only. GitHub also attributes comments that used skills or MCP context.
That makes this a practical control-plane problem: how do you add project context without quietly turning code review into an agent with mutation privileges?
The workflow
A safe starting design has four layers:
- Versioned review policy in the repository.
- Read-only external context for tickets, architecture notes, or service catalogs.
- Attribution so reviewers can see which comments depended on that context.
- Human approval before anything changes code, labels, issues, or deployments.
The model may produce an incorrect comment. Read-only access does not make the comment correct. It does reduce the blast radius of a bad tool call.
Put review policy next to the code
GitHub’s format is a skill-specific directory under .github/skills, containing a SKILL.md file. Start with narrow, testable instructions rather than a giant engineering handbook. For example:
.github/skills/api-review/SKILL.md
---
name: api-review
description: "Review changes to public HTTP APIs"
---
When a pull request changes a public endpoint:
- Check backward compatibility for field removal, type changes, and enum narrowing.
- Require an explicit migration note for response-shape changes.
- Check that authorization behavior is covered by a test.
- Treat generated client updates as evidence, not as proof of compatibility.
- If the repository does not contain enough evidence, say what is missing instead of guessing.
The important word is evidence. A skill should tell the reviewer where to look and what to verify, not force a conclusion. Keep the file small enough to review like production configuration.
Add context, not authority
MCP can connect a review to systems such as an issue tracker, documentation platform, or service catalog. Use those connections to answer questions like:
- What behavior does the linked issue actually require?
- Is this endpoint still supported?
- Which service owns the changed schema?
- Is there an approved deprecation date?
Do not treat retrieved context as an authorization decision. A ticket can be stale, a document can contradict the repository, and a service catalog can lag reality. The review should surface the source and uncertainty.
A useful review comment has this shape:
The PR changes
POST /v2/ordersby makingcurrencyrequired. The linked migration issue says old clients remain supported until September. I could not find a compatibility test for requests withoutcurrency; please add one or explain why the issue no longer applies.
That is much safer than: “This is a breaking change, revert it.”
Treat attribution as an audit signal
GitHub says comments generated with agent skills or MCP context are attributed. Use that signal during review triage:
| Comment provenance | Review action |
|---|---|
| Ordinary model analysis | Validate against code and tests |
| Skill-assisted | Check the skill version and its evidence rules |
| MCP-assisted | Check the retrieved source, freshness, and access scope |
| Skill + MCP | Check both, then confirm the repository still wins on conflicts |
Attribution is not a correctness score. It tells you what to inspect when a comment looks authoritative.
A small rollout checklist
Before enabling this for every repository, test one low-risk project:
- Add one skill for one review category, such as API compatibility.
- Connect one read-only MCP server.
- Store credentials in the repository’s Agents secrets, not in
SKILL.mdor the workflow. - Open pull requests containing known good, known bad, and ambiguous changes.
- Record whether the reviewer found the expected issue, cited the right source, and stated uncertainty.
- Check that no connected tool can create, edit, merge, label, or deploy.
- Review the attribution on every context-dependent comment.
For a simple test matrix:
| Case | Expected behavior |
|---|---|
| Required field added with migration test | Ask for evidence or pass |
| Required field added without compatibility coverage | Flag the missing test |
| Stale ticket contradicts current code | Surface the conflict |
| MCP source unavailable | State that context was unavailable |
| Tool would need a write operation | Keep the review read-only |
What this does not solve
Read-only MCP limits mutations, not hallucinations. Repository skills can become stale or contradictory. External context adds latency and another authorization surface. A comment can cite a real ticket and still misunderstand the implementation.
So measure the workflow, not just comment volume: useful findings confirmed by maintainers, false-positive rate, source freshness failures, time to resolve a finding, and how often reviewers had to correct the agent’s interpretation. GitHub’s announcement establishes availability and behavior; it does not provide an independent evaluation of review accuracy.
The practical rule is simple: give the review agent more evidence, but keep authority in the repository’s tests and the human approval path.
What would you connect first in your code-review workflow: issue context, architecture documentation, or a service catalog?
Sources:
Top comments (0)