GitHub's Copilot code review with agent skills and MCP servers went generally available on July 29, and the teams that will see the fastest value are the ones who have already articulated how they review code. Most engineering teams haven't. That's not a criticism — it's the thing the feature makes visible.
The announcement lets you add a SKILL.md file under .github/skills/ that extends Copilot's review with your team's standards: patterns to enforce, architecture constraints to check, things Copilot would never know from the code alone. MCP connections go further — point them at your issue tracker, your service catalog, your internal documentation, and Copilot can pull that context into every review. The stated goal is that your institutional knowledge shows up consistently, not just in the reviews where the right senior engineer happened to be available.
That goal is real. What the feature actually does, for most teams trying it in the first week, is surface how much of that institutional knowledge was never written down.
What SKILL.md Asks You to Do
The mechanic is clean. You write a SKILL.md describing what Copilot should look for — performance constraints specific to your stack, security patterns your team has standardized on, architectural decisions that affect how new code should be structured. Copilot reads it and adjusts its analysis. If you've documented that all database queries should go through the repository layer, it checks for that. If a particular abstraction pattern is banned because of something that happened eighteen months ago, you can put it there and the review bot will know.
MCP adds live context. A configured MCP server can let Copilot check whether the function being modified is used by a critical service, look up whether the API being changed has related open incidents, or query the current owner of a system before flagging a dependency change.
The pitch is automation of something real: the review comments that senior engineers have been leaving for years, applied consistently at the speed of the commit.
The gap is that all of this requires you to have written things down first.
The Specification Problem in Code Review
Review standards at most engineering teams are informal. You know what good code looks like for your codebase because you've been there and seen what breaks. You know the architectural decision to avoid a particular library was made three years ago for reasons that were never added to any document. You know the service catalog entry for that platform is wrong since the Q3 restructuring. You know the pattern works in all contexts except the one place in the codebase where it'll cause a latency problem.
None of that is in a SKILL.md file. None of it is queryable via MCP. It's in Slack messages, in the heads of two engineers who've been with the team since the early days, in architectural decisions that accumulated without ever being recorded.
Writing a SKILL.md that actually works requires converting implicit, person-dependent knowledge into explicit, durable specifications. This is not a new kind of work. It's what makes a good ADR, a good contribution guide, a good codebase onboarding doc. The difference is that for those documents, you could defer the effort until someone needed them. SKILL.md makes the deferral visible: the file you can't fill in is exactly the knowledge your reviewers are already failing to transfer consistently.
The Teams That Win Are the Teams That Already Did the Work
There's a reliable pattern in which teams get the most out of AI tools that require structured inputs. The ones with well-maintained architecture docs, regularly updated service catalogs, and explicit coding standards can connect those to Copilot's code review and see immediate improvement. The MCP queries return accurate context. The SKILL.md is already half-written because the standards were already written.
Teams with stale wikis, undocumented architecture constraints, and standards that live in the heads of three people get thinner results. They can write a SKILL.md, but it covers the easy rules — the stuff that was already codified — and misses the judgment calls that are actually doing the work in review. The MCP connection queries context that's out of date, or doesn't know which questions to ask.
This isn't a reason not to adopt SKILL.md. It's worth being precise about what the feature is actually evaluating. The bottleneck to better AI code review is not model capability. It's whether your team has articulated what it cares about, and in a form that can outlive the people who currently hold it.
Two Kinds of Review Culture
Code review culture means different things depending on who's using the phrase.
Process: teams that require reviews before merging, have turnaround expectations, block merges without approval. This is easy to implement, easy to measure, and most teams that care about shipping reliably have it.
Standards: shared, documented understanding of what good code looks like for this specific codebase. Not "write clean code" — the patterns and constraints that evolved from this system's particular history, architecture, and past failures. The stuff that makes a senior reviewer valuable isn't generic technical knowledge; it's the accumulated model of how this system works and what it needs.
SKILL.md is infrastructure for the second kind. Generic Copilot code review — what existed before July 29 — works with only the first. The distinction matters because most teams have invested heavily in the process layer and very little in the standards layer. You can have a rigorous review process where every PR goes through two senior engineers, and still have no written documentation of what those engineers are checking for.
What It Takes to Write a Useful One
A practical test for whether SKILL.md would immediately help your team: try writing one, not to deploy, just to see what you can put in it. Take the last ten code review comments that flagged something AI review would have missed — the pattern violations, the architecture concerns, the things that are wrong for your codebase specifically. Can you write them as rules that would apply consistently? Or are they expressions of judgment that depend on context that can't go in a file?
If you can draft five solid, consistently applicable rules in twenty minutes, your team has documented standards. If every rule you write needs paragraphs of surrounding context to make sense, or depends on knowing things that aren't written anywhere, you've found the gap.
The gap is not new. It was present in every review where the right engineer wasn't available. It caused every onboarding that took four months because the architecture constraints lived in three people's heads. It's behind most of the inconsistency in large codebases where the patterns in one corner look nothing like the patterns in another.
SKILL.md doesn't create this gap. It makes it legible.
Why This Matters More Than the Code Review Itself
The useful thing to do with the July 29 announcement is not evaluate whether Copilot's review is now good enough to replace human reviewers. It's to use the announcement as a forcing function for work that compounds beyond the AI review use case.
A team that writes a well-maintained SKILL.md doesn't just get better AI code reviews. They get better onboarding for new engineers. They get consistent reviews when their senior engineers are busy. They get architecture constraints that survive personnel changes. They get the organizational knowledge artifact that makes every AI tool they use work better, because the tools are all downstream of the same thing: knowing what your team has decided and having it written somewhere.
At xeve, we track where developer time actually goes across the full work cycle — not just coding sessions, but the review overhead, the documentation work, the knowledge transfer that doesn't show up in commit counts. The teams that consistently invest time in explicit documentation — ADRs, contribution guides, decision logs — show up differently in that data. Their onboarding is shorter. Their review cycles are faster. Their AI tools perform better because those tools inherit the clarity the team built for human reasons first.
SKILL.md is a good feature. What it's testing is whether your team has done the slower work that makes any code review more than pattern-matching on code that happens to be in front of you right now.