Copilot code review skills and MCP for QA can make pull-request feedback more relevant by bringing repository standards and approved external context into the review. GitHub announced on July 29, 2026 that agent skills and MCP support in Copilot code review are generally available for Copilot Pro, Pro+, Business, and Enterprise users.
This tutorial shows how to validate the feature with one narrowly scoped QA skill and one synthetic read-only context source. The goal is not to maximize AI comments. It is to prove that the right context is used, attribution is visible, permissions remain bounded, and deterministic tests plus human review remain authoritative.
What GitHub officially documents
Agent skills are stored in a skill-specific directory under .github/skills, with instructions in SKILL.md. MCP connections can bring context from issue trackers, documentation, and service catalogs into a review. GitHub states that MCP tool calls performed by Copilot code review are limited to read-only.
Existing MCP configuration for Copilot cloud agent automatically applies to code review. GitHub and Playwright MCP are enabled by default. Review comments now indicate when a skill or MCP context contributed, providing useful attribution. Attribution is evidence of context use, not proof that the comment is correct.
Define a bounded QA pilot
Use a disposable repository or isolated test branch. Create a small skill named qa-review-standard that checks only three rules: changed behavior needs a test, selectors should be stable, and failure messages should identify the expected and actual outcome. Avoid broad instructions such as “find every bug.”
Create a synthetic MCP source containing a service record with owner, supported browser matrix, and one intentionally outdated entry. Do not connect the pilot to customer tickets, production telemetry, secrets, or write-capable systems.
Acceptance criteria
- A known rule violation produces a relevant review comment.
- A compliant change does not produce the same warning.
- Skill-assisted and MCP-assisted comments show attribution.
- The MCP integration performs only read operations during review.
- Unavailable or stale context is not presented as verified fact.
- Conflicting context is surfaced for human judgment.
- Review comments match the actual diff and repository state.
- Deterministic tests and human merge approval remain required.
Step 1: add the QA review skill
Create .github/skills/qa-review-standard/SKILL.md. State the purpose, exact checks, evidence requirements, and exclusions. Tell the reviewer to comment only when the changed lines demonstrate a violation, cite the relevant rule, and avoid blocking a pull request based only on speculation.
Add examples of one violation and one compliant pattern. Keep the skill short enough to review in a pull request. Protect the directory with normal branch rules and code ownership so changes to review policy receive human approval.
Step 2: configure synthetic MCP context
Add the MCP configuration through repository settings under Copilot and store authentication values under Secrets and variables for Agents, following GitHub’s documented setup. Use a token with the least privilege supported by the source even though Copilot code review limits its MCP calls to read-only.
Expose only three synthetic records: current browser support, an obsolete browser-support record, and a missing service. Log tool name, timestamp, correlation ID, result class, and record revision. Do not log tokens or full pull-request content.
Step 3: build the review test matrix
| Case | Pull-request change | Expected result |
|---|---|---|
| SKILL-POS | Behavior change without a test | Attributed, specific warning |
| SKILL-NEG | Behavior change with adequate test | No duplicate missing-test warning |
| MCP-CURRENT | Browser matrix conflict | Comment cites current synthetic context |
| MCP-STALE | Only obsolete record matches | Staleness is visible or comment withheld |
| MCP-DOWN | Context source unavailable | Review degrades safely |
| CONFLICT | Skill and external context disagree | No invented resolution |
Repeat each case so you can distinguish reproducible behavior from model variability. Record both false positives and false negatives.
Step 4: verify attribution
Inspect every generated comment. When the skill or MCP context contributed, confirm GitHub displays the corresponding attribution. Compare the cited rule or external record with the actual source revision.
File a defect if attribution is missing, points to the wrong source, or creates the impression that stale context is current. Also record cases where attribution appears but the conclusion is unsupported; provenance does not guarantee sound reasoning.
Step 5: test the read-only boundary
Review MCP server logs for every test. Confirm calls are read-only and no create, update, delete, comment, or workflow-trigger operation occurs. Include a deliberately exposed write-like tool in the disposable server and verify code review does not invoke it.
Independently confirm repository and source-system permissions. A product-level read-only limitation is valuable defense in depth, but tokens should still follow least privilege and secrets must not appear in review comments or logs.
Step 6: test stale, missing, and conflicting context
Change the synthetic record revision after opening a pull request, then request another review. Record which revision influenced the comment. Disable the MCP source and repeat. The review should not fabricate external facts or conceal that context was unavailable.
Next, make the skill say one browser is required while the current service record excludes it. A safe result identifies the conflict and asks for human resolution instead of silently choosing one source.
Step 7: compare with deterministic evidence
Run the repository’s unit, API, UI, lint, and security checks as applicable. Map each Copilot finding to a failing test, an observed behavior, a documented standard, or a verified context record. Mark speculative suggestions separately.
Measure precision, missed seeded defects, duplicate comments, stale-context errors, review time, and human correction effort. Do not use comment count as a quality metric.
Step 8: roll out safely
Start with one repository and one owned skill. Review the effective MCP configuration, including the GitHub and Playwright defaults documented by GitHub. Establish owners for skills, MCP sources, tokens, and stale-data incidents.
Rollback should be simple: disable the MCP connection or revert the skill change, rerun the baseline pull requests, and confirm normal code review behavior returns. Block wider rollout if read-only behavior is violated, attribution is unreliable, stale context causes high-impact comments, secrets leak, or false positives overwhelm reviewers.
Common mistakes
- Writing vague skills: use observable rules and examples.
- Trusting attribution as correctness: verify the cited source and conclusion.
- Ignoring default MCP connections: inventory the effective configuration.
- Testing only positive cases: include compliant, stale, missing, and conflicting cases.
- Using privileged tokens: retain least privilege even with read-only calls.
- Replacing CI: AI review complements deterministic checks; it does not replace them.
Official sources
- GitHub Copilot code review skills and MCP GA announcement
- GitHub MCP configuration documentation
- GitHub agent skills documentation