# GitHub Copilot Code Review: Skills and MCP Guide

> Configure Copilot code review with head-branch skills, repository instructions, read-only MCP tools, secrets, attribution, and review gates.

- **Published**: 2026-07-30
- **Category**: DevOps
- **URL**: https://agentpedia.codes/blog/github-copilot-code-review-agent-skills-mcp-guide

---

> **Important callout**

**Bottom line:** GitHub Copilot code review can now use repository skills and MCP context at general availability, but the safe setup is narrow: keep standing rules in instructions, task workflows in `.github/skills`, allowlist specific read-only MCP tools, inspect head-branch changes, verify the review session, and retain accountable human approval.

[GitHub made agent skills and MCP support generally available](https://github.blog/changelog/2026-07-29-copilot-code-review-agent-skills-and-mcp-now-generally-available/) for Copilot code review on July 29, 2026. Availability covers Copilot Pro, Pro+, Business, and Enterprise. The feature can pull repository procedures and external context into a review, with attribution when a comment used a skill or MCP source.

This is not permission to connect arbitrary servers. GitHub says code-review MCP calls are read-only, while its shared repository-MCP documentation also says agents call enabled tools autonomously without asking. Configure for the broader shared surface, not only the reviewer you intended to enable.

## What reached GA

Two customization paths moved from public preview to GA:

- **Agent skills:** task-specific instructions in `.github/skills/NAME/SKILL.md`, selected when relevant to a review.
- **Repository MCP servers:** external context providers configured in repository settings, shared with Copilot cloud agent.

The built-in GitHub and Playwright MCP servers are enabled by default for code review. Repository settings also enable **Allow Copilot to use MCP tools when reviewing pull requests** by default. Administrators can disable that toggle while retaining MCP configuration for the cloud agent.

Attribution helps with observability: a review comment can indicate that skill or MCP context contributed. Attribution is evidence that context was used, not evidence that the conclusion is correct.

Copilot code review and [GitHub Code Quality](/blog/github-code-quality-ga-guide) solve different jobs. Review provides advisory feedback on a pull request. Code Quality adds systematic rules, coverage signals, repository-wide analysis, and optional merge gates. Use deterministic gates where a property can be computed.

## Choose the right customization file

GitHub's current guidance separates always-on rules from on-demand procedures:

| Mechanism | Location | Best use | Activation |
| --- | --- | --- | --- |
| Copilot repository instructions | `.github/copilot-instructions.md` | Repository-wide Copilot rules | Automatic |
| Path instructions | `.github/instructions/**/*.instructions.md` | Rules for matching paths or file types | Automatic on matching changes |
| Cross-agent instructions | `AGENTS.md` at repository root | Standing conventions shared by agent tools | Automatic |
| Agent skill | `.github/skills/NAME/SKILL.md` | A review, migration, release, or analysis workflow | Selected when relevant |

Put "all database changes require a rollback path" in standing instructions. Put the multi-step procedure for checking a migration against schema, deploy order, and rollback in a `database-migration-review` skill.

Avoid copying the same rule into all four surfaces. Duplication makes later edits inconsistent and consumes review context. AgentPedia's [AGENTS.md code-review guide](/blog/codex-code-review-agents-md-rules) explains how to turn repository policy into checks that work across tools.

## Create a review-focused skill

GitHub says a review-focused directory name such as `code-review` makes Copilot more likely to select the skill. A minimal project skill can look like this:

```markdown
---
name: code-review
description: Review pull requests for authorization, data exposure, migration safety, and missing tests.
---

# Repository review workflow

1. Identify changed trust boundaries and persisted-data formats.
2. Check authorization before each new read or write path.
3. Require forward and rollback steps for schema changes.
4. Match behavior changes to tests, including negative cases.
5. Report file and line evidence. Do not approve or merge.
```

Save it as:

```text
.github/skills/code-review/SKILL.md
```

A useful skill names observable checks and expected evidence. "Review carefully" adds little. A skill also should not instruct Copilot to run destructive scripts, reveal secrets, or treat an issue description as trusted instructions.

GitHub's skill documentation says a selected `SKILL.md` is injected into context and can include scripts or examples from its directory. Review every file in an installed skill. GitHub warns that skills are not verified and can contain prompt injection, hidden instructions, or malicious scripts.

For third-party skills, preview before installing:

```bash
gh skill preview OWNER/REPOSITORY SKILL
gh skill install OWNER/REPOSITORY SKILL
```

The `gh skill` command itself is still public preview and currently requires GitHub CLI 2.90.0 or later. That preview status is separate from GA support for skills in Copilot code review.

## Test changes from the head branch

Copilot reads repository custom instructions, root `AGENTS.md`, and agent skills from the pull request's **head branch**, not the base branch. This allows a pull request to test a new review skill before merging it.

It also creates a review boundary. A contributor can change code and the instructions used to review that code in the same head branch. Treat changes under these paths as security-sensitive:

```text
.github/copilot-instructions.md
.github/instructions/
.github/skills/
AGENTS.md
```

For an untrusted or high-risk pull request:

1. inspect instruction and skill diffs before relying on the automated review;
2. compare them with the base branch's approved policy;
3. request a separate human review for configuration changes;
4. ensure branch protections cover the owners of review policy;
5. rerun the review after suspicious instructions are removed.

The head-branch behavior is deliberate, but it means an attributed skill comment does not prove the skill was the approved base-branch version.

## Configure MCP with an explicit allowlist

Repository administrators add MCP JSON under **Settings -> Copilot -> MCP servers**. Authentication values belong under **Settings -> Secrets and variables -> Agents**.

GitHub accepts local server types (`local` or `stdio`) and remote types (`http` or `sse`). Each server needs a `tools` list. GitHub strongly recommends listing specific read-only tools because the agent can invoke them autonomously and does not ask first.

This illustrative shape follows the documented fields:

```json
{
  "mcpServers": {
    "service-catalog": {
      "type": "http",
      "url": "https://catalog.example.internal/mcp",
      "headers": {
        "Authorization": "Bearer $COPILOT_MCP_CATALOG_TOKEN"
      },
      "tools": [
        "get_service",
        "get_owner",
        "get_runbook"
      ]
    }
  }
}
```

Agent secrets or variables referenced by MCP configuration must start with `COPILOT_MCP_`. The reference may use `$COPILOT_MCP_NAME` or `${COPILOT_MCP_NAME}` syntax. Expose a secret to the server under the minimum environment variable or header needed; do not place literal tokens in the configuration.

Read-only needs to be true at several layers:

| Layer | Required control |
| --- | --- |
| Copilot review caller | GitHub's code-review read-only restriction |
| MCP tool list | Specific retrieval tools, not `"*"` |
| Server implementation | No write side effects in a "read" method |
| Credential | Read-only scope for only required resources |
| Network | Access only to approved endpoints |
| Data | Redaction of secrets and unnecessary customer data |

A tool named `get_issue` can still be unsafe if its server runs arbitrary queries, follows untrusted redirects, or returns sensitive fields. Review the server and credentials; do not infer safety from the method name.

## Account for shared repository settings

Repository MCP configuration applies to both Copilot code review and Copilot cloud agent. A change made to improve review context can therefore alter the cloud agent's tool surface. Conversely, an MCP server added for implementation work becomes available to review unless the code-review MCP toggle is disabled.

The practical rule is to evaluate permissions against the most capable shared consumer. GitHub's current docs warn that configured tools can be called autonomously. Prefer separate read-only server endpoints and narrowly scoped credentials even though code-review calls are limited to read-only.

The default GitHub MCP uses a specially scoped token with read-only access to the current repository. GitHub documents an optional wider personal access token for access outside the repository and recommends a fine-grained token with read-only permissions on specific repositories. Wider access expands both confidentiality and prompt-injection risk.

Playwright is also enabled by default. Browser access can retrieve useful documentation or application state, but pages are untrusted input. Do not rely on it for secrets, production mutation, or authorization decisions.

## Verify tools and attribution

Test the complete path on a harmless pull request:

1. Add a review-focused skill on the head branch.
2. Mention a real issue or incident identifier that the configured MCP can retrieve.
3. Request a Copilot review.
4. Open **View session** from the pull request timeline.
5. Inspect **Setting up environment** for started MCP servers and called tools.
6. Confirm the called tool is on the allowlist and used the expected credential scope.
7. Inspect comments for skill or MCP attribution.
8. Compare the comment's factual basis with the retrieved source.

Test negative cases too: an unknown issue key, an unauthorized service, a server timeout, malformed output, and content containing instructions aimed at the reviewer. The correct result is a bounded failure or an explicit lack of context, not an invented answer.

The [Cisco Antares vulnerability-localization guide](/blog/cisco-antares-vulnerability-localization-guide) offers a related verification pattern: model output should identify evidence to inspect, while reproducible checks decide whether a finding holds.

## Budget for Actions and AI-credit usage

Copilot code review has two usage components:

- **AI credits** for the model interaction;
- **GitHub Actions minutes** for agentic context gathering and tool use.

GitHub uses standard hosted runners by default. Larger hosted runners cost more per minute; self-hosted runners do not consume Actions minutes. If hosted runners are disabled, GitHub says the agentic capabilities are unavailable and the review falls back to a more limited form. A review can still be generated when Actions is unavailable or its workflow fails, but it lacks those additional agentic capabilities.

Review effort also matters. GitHub documents Low as the default and Medium as a longer, higher-reasoning review that uses more AI credits and Actions minutes. Track usage before enabling automatic review on every push.

Automatic review usage is normally attributed to the pull request author; manual review usage goes to the requester. Business and Enterprise budget controls can block reviews when user, cost-center, or enterprise limits are exhausted. Users without a plan that includes review can create paid additional usage for the organization when administrators enable that policy.

## Plan for predictable failures and human limits

| Failure | Likely symptom | Control |
| --- | --- | --- |
| Skill not selected | Generic review, no attribution | Use a review-focused name and clear description |
| Head-branch policy weakened | Important checks disappear | Human-review policy-file changes |
| MCP server fails to start | Session setup error or limited review | Inspect session logs and runner dependencies |
| Overbroad tool list | Unexpected data retrieval | Explicit allowlist and read-only credential |
| Stale external context | Incorrect issue or service assumption | Show source timestamp and identifier |
| Prompt injection in retrieved text | Review follows external instructions | Treat MCP content as data; constrain skill |
| Budget exhausted | Review blocked | Monitor AI credits and runner usage |
| False positive or missed defect | Misleading or absent comment | Human review plus deterministic CI |

GitHub explicitly says Copilot is not guaranteed to find every issue and can make mistakes. Human reviewers must own architecture, security, authorization, data migration, regulatory requirements, and the merge decision.

## Roll out in controlled stages

- Inventory existing instructions, `AGENTS.md`, skills, and repository MCP settings.
- Remove duplicated or contradictory rules.
- Add one review-focused skill with observable checks.
- Protect review-policy paths with appropriate ownership.
- Configure one server with specific read-only tools and a least-privilege `COPILOT_MCP_` secret.
- Review how the same server affects Copilot cloud agent.
- Test success, no-access, timeout, malformed-data, and injection cases.
- Verify session logs and comment attribution.
- Measure AI credits and Actions minutes on Low and Medium effort.
- Keep required CI and human approvals independent of Copilot comments.
- Document how to disable MCP for code review without breaking cloud-agent workflows.

## Practical verdict

Use skills when a review needs a repeatable procedure, and MCP when correctness depends on current context outside the repository. Keep broad conventions in instructions and `AGENTS.md`. This division makes the setup easier to audit and reduces irrelevant context.

The GA feature is useful precisely because it can connect policy and live context to a diff. That same reach makes least privilege mandatory. An allowlisted retrieval tool can improve a review; an arbitrary autonomous server is not made safe by the words "read-only."

## FAQ

### Who can use Copilot code review agent skills and MCP at GA?

GitHub's July 29, 2026 announcement lists Copilot Pro, Pro+, Business, and Enterprise users.

### Where does a repository agent skill go?

Create a named directory under .github/skills and put SKILL.md inside it, for example .github/skills/code-review/SKILL.md. A review-focused directory name increases the chance that Copilot code review selects it.

### Which branch supplies Copilot's review instructions and skills?

Copilot code review reads repository custom instructions, AGENTS.md, and agent skills from the pull request's head branch, not its base branch.

### Are arbitrary MCP servers safe for Copilot code review?

No. GitHub limits code-review MCP calls to read-only, but repository MCP settings also apply to Copilot cloud agent, tools are called autonomously, and server behavior still requires review. Allowlist specific read-only tools and minimize credentials.

### Can Copilot code review replace a human reviewer?

No. GitHub says Copilot can miss problems and make mistakes. Keep human review for security, architecture, authorization, data handling, and merge accountability.


## Official sources

- [GitHub GA announcement: Copilot code review agent skills and MCP](https://github.blog/changelog/2026-07-29-copilot-code-review-agent-skills-and-mcp-now-generally-available/)
- [GitHub Docs: Copilot code review concepts, usage, customization, and limits](https://docs.github.com/en/copilot/concepts/agents/code-review)
- [GitHub Docs: Configure MCP servers for a repository](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers)
- [GitHub Docs: Add agent skills](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills)

---

[Join the Agentpedia newsletter](https://agentpedia.codes/blog)

[Browse related Agentpedia articles](https://agentpedia.codes/blog)


---

- [All articles](https://agentpedia.codes/blog)