Cómo determinar qué archivo de instrucciones de Copilot se lee en cada entorno (Guía 2026)

GitHub publica la lista completa y la presenta así: "La siguiente lista muestra el orden de precedencia completo, teniendo mayor prioridad las instrucciones que aparecen más arriba en la lista". Las entradas, en ese orden, son: instrucciones personales; luego, instrucciones personalizadas del repositorio, que a su vez se ordenan como "Instrucciones específicas de ruta en cualquier archivo .github/instructions/**/*.instructions.md aplicable", luego "Instrucciones para todo el repositorio en el archivo .github/copilot-instructions.md", luego "Instrucciones de agente (por ejemplo, en un archivo AGENTS.md)"; y finalmente, instrucciones personalizadas de la organización.

Hay tres cosas en esa lista que sorprenden a la gente.

Lo personal supera a todo. La mayoría de los sistemas de instrucciones en software colocan a la organización en la cima y al individuo en la base. Copilot hace lo contrario, y es deliberado: una instrucción de la organización para responder siempre en un idioma es un valor predeterminado, no un mandato, y un individuo puede anularla. GitHub es explícito al señalar que las instrucciones de la organización "se utilizan para todos los miembros de la organización, independientemente de si reciben su suscripción de Copilot de esa organización"; se aplican de forma generalizada y, aun así, ocupan el último lugar.

Los archivos de agente se sitúan por debajo de los archivos del repositorio. AGENTS.md, CLAUDE.md y GEMINI.md se listan por debajo tanto de .github/instructions/**/*.instructions.md como de .github/copilot-instructions.md. Los equipos que migraron a un archivo de agente independiente del proveedor y dejaron el archivo de repositorio antiguo en su lugar han, sin querer, relegado el archivo más nuevo. La dirección de la migración en sí es un ejercicio real con sus propios pros y contras, que analizamos en al mover un CLAUDE.md a AGENTS.md y, para este destino específico, en al mover un CLAUDE.md a Copilot.

Nada se descarta. Esta es la frase que cambia la forma en que debes leer toda la lista: "Sin embargo, todos los conjuntos de instrucciones relevantes se proporcionan a Copilot". La precedencia aquí no es un filtro que descarta a los perdedores. Cada conjunto aplicable se entrega al modelo, y el orden describe cuál gana en caso de conflicto. Por lo tanto, una regla contradictoria que olvidaste eliminar sigue estando en el prompt, consumiendo atención y, ocasionalmente, ganando debido a una redacción que no previste. El consejo de GitHub es directo: "Siempre que sea posible, intenta evitar proporcionar conjuntos de instrucciones en conflicto".

Debajo de todo esto se encuentra la cuestión de la cobertura. Sobre las instrucciones de agentes, GitHub escribe que son "similares a las instrucciones personalizadas para todo el repositorio, pero actualmente no son compatibles con todas las funciones de Copilot", y que "se especifican en archivos llamados AGENTS.md, CLAUDE.md o GEMINI.md". Para las instrucciones de la organización, la nota de compatibilidad es aún más restringida: "Las instrucciones personalizadas de la organización actualmente solo son compatibles con Copilot Chat en GitHub.com, la revisión de código de Copilot en GitHub.com y el agente en la nube de Copilot en GitHub.com".

Al leer estas dos notas juntas, surge la estructura práctica. Qué archivo rige una respuesta depende del entorno de Copilot en el que te encuentres, y el mismo repositorio puede comportarse de manera diferente en el editor, en el chat de GitHub.com y en una revisión de pull request, sin que aparezca ningún mensaje en ningún lado que indique qué reglas se cargaron. Este es el modo de fallo general que describimos en por qué los agentes omiten silenciosamente tus archivos de instrucciones.

Añadir la regla de nuevo, un nivel más arriba. El instinto cuando se ignora una regla es escalarla: si el archivo del repositorio no funciona, colócalo en la configuración de la organización. Dado el orden publicado, eso mueve la regla hacia abajo en la lista de precedencia, no hacia arriba. Si una instrucción personal la contradice, escalarla empeora la contradicción.

Consolidar todo en un solo archivo. Es razonable y elimina los conflictos. Sin embargo, también descarta lo único que las instrucciones con alcance de ruta hacen bien: .github/instructions/**/*.instructions.md se aplica allí donde coincide, que es como evitas que las convenciones del front-end interfieran en una respuesta del back-end. Reducir todo a un único archivo para todo el repositorio hace que cada regla sea global.

