Le pides a Copilot que añada una pantalla a tu aplicación. El código funciona, pero usa otra estructura de carpetas, olvida tus pruebas y te propone comandos que ni existen en el proyecto. Repetir las reglas en cada chat ayuda una vez; dejarle contexto dentro del repositorio ayuda en la siguiente tarea también.

GitHub publicó el 12 de octubre de 2026 una guía sobre cuatro piezas de personalización: instrucciones, skills, agentes especializados y servidores MCP. Es una explicación de capacidades de Copilot, no el anuncio de que las cuatro acaben de estrenarse. Para un equipo pequeño, la prueba más útil empieza con dos archivos y una tarea real.

Primero: las reglas que siempre importan

Crea .github/copilot-instructions.md en la raíz del repositorio. Copilot puede usarlo como contexto general del proyecto. Escribe hechos comprobables: dónde está la lógica, qué scripts existen y cómo reconocer una entrega aceptable. No pegues un manual entero ni afirmes que un comando funciona porque suena habitual. GitHub documenta este archivo y también instrucciones específicas por rutas cuando hacen falta.

Una base que puedes adaptar:

# Cómo trabajar en este repositorio

- Antes de cambiar código, lee README.md y los scripts de package.json.
- Conserva la arquitectura existente; no abras una carpeta nueva si ya hay un patrón equivalente.
- Para cambios de interfaz, comprueba estados de carga, vacío y error.
- Usa solo comandos que existan en package.json; informa cuáles ejecutaste y su resultado.
- Si una prueba no se pudo correr, dilo explícitamente y explica el motivo.
- No modifiques variables de producción ni subas secretos al repositorio.

Este ejemplo no impone npm test a un proyecto que quizá no lo tiene. Cambia las referencias a README.md y package.json si usas otro lenguaje. Lo valioso es que la instrucción se pueda comprobar contra archivos reales. Una regla vaga como “escribe código excelente” no le dice al agente qué hacer cuando encuentra un error.

Segundo: el procedimiento que solo necesitas a veces

Supongamos que cada cambio de interfaz requiere revisar accesibilidad y probar en navegador. Esa es una tarea concreta, no una regla que deba ocupar todo chat. Una skill de proyecto puede vivir en .github/skills/revisar-interfaz/SKILL.md. La documentación de GitHub exige nombre y descripción en el encabezado YAML para ayudar a Copilot a decidir cuándo cargarla.

Reglas estables en las instrucciones; procedimientos de una tarea en la skill.

---
name: revisar-interfaz
description: Revisa cambios de interfaz en este repositorio; úsala cuando se modifiquen componentes, páginas o estilos.
---

1. Identifica las rutas y componentes afectados.
2. Lee package.json y ejecuta los scripts de verificación que existan.
3. Comprueba carga, vacío, error, teclado y tamaño móvil.
4. Si hay navegador disponible, abre la página modificada y describe qué viste.
5. Entrega una lista de fallos reproducibles y los pasos para comprobarlos.

Puedes copiar ambos archivos tal como están para empezar, pero debes ajustar sus rutas y criterios a tu proyecto antes de depender de ellos. Aquí no se ejecutó una sesión de Copilot: el formato y las rutas se contrastaron con la documentación oficial, mientras que el contenido es un ejemplo editorial. Tampoco necesitas crear un agente especializado ni conectar un MCP todavía. Agrega uno cuando una tarea recurrente realmente requiera otro rol o una herramienta externa; cada conexión amplía lo que el agente puede hacer y merece una revisión de permisos.

Cómo saber si mejoró algo

Elige una petición pequeña y representativa, por ejemplo: “Añade un estado vacío a la lista de pedidos”. Guarda el resultado de una ejecución sin estos archivos. Luego añade las instrucciones y la skill, repite una tarea equivalente en el mismo proyecto y compara tres cosas: si respetó la estructura existente, si ejecutó verificaciones disponibles y si informó fallos o límites en lugar de declararse terminado. No compares solo la prosa de la respuesta: revisa el diff y la aplicación.

Si Copilot ignora una regla, comprueba primero que el archivo está en la ruta correcta y que la experiencia de Copilot que usas admite ese tipo de instrucción. El soporte varía entre Copilot Chat, el agente en la nube, la revisión de código y los IDE. Una instrucción por ruta puede servir para archivos concretos, pero no se aplica igual en todas las superficies. Y un documento lleno de normas contradictorias puede empeorar el resultado aunque la herramienta lo lea.

La secuencia práctica es sencilla: empieza por una convención que hoy repites a mano, conviértela en un archivo corto, prueba una tarea real y corrige la instrucción según el diff. Solo después encapsula procedimientos en skills o añade MCP. Así construyes contexto que vive con el código y puedes evaluar, en vez de acumular prompts que nadie mantiene.