Copilot Review Skills Are Team Policy, Not Nicer Nitpicks

Generic AI review comments are mostly expensive autocomplete. "Consider adding error handling." "This function is long." "Have you thought about edge cases?" Reviewers learn to mute them. GitHub's July 29 GA for Copilot code review agent skills and MCP is interesting for a different reason: the reviewer can finally load your house rules and external context instead of guessing from the diff alone.

That shifts the product from "AI that nits" to "AI that applies written team policy." Whether that is good depends entirely on how you write the skills and what you attach over MCP.

Skills encode what Codeowners cannot say in a regex

Put a `SKILL.md` under `.github/skills/<name>/` and Copilot can pull that skill into a review when it looks relevant. Directory name and description matter for selection. Pull request head branch is the source of truth, so you can iterate on a skill in a PR and have that same PR reviewed by the edited skill. That is the opposite of most CI lint config, which only cares what is already on the base branch.

Use that for rules that are real, specific, and repeatedly broken:

• Auth changes must not introduce client-side secret material
• New API routes need rate-limit middleware unless explicitly exempted
• Payload collections require access control on every operation
• Migrations must be backward-compatible for one release
• Do not add `any` in public package entrypoints

Bad skill content looks like a style guide dumped into Markdown: fifty preferences, no priority, no examples of good vs bad diffs. Copilot will spray comments. Humans will ignore them. You will blame the model for a policy design problem.

I treat a review skill like a linter rule with a prose body. One concern per skill when possible. Concrete fail examples. Clear "do not comment on X" exclusions so it stays quiet on noise.

MCP gives context. It also expands the attack surface.

MCP in code review is read-only by design, which is the correct default. A reviewer that can post to your issue tracker is a reviewer that can be steered by a malicious PR description. GitHub still lets you configure broad tool allowlists; do not. Allowlist the tools you need. Put tokens under Agents secrets, not in the skill file, and prefer servers that return narrowly scoped documents over "everything the service account can see."

Useful MCP for review:

• Fetch the linked issue or RFC so comments match the actual acceptance criteria
• Pull a service catalog entry when the PR touches a named system
• Read an internal API contract or OpenAPI snippet referenced in the PR

Less useful, and riskier:

• Broad wiki search that returns outdated runbooks as gospel
• Servers that expose customer data, billing ledgers, or production logs into a PR review
• `"tools": ["*"]` because setup was annoying on a Friday

If MCP is already configured for Copilot cloud agent, it applies to review too unless you turn that off. Audit the shared config. Cloud-agent convenience is not the same threat model as an always-on PR reviewer that reads every diff.

Attribution is how you debug the policy

Comments now indicate when they came from a skill or MCP context. Use that. When a comment is wrong, ask which skill fired. Fix or delete the skill. When a comment is right, keep the skill and ignore the urge to add five more "also check…" paragraphs.

Without attribution, skills become a ghost writer. With attribution, they become versionable policy you can own like any other repo artifact.

A minimal skill shape that stays maintainable:

1---
2name: api-rate-limit-review
3description: Flag new Next.js route handlers missing rate limiting
4---
5
6When the diff adds or significantly changes a route under `src/app/api/`:
7
81. Require an explicit rate-limit helper or documented exemption comment.
92. Do not nitpick formatting, naming, or unrelated refactors.
103. If unsure whether a path is public, ask one clarifying question instead of asserting.
11
12Fail example: new `POST` handler with no limiter and no exemption.
13Pass example: handler wrapped in `withRateLimit(...)` or `// rate-limit: exempt — internal cron`.

Short. Testable. Quiet on everything else.

Ownership matters as much as content. Put a CODEOWNERS entry on `.github/skills/` so policy changes get the same review as security middleware. A skill that nobody owns will rot into contradictory advice faster than a stale README.

Adoption rule

Ship one skill that catches a real recurring incident class. Measure comment acceptance for two weeks — how often humans resolve threads as fixed vs dismiss as noise. Only then add MCP. Only then add a second skill. Skills are policy as code. Policy that fires on every PR without ownership becomes ambient noise, and ambient noise is how teams turn review agents back into CI cost with worse manners.