Eliminar el archivo antiguo sin comprobar qué entorno lee cuál. Solo es seguro si conoces la respuesta. Dado que está documentado que las instrucciones de agentes no son compatibles con todas las funciones de Copilot, eliminar .github/copilot-instructions.md en favor de AGENTS.md puede dejar algunos entornos sin nada en absoluto, y no te lo advertirá.

Probar en el lugar equivocado. La gente verifica una instrucción de repositorio en el editor y concluye que funciona en todas partes, o prueba en el chat de GitHub.com y concluye lo contrario. Dadas las notas de compatibilidad por entorno, una prueba solo demuestra el funcionamiento en ese entorno específico.

Asumir que una pull request lee el estado fusionado (merged). No lo hace. GitHub es específico: "Al revisar una pull request, Copilot lee las instrucciones personalizadas del repositorio, las instrucciones del agente y las habilidades del agente de la rama de origen (head branch, la rama con tus cambios), no de la rama de destino (base branch)". La ventaja se menciona en la misma nota: "para que puedas probar los cambios en ellas en la misma pull request", y la desventaja es la otra cara de la moneda: una rama que se ha desviado de main se revisa a sí misma con sus propias reglas antiguas.

Tratar los archivos de instrucciones como una capa de memoria. Son configuraciones que se vuelven a leer, no un registro que se acumula. Configurar la parte persistente es un ejercicio independiente, que se detalla en configurar la memoria de Copilot en VS Code.

El objetivo no es elegir el único archivo verdadero. Es ser capaz de responder, en cinco segundos, qué archivo rige una respuesta determinada.

Step 1: Escribe el orden y luego comprueba qué archivos tienes realmente

Comienza por listar lo que existe en el repositorio: un directorio de instrucciones con alcance de ruta, un archivo para todo el repositorio, un archivo de agente o alguna combinación. Luego, coloca tus instrucciones personales junto a ellos, porque en el orden publicado superan a los tres.

El descubrimiento común en este punto es un archivo que nadie recuerda haber añadido. Dado que todos los conjuntos aplicables se proporcionan a Copilot en lugar de filtrarse, un archivo abandonado no es inerte: sigue estando en el prompt. Elimina lo que no estés manteniendo antes de ajustar lo que sí.

Step 2: Decide el alcance por regla, no por archivo

La propia guía de GitHub se centra en el alcance: las instrucciones personalizadas "son más efectivas cuando son declaraciones cortas e independientes", y debes "considerar el alcance sobre el cual deseas que se aplique la instrucción al elegir si deseas agregar una instrucción a nivel personal, de repositorio o de organización".

Ese es el eje de decisión correcto. Una preferencia de idioma es personal. Una convención de framework es para todo el repositorio. Una regla que solo se aplica a un directorio pertenece a un archivo con alcance de ruta, que es la única capacidad a la que renuncias al consolidar. Una política que cada miembro debería recibir por defecto, y que puede anular, es de nivel de organización, y vale la pena escribirla sabiendo que ocupa el último lugar y que es compatible con tres entornos de GitHub.com.

Step 3: Verifica por entorno y verifica en la rama que estás revisando

Ejecuta el mismo prompt en cada entorno que tu equipo use realmente y toma nota de dónde se cumple la regla. Es un ejercicio de diez minutos que reemplaza una discusión recurrente.

Para las pull requests, recuerda la regla de la rama de origen (head branch). Si cambias un archivo de instrucciones y quieres que la revisión lo refleje, cámbialo en la rama bajo revisión. Si una rama de larga duración genera revisiones que ignoran una regla que todos acordaron el mes pasado, comprueba si esa regla llegó a la rama. Las capas en conflicto en un repositorio son su propio problema de mantenimiento, que abordamos en conciliar capas de instrucciones contradictorias.

Los archivos de instrucciones responden a "cómo debes comportarte". Son un mal lugar para "qué decidimos y por qué", que es lo que la gente sigue intentando almacenar en ellos. MemoryLake es un almacén donde escribes esas decisiones a propósito, manteniéndolas al margen de la configuración de cualquier herramienta y accesibles desde cada asistente que conectes. Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de los sistemas de GitHub ni del almacén de ningún otro proveedor; los archivos de tu repositorio y la configuración de Copilot permanecen completamente bajo sus propios controles.

