GitHub Copilot funciona mejor cuando conoce las reglas específicas de la base de código con la que trabaja, en lugar de depender únicamente de instrucciones generales. GitHub explica que gran parte de este contexto puede almacenarse dentro del repositorio, de modo que Copilot reconozca automáticamente las formas de organizar los componentes, los comandos utilizados y los estándares de nomenclatura y pruebas.
Instrucciones generales y específicas para rutas
La configuración comienza creando el archivo .github/copilot-instructions.md para incluir las reglas que se aplican a todo el repositorio, como la arquitectura preferida, las convenciones de nomenclatura y los requisitos de pruebas y validación.
GitHub también permite crear archivos de instrucciones vinculados a rutas concretas dentro de .github/instructions. Estos archivos utilizan el campo applyTo para determinar los archivos o casos a los que se aplican las instrucciones. Así, es posible combinar directrices generales con reglas más específicas, sin imponer un único estilo a todos los tipos de archivos.
Convertir los procedimientos repetitivos en habilidades
Las instrucciones generales no son adecuadas para todos los procedimientos. Operaciones como ejecutar comprobaciones de calidad, preparar una versión o diagnosticar un fallo del flujo de trabajo requieren pasos que puedan repetirse. Para este fin, GitHub propone utilizar habilidades de agentes, que son carpetas que pueden incluir instrucciones, scripts y recursos adicionales.
Las habilidades específicas del proyecto pueden colocarse en .github/skills, con una carpeta dedicada a cada habilidad. Una carpeta como quality-checks puede contener un archivo SKILL.md que determine cuándo utilizar la habilidad, los comandos para probar y comprobar el estilo del código, qué revisa cada comando y cómo gestionar los casos de fallo habituales.
¿Cuándo necesitas un agente personalizado?
Algunas tareas van más allá de un único procedimiento y abarcan varios archivos y herramientas. GitHub pone como ejemplo la revisión de la accesibilidad, que puede requerir comprobar componentes, plantillas, estilos e interacciones. En estos casos, se puede crear un agente personalizado dentro de .github/agents, definiendo su objetivo, instrucciones, herramientas y contexto relevante para el proyecto.
Esta opción resulta adecuada cuando un tipo concreto de trabajo se repite y se beneficia de un rol especializado o de una perspectiva específica, especialmente si requiere trabajar con varios archivos y fuentes de contexto.
Ampliar el alcance de Copilot mediante servidores MCP
Las instrucciones, las habilidades y los agentes ayudan a Copilot a comprender cómo trabajar dentro del proyecto, mientras que los servidores de Model Context Protocol (MCP) lo conectan con herramientas, fuentes de datos y servicios externos al repositorio. Un servidor de documentación puede proporcionar directrices de un marco de trabajo, mientras que un servidor como Playwright permite abrir la aplicación e interactuar con ella mediante el navegador.
Después de configurar Playwright, se puede solicitar que pruebe manualmente las funcionalidades utilizando un servidor MCP. De este modo, la validación no se limita a que las pruebas automatizadas tengan éxito; Copilot también puede comprobar el comportamiento de la interfaz después del cambio e interactuar con ella en el navegador.
¿Qué cambia en la práctica?
El beneficio principal consiste en trasladar el conocimiento repetitivo de la conversación a archivos revisables dentro del repositorio. Las instrucciones definen los estándares, las habilidades documentan los procedimientos, los agentes se centran en las tareas complejas y los servidores MCP añaden la capacidad de utilizar herramientas externas. GitHub recomienda comenzar gradualmente: elige una regla cuya explicación repitas, colócala en .github/copilot-instructions.md y observa cómo la aplica Copilot.
El artículo también señala el repositorio Awesome Copilot, que incluye instrucciones, habilidades y agentes listos para compartir. Sin embargo, sigue siendo necesario adaptar estos recursos a las herramientas y los estándares del proyecto antes de adoptarlos.