GitHub cambió algo más importante que el tono de los comentarios automáticos. El 2 de junio de 2026 anunció que Copilot code review ya puede usar agent skills y MCP servers en public preview. La novedad útil no es que la review “sepa más”. La novedad útil es que puede llegar al diff con reglas, contexto y herramientas del repo en vez de opinar casi a ciegas.

Eso pega directo a un problema viejo: muchas revisiones automáticas detectan lo obvio, pero fallan cuando la decisión correcta vive fuera del diff. A veces está en una norma interna. Otras en una API externa, una policy de seguridad, una doc privada o un skill mantenido por el equipo.

Escena editorial con revisión de PR, skills del repo y un servidor MCP aportando contexto adicional

Qué se desbloquea de verdad

La documentación de GitHub ya aterriza tres detalles concretos:

Copilot code review puede usar skills del repositorio cuando son relevantes.
También puede usar MCP servers configurados a nivel repo.
La configuración MCP del repo ahora aplica tanto a Copilot cloud agent como a Copilot code review.

Ese tercer punto vale mucho más que el titular. Significa que GitHub está intentando unificar el contexto agentic entre superficies, en lugar de inventar una configuración distinta para cada feature.

El cambio práctico: pasar de revisión genérica a revisión situada

Si quieres que la review te ayude de verdad, necesitas que conozca cosas como:

convenciones de seguridad del equipo;
contratos internos de API;
criterios de accesibilidad o performance;
o incluso herramientas externas donde vive el contexto operativo.

GitHub también documenta una recomendación muy útil: si quieres que Copilot code review use un skill con más probabilidad, conviene organizarlo con un nombre orientado a revisión como code-review. Eso ya te dice cómo están pensando el feature: no como prompt suelto, sino como una capa estable de contexto reutilizable.

Lo interesante no es solo MCP; es MCP dentro del loop de review

Muchos equipos ya probaron MCP en chat o en cloud agent. La diferencia aquí es otra. En code review, el agente entra a un momento delicado:

hay menos margen para alucinaciones;
el comentario tiene que ser corto y accionable;
y el reviewer humano necesita confiar en por qué llegó a esa observación.

Por eso el mejor uso de MCP aquí no es “abrir más tools porque sí”. Es usarlo para que la review pueda verificar contexto donde de verdad lo necesita: estándares internos, checklists de seguridad, documentación viva o metadata del sistema.

Panel editorial con tier de esfuerzo, reglas de revisión y controles antes de publicar comentarios automáticos

Checklist de adopción que sí haría

En vez de activarlo a ciegas, haría esto:

identificar dos o tres fallos de review que hoy se repiten;
convertir esas reglas en un skill corto y específico;
conectar solo los MCP servers estrictamente necesarios;
probar primero en un repo donde el costo de comentarios malos sea manejable.

El changelog también menciona un medium analysis tier para PRs más complejos. Eso sugiere otra lectura importante: GitHub ya no está tratando code review como una sola operación homogénea. Está separando nivel de análisis y contexto disponible según complejidad.

Dónde veo demanda buena

Las queries aquí son limpias y tienen intención real:

copilot code review mcp
copilot code review skills
github code review mcp server
copilot code review repo skills

Es gente que ya tiene revisión automática o la está evaluando, no público curioso.

Esta nota conversa bien con nuestra cobertura sobre Copilot y el costo doble entre créditos y Actions, porque una pieza responde cuánto cuesta y esta responde cómo meterle contexto útil sin convertirlo en ruido. Si todavía no tienes una base clara para escribir instrucciones y guardrails de agente, el punto de entrada más sensato sigue siendo el curso gratis.

Mi lectura corta es esta: GitHub está empujando code review hacia una revisión más situada y menos genérica. Si tu equipo ya vive en PRs largos o reglados, skills y MCP pueden valer más que otra subida de modelo.