Step 1: Crea una clave API

Genera una clave desde el panel de control. Esto es lo que permite que Copilot, un agente de terminal y un asistente de chat accedan al mismo conjunto de datos sin que cada uno necesite su propio archivo.

Step 2: Sube tus primeros recuerdos

Comienza con las decisiones detrás de las reglas: por qué existe la convención, qué reemplazó, qué enfoque se descartó y bajo qué argumentos. Los archivos de instrucciones contienen la regla; rara vez contienen la razón, que es lo que evita que la siguiente persona revoque la regla.

Step 3: Conecta tu IA y agentes

Apunta tus herramientas a la capa para que esos datos se carguen al inicio de una sesión en lugar de inferirse de un archivo de reglas. Luego, pruébalo de la única manera que demuestra algo: pídele a un asistente diferente que te devuelva una de las decisiones. Si responde, tu razonamiento habrá dejado de estar ligado al formato de archivo de un único proveedor.

El primer cambio es que la discusión sobre la precedencia termina. El orden está publicado, lo personal supera a la organización y todos los conjuntos se proporcionan de todos modos. Una vez que un equipo ha leído la lista en conjunto, la mayor parte del debate se convierte en una breve limpieza.

El segundo es que la cobertura se convierte en la pregunta que la gente realmente se hace. "Qué archivo gana" importa mucho menos que "qué archivo se lee siquiera aquí", y las notas de compatibilidad por entorno es donde se encuentran las sorpresas.

El tercero es que los archivos abandonados dejan de ser inofensivos. Dado que cada conjunto aplicable llega al modelo, un archivo antiguo es un participante activo. Tratar la eliminación como mantenimiento en lugar de simple limpieza cambia el comportamiento de inmediato.

El cuarto es que las revisiones de pull requests se vuelven predecibles. Leer las instrucciones de la rama de origen (head branch) es un diseño sensato (te permite probar cambios de reglas en la misma pull request) y solo es una trampa mientras no se conoce.

Mantén un archivo por alcance y elimina el resto. Con alcance de ruta para reglas de directorio, para todo el repositorio para reglas de proyecto, archivo de agente donde tus otras herramientas lo necesiten, y personal para ti.

Escribe declaraciones cortas e independientes. Es la propia guía de GitHub, y cobra más importancia cuando se combinan varios conjuntos.

Espera que ganen las instrucciones personales. Si una regla de equipo sigue perdiendo, comprueba si la configuración personal de alguien la contradice antes de reescribir el archivo del repositorio.

Verifica cada entorno por separado. Las instrucciones de agentes están documentadas como no compatibles con todas las funciones de Copilot, y las instrucciones de la organización como compatibles en tres entornos de GitHub.com.

Cambia los archivos de instrucciones en la rama bajo revisión. Las revisiones de pull requests los leen de la rama de origen (head branch), no de la rama de destino (base branch).

Keep the reasoning somewhere else. Un archivo de reglas que también lleva su propio historial deja de ser corto, y la brevedad es lo que hace que funcione.

GitHub publica el orden de precedencia completo para las instrucciones de Copilot, y vale la pena conocer su estructura: primero las instrucciones personales, luego las instrucciones del repositorio con alcance de ruta, luego el archivo para todo el repositorio, luego los archivos de agente como AGENTS.md, y por último las instrucciones de la organización. Todos los conjuntos aplicables se siguen proporcionando a Copilot, por lo que la precedencia decide los conflictos en lugar de eliminar a los perdedores.

La parte que causa más tardes perdidas es la cobertura en lugar del orden. Las instrucciones de agentes "actualmente no son compatibles con todas las funciones de Copilot", las instrucciones de la organización están documentadas para tres entornos de GitHub.com y las revisiones de pull requests leen estos archivos de la rama de origen (head branch). Una regla puede estar perfectamente escrita, correctamente ubicada y, simplemente, no cargarse donde la probaste.

Nada de esto es un fallo, y GitHub lo documenta todo abiertamente. La medida práctica es tener menos archivos, decidir el alcance de cada regla de manera deliberada, verificar en cada entorno que use tu equipo y mantener el razonamiento detrás de las reglas en un lugar que un archivo de configuración nunca estuvo destinado a albergar.