Code Review Agents Turn Context Into Review Infrastructure

GitHub's 29 July changelog says Copilot code review support for agent skills and MCP servers is now generally available. A repository or organization can add SKILL.md files under .github/skills, connect MCP servers, and let Copilot code review use team standards, issue trackers, documentation systems, and service catalogs during review. GitHub also says MCP tool calls from Copilot code review are read-only, existing Copilot cloud agent MCP configurations apply, GitHub and Playwright MCP are on by default, and comments now show when skills or MCP context contributed.

The same day's default model enablement change for Copilot Business and Enterprise adds a governance deadline: generally available Copilot models will follow a global default policy from 26 August unless admins opt out or explicitly configure individual models. One day earlier, GitHub expanded Copilot app usage metrics across report rollups, attributing Copilot app activity to users and folding app work into feature, model, language, code activity, and daily-active-user reports.

Those three updates are easy to read separately: better review context, model defaults, and better reporting. The more useful pattern for operators is that AI-assisted review is becoming infrastructure. Review comments can now depend on versioned local skills, external read-only context, default model availability, and metrics that span more Copilot surfaces.

The repeated angle to avoid

The last ten posts here covered package-malware state transitions, AI inference routing, long-running agent checkpoints, overlapping work taxonomies, edge-controlled uploads, agent intake, purchase receipts, model routing, AI credit pools, and code-quality gate experiments. Older overlapping posts covered review-agent environments, Copilot metrics, runtime credentials, prompt-injection triage, pull-request dashboards, AI coding telemetry, and agent audit trails.

The weak version of this article would repeat the old X needs Y formula: code review agents need context. That is true but too broad. The sharper thesis is that review context has become a managed dependency. A SKILL.md file, an MCP server, a service catalog, a default model policy, and a usage rollup can all change what the review agent sees and how the team interprets its work.

Review context is now part of the build surface

Human reviewers often carry unwritten context: which checkout paths are fragile, which analytics events are contractual, which Shopify app hooks are risky, which quote-form fields feed the CRM, and which accessibility rules the team will not compromise. Agent skills are a way to put some of that knowledge where Copilot code review can use it.

That is useful, but it changes the operating model. A skill file is not just documentation. If review quality depends on it, it becomes a review input that can drift, conflict, or go stale.

For a practical web team, useful skills might include:

• checkout review rules for pricing, tax, payment, inventory, and abandonment analytics;
• local-service lead rules for spam controls, consent text, CRM routing, and quote qualification;
• accessibility review rules for forms, focus states, labels, keyboard paths, and error messages;
• SEO review rules for canonical URLs, structured data, internal links, redirects, and content variants;
• reliability review rules for retries, idempotency, queue backpressure, logging, and rollback.

The mechanism is simple: once a reviewer can invoke a skill, the skill shapes the questions the reviewer asks. If the skill says every lead-form change must preserve source attribution, the agent can catch a regression a generic code reviewer would miss. If the skill says nothing about the CRM destination, the agent may praise a clean refactor that breaks sales operations.

Read-only MCP still deserves a data boundary

GitHub's read-only limit for Copilot code review MCP calls is a good default. A review agent that can read issue trackers, documentation, service catalogs, or test context is much safer than one that can mutate those systems during review.

Read-only does not mean risk-free. The review can still expose sensitive context in a comment, overfit to stale documentation, use an irrelevant service entry, or import noise from an issue that has drifted away from the actual pull request. External context also changes the review's blast radius: a Shopify product-page pull request may now depend on a merchandising brief, an analytics schema, a service catalog entry, and a historical incident note.

That creates a practical rule:

Give review agents enough read access to verify the business contract, but not so much unscoped context that every pull request becomes a search across the company's memory.

Scope MCP context by repository lane and review question. A checkout repository may need payment docs, analytics schemas, and incident runbooks. A marketing-site repository may need SEO rules, design-system docs, and redirect policy. A small internal script should not automatically get the same external context as a revenue-critical funnel.

Default model enablement changes the review baseline

The model-policy update matters because review behaviour can change without an individual reviewer choosing a new model. From 26 August, models that were not explicitly configured can inherit the global default and become available if the policy is enabled. GitHub excludes open-weight models and models not covered by its data-retention agreement from default enablement, and explicit per-model decisions are preserved, but the baseline still changes.

That is an operations issue, not just an admin setting. If a team evaluates review quality with one model set and later allows new generally available models by default, the review system may become faster, better, noisier, or simply different. Metrics may show more usage, but the important question is whether the comments improved decisions on real pull requests.

Small teams should use the 28-day window as a review-infrastructure audit:

1. Which repositories are allowed to use default-enabled models for code review?
2. Which repositories require explicit model approval because they touch customer data, payments, auth, infrastructure, or regulated workflows?
3. Which review skills should be tested before new model availability changes the comment mix?
4. Which MCP servers are appropriate for review, and which belong only in broader agent workflows?
5. What evidence will prove review quality improved rather than merely increased activity?

Metrics should separate surface activity from review value

The Copilot app usage-rollup expansion helps because activity is no longer just a standalone total. Operators can see Copilot app usage by user, feature, model, language, code activity, and active-user reports when the metrics policy is enabled and the viewer has permission.

That is better visibility, but it can create a measurement trap. Lines added, prompts sent, sessions started, or active users do not prove that review quality improved. They prove that the surface was used. For review operations, the better questions are closer to outcome:

Metric question	Why it matters	Bad proxy to avoid
Did the review agent find issues humans accepted as valid?	Measures useful signal	Number of comments
Did comments cite the right skill or MCP context?	Tests whether context wiring works	Total MCP usage
Did review latency improve without hiding risk?	Connects automation to delivery	Daily active users
Did defects escape after agent-reviewed merges?	Checks real quality	Lines generated or deleted
Did teams dismiss repeated false positives?	Finds stale skills or bad prompts	Session count

The key is to join platform metrics with repository outcomes. A business-critical checkout repo needs different success evidence from a content repo or prototype utility.

A review-context register

The concrete operator asset is a small register for the review context each repository is allowed to use. It can live in the repo, a platform spreadsheet, or an internal service catalog.

review_context_register:
  repository: org/storefront
  lane: revenue_path
  accountable_owner: ecommerce_engineering
  review_agent:
    enabled: true
    allowed_models:
      policy: explicit_for_revenue_repos
      default_enablement: disabled_until_evaluated
  skills:
    - path: .github/skills/checkout-review/SKILL.md
      owner: ecommerce_engineering
      covers:
        - payment_integrity
        - tax_and_discount_rules
        - analytics_events
      test_prs:
        - pull_request_with_discount_regression
        - pull_request_missing_purchase_event
  mcp_context:
    - server: service_catalog
      mode: read_only
      allowed_queries:
        - checkout_services
        - payment_dependencies
    - server: documentation
      mode: read_only
      allowed_queries:
        - analytics_schema
        - accessibility_form_rules
  comment_requirements:
    cite_skill_or_context_when_used: true
    avoid_customer_data_in_comments: true
  outcome_checks:
    - accepted_agent_findings
    - dismissed_agent_findings
    - escaped_checkout_defects
    - review_latency

This looks heavier than adding one skill file, but the first version can be brief. The point is to make review context inspectable. If an agent comment blocks a merge, the team should know which standard or external record contributed. If the comment is wrong, the operator should know whether to fix the skill, narrow the MCP source, change the model policy, or treat the case as a human-review exception.

Implementation consequences for small teams

Start with the repositories where a review miss has business cost: checkout, booking, quote intake, lead routing, authentication, customer messaging, analytics collection, and deployment tooling. Write one narrow skill for each high-value review question rather than one giant standards manual. Connect MCP only where external context changes the decision. Keep model defaults conservative on high-risk repositories until the team has compared review output across real pull requests.

Then test the review infrastructure with deliberately boring examples: a missing analytics event, an inaccessible form error, an unsafe retry, a broken redirect, a changed CRM field, or a product schema regression. The question is not whether the agent can write a clever paragraph. The question is whether it notices the business contract that ordinary syntax and lint checks cannot see.

The durable advantage is not more AI in review. It is review context that behaves like the rest of the delivery system: owned, scoped, versioned, measurable, and safe to change deliberately.