On 29 July 2026, GitHub announced that agent skills and MCP servers for Copilot code review are generally available for Copilot Pro, Pro+, Business, and Enterprise. That sounds like a feature checklist. The useful reading is different: review is no longer a single generic prompt staring at a diff. It can load specialized instructions and external read-only context—closer to how a real review team works.
This article explains the news for beginners, then maps it to agent-team ideas (including how PapaCoder Labs thinks about specialized agents, MCP, and human gates). It is analysis, not a changelog repost.
What shipped (grounding)
According to the GitHub Changelog and Copilot docs:
- Copilot code review can use agent skills from your repo (typically under
.github/skills/.../SKILL.md). - It can use MCP servers configured for the repository to pull context from tools your team already uses (issue trackers, docs, service catalogs, and similar).
- In code review, MCP tool calls are limited to read-only.
- MCP configs you already set for Copilot cloud agent also apply to code review; the GitHub and Playwright MCP servers are on by default.
- Review comments can attribute when a skill or MCP context contributed—so you can see the specialization at work.
Skills themselves are folders of instructions (and optional scripts/resources). SKILL.md uses YAML frontmatter (name, description) plus a Markdown body of guidance. GitHub documents that the same skill idea also shows up across cloud agent, CLI, the Copilot app, and VS Code agent mode.
Source note: Direct page fetches to
github.blog/docs.github.comwere blocked in this agent environment; claims below are cross-checked against Web Search snippets from those official URLs. Treat vendor performance anecdotes as unverified unless you reproduce them.
Why it matters
Think of a junior reviewer who only ever says “looks fine” or “add tests.” Now imagine handing them a one-page playbook for this repo (auth rules, migration checklist, API versioning) and a read-only badge to the issue tracker and architecture docs.
That is the product shape:
- Skills = playbooks the review agent loads when relevant.
- MCP = tools/context ports (in review: read-only).
- Attribution = audit trail for which playbook/tool shaped a comment.
Without skills, “AI review” collapses into one monolithic prompt. With skills, you encode team standards as versioned artifacts—closer to code review process as code.
For beginners: you do not need to invent a new AI platform. You add a directory, write Markdown instructions, optionally connect a docs/issue MCP, and ask Copilot to review a PR.
Comparison: before vs after (and vs a real agent team)
| Approach | What the model sees | Failure mode |
|---|---|---|
| Generic PR review | Diff + maybe repo README | Comments ignore house rules |
| Custom instructions only | One long global prompt | Bloated context; hard to specialize per task |
| Skills + MCP (GA) | Diff + relevant SKILL.md + read-only tool context | Skills drift if nobody owns them; MCP noise if over-connected |
| Specialized agent team (PapaCoder-style) | Typed handoffs between single-responsibility agents + quality gates | More design work; higher reliability when done well |
PapaCoder Labs’ architecture (see specs/11-agent-architecture.md) insists on specialized agents, typed outputs, MCP with least privilege, and a human publish gate. Copilot’s review GA is not that full DAG—but it rhymes:
- A
code-reviewskill ≈ a Reviewer agent card (goal + instructions). - MCP servers ≈ MCP Coordinator ports (tools, not free-form browsing).
- Read-only MCP in review ≈ least privilege at the trust boundary.
- You still merge (human gate)—the bot does not own production.
The MCP protocol also moved to a stateless core in the 2026-07-28 spec (separate news). Skills+MCP in Copilot review is the product-facing side: how those tool connections show up in day-to-day PR flow. Do not confuse “protocol revision” with “Copilot GA”—related ecosystem, different announcements.
Code example: a review skill + a tiny typed checklist
Illustrative SKILL.md (adapt to your stack):
---
name: code-review
description: Repo PR review rules for auth, migrations, and API compatibility. Use on pull requests.
---
# Code review skill
## Always check
1. AuthZ is server-side; no trust of client role claims.
2. New env vars appear in `.env.example` without secret values.
3. DB migrations are backward-compatible or clearly gated.
4. Public API changes include a migration note in the PR body.
## Comment style
- Prefer one actionable finding per comment.
- If unsure, ask a clarifying question instead of inventing requirements.
- Never request committing secrets.
Place it at:
.github/skills/code-review/SKILL.md
Here is a TypeScript mental model for “specialized review output” (not GitHub’s internal API—teaching structure):
type ReviewFinding = {
path: string;
severity: "blocker" | "suggestion" | "question";
ruleId: string; // maps to a skill checklist item
message: string;
usedSkill?: string;
usedMcpServer?: string;
};
function scoreReview(findings: ReviewFinding[]): number {
const blockers = findings.filter((f) => f.severity === "blocker").length;
// Accuracy-style gate: inventing blockers without evidence should fail the run.
if (findings.some((f) => f.message.includes("probably") && f.severity === "blocker")) {
return 0;
}
return Math.max(0, 100 - blockers * 15);
}
The point is not the function—it is the contract: findings should cite a rule (skill) and optionally a context source (MCP), the same way Fact Checker agents refuse unsupported claims.
Practical use: adopt this week
- Create one skill named for review (
code-review) with five concrete house rules—not a novel. - Enable MCP only where needed. Start with GitHub’s default MCP; add a docs/issue server when reviews keep missing ticket context.
- Store tokens under repository Secrets for Agents; do not paste keys into
SKILL.md. - Open a small PR and read attribution on comments. If skills never fire, tighten the skill
descriptionand directory name so relevance matching works. - Keep a human merge bar. Treat AI comments as a Reviewer agent draft—maintainers still approve.
If you already configured skills/MCP in public preview, GitHub’s changelog says your setup should continue without migration.
NZ / senior-engineer perspective
In smaller NZ and APAC teams, the scarce resource is not “more model tokens”—it is shared standards that survive staff turnover. Skills are valuable when they encode the boring invariants (auth, migrations, PII, cost) that seniors repeat in every review.
Two cautions from a senior lens:
- Read-only MCP is a feature, not a limitation. Review agents that can mutate tickets or deploy from a PR comment are an incident waiting to happen.
- Skills rot. Appoint an owner. Stale skills are worse than none: they train juniors (and models) on obsolete rules.
Also: vendor “internal testing” claims about model quality are useful marketing signals, not your SLO. Measure whether your skills catch your defects.
How to use this in Cursor
Cursor already leans on agent workflows, repo rules, and MCP. Parallel habits:
- Keep review/deploy playbooks as versioned Markdown (skills, agent cards, or Cursor rules)—not tribal Slack lore.
- Give MCP tools least privilege; prefer read-only for review-like agents.
- Separate draft from publish/merge. PapaCoder’s constitution is explicit: AI drafts, humans publish. Copilot review GA fits the same mental model: AI annotates, humans merge.
If you are building an editorial or platform agent loop, treat Copilot’s skill file as a tiny cousin of an agent card: goal, when-to-use description, instructions, optional tools.
FAQ
Who can use Copilot code review skills and MCP now?
GitHub’s 2026-07-29 changelog states general availability for Copilot Pro, Pro+, Business, and Enterprise users.
Where do I put SKILL.md files?
Under a skill directory in .github/skills (for example .github/skills/code-review/SKILL.md). The file name must be SKILL.md.
Are MCP tools read-only during code review?
Yes—GitHub documents that MCP tool calls performed by Copilot code review are limited to read-only. Defaults include GitHub and Playwright MCP; org/repo settings can further constrain use.
How do I know a comment used a skill or MCP?
Look for attribution on the review comment (and session logs linked from the PR timeline, per GitHub’s code review docs).
Is this the same as the MCP 2026-07-28 protocol release?
No. The protocol release changes how MCP servers speak HTTP/sessions. The Copilot GA is a product rollout of skills + MCP inside code review. Related ecosystem timing; different deliverables.