Cómo migrar tu CLAUDE.md a GitHub Copilot sin perder el contexto (2026)

La perspectiva capa por capa, utilizando la propia documentación de ambos proveedores.

El archivo raíz: se transfiere tal cual. La documentación de instrucciones de GitHub enumera los archivos AGENTS.md en cualquier lugar del repositorio, teniendo prioridad el archivo más cercano en el árbol de directorios, y nombra a CLAUDE.md o GEMINI.md en la raíz del repositorio como alternativas. Por lo tanto, Copilot lee un CLAUDE.md raíz sin modificaciones. Si el conocimiento de tu proyecto está concentrado allí (comandos de compilación, convenciones, notas de arquitectura), ya has migrado la mayor parte de lo que importa.

Reglas con alcance de ruta: se transfieren con un mapeo limpio. Este es el par mejor emparejado en todo el proceso. El directorio .claude/rules/ de Claude Code contiene archivos markdown que pueden llevar un campo de frontmatter paths:, de modo que una regla solo se carga cuando Claude trabaja con archivos que coinciden. El equivalente de Copilot es .github/instructions/NAME.instructions.md, cuyo frontmatter acepta un campo applyTo utilizando sintaxis glob. Misma idea, mismo vocabulario glob, diferente convención de nombres de archivo. Una regla con alcance para src/api/**/*.ts en un sistema es una regla con alcance para src/api/**/*.ts en el otro.

Instrucciones para todo el repositorio: un segundo hogar redundante. Copilot también admite .github/copilot-instructions.md, que se aplica a todas las solicitudes en el contexto del repositorio. No lo necesitas si ya se está leyendo tu CLAUDE.md raíz, y mantener ambos invita al problema de la desincronización: dos archivos, uno se actualiza y el otro no. Elige uno como la fuente de verdad.

Archivos `CLAUDE.md` anidados: no se transfieren. Aquí está la parte que confunde a la gente. La documentación de Claude Code describe el recorrido hacia arriba en el árbol de directorios desde el directorio de trabajo, cargando CLAUDE.md y CLAUDE.local.md de cada directorio a lo largo del camino, concatenando todos los archivos descubiertos en el contexto; los archivos en los subdirectorios también se descubren y se cargan bajo demanda cuando Claude lee archivos allí. Copilot acepta CLAUDE.md en la raíz del repositorio; ese es el alcance documentado. Tu packages/billing/CLAUDE.md es invisible para él. La forma nativa de Copilot para expresar instrucciones por directorio es un AGENTS.md anidado, que según la documentación tiene prioridad cuando es el más cercano en el árbol. En un monorepo, esta única diferencia puede ser la causa de que la mayoría de tus instrucciones no se apliquen silenciosamente.

Importaciones `@`: sin destino. El archivo CLAUDE.md de Claude Code puede incorporar otros archivos con la sintaxis @ruta/al/archivo, de forma recursiva, hasta una profundidad máxima documentada de cuatro saltos. La documentación de instrucciones de GitHub no describe ningún mecanismo de importación. Si tu archivo raíz es un índice delgado que importa cinco documentos reales, Copilot leerá el índice y ninguno de los documentos.

`CLAUDE.local.md`: sin destino. Claude Code admite un archivo CLAUDE.local.md en la raíz del proyecto para preferencias personales que mantienes fuera del control de versiones. La capa de Copilot para preferencias personales son las instrucciones personales, que residen en tu cuenta de GitHub en lugar de en el repositorio. Es una capa real (la prioridad declarada por GitHub es: "Las instrucciones personales tienen la prioridad más alta. Las instrucciones del repositorio vienen a continuación, y luego las instrucciones de la organización se priorizan al final"), pero no es un archivo en tu copia local, por lo que el contenido se traslada escribiéndolo de nuevo, no copiándolo.

Memoria automática: sin destino, y para empezar, no era portable. La memoria automática de Claude Code está activada por defecto, almacena notas por proyecto en ~/.claude/projects/<proyecto>/memory/, carga las primeras 200 líneas o 25 KB de MEMORY.md en cada sesión, y es explícitamente local de la máquina (la documentación dice que los archivos "no se comparten entre máquinas o entornos en la nube"). La documentación de instrucciones de GitHub no contiene ninguna declaración sobre la persistencia de la memoria o el contexto entre sesiones; los archivos de instrucciones son el mecanismo de persistencia documentado. Por lo tanto, esta capa no se transfiere, y la razón no es el diseño de Copilot, sino que la capa nunca fue un artefacto compartido en primer lugar. Si ya te has topado con esa pared, es la misma que se describe en por qué Claude Code olvida entre máquinas.

Una nota de encuadre antes de los pasos: ambos sistemas describen las instrucciones como contexto en lugar de imposición. La documentación de Claude Code dice que las instrucciones son "contexto, no configuración impuesta" y que el contenido se entrega como un mensaje de usuario después del prompt del sistema con "ninguna garantía de cumplimiento estricto". La declaración de prioridad de GitHub termina con "Sin embargo, todos los conjuntos de instrucciones relevantes se proporcionan a Copilot". Ningún proveedor promete obediencia. Planifica la migración en torno a lo que se lee, no en torno a lo que esperas que se obedezca.

Paso 1: Mapear las capas que tienen un hogar

Trabaja de arriba hacia abajo y resiste la tentación de consolidar todo en un solo archivo gigante.

Deja el CLAUDE.md raíz donde está. Funciona. Si prefieres ser explícito para los compañeros de equipo que no saben que Copilot lo lee, agrega un comentario de una línea en la parte superior del archivo que diga que ambos agentes leen esto. No lo dupliques en .github/copilot-instructions.md; mantendrás dos copias y una quedará desactualizada.

Convierte cada archivo .claude/rules/*.md que tenga un campo paths: en .github/instructions/<nombre>.instructions.md con los mismos globs bajo applyTo. Mantén los nombres de archivo reconocibles para que el par sea obvio en un diff. Las reglas que no tienen un campo paths: son del tipo incondicional (Claude Code las carga al inicio con la misma prioridad que .claude/CLAUDE.md), por lo que pertenecen a tu archivo raíz o a un AGENTS.md, no al directorio con alcance de ruta.

Promueve los archivos CLAUDE.md anidados a archivos AGENTS.md anidados en los mismos directorios. Esto es un cambio de nombre más una decisión: si deseas que ambos agentes lean el mismo contenido anidado, ten en cuenta que la documentación de Claude Code es directa sobre la asimetría: "Claude Code lee CLAUDE.md, no AGENTS.md", y su patrón recomendado es un CLAUDE.md que importa AGENTS.md con @AGENTS.md, o un enlace simbólico (symlink). Así que en cada subdirectorio puedes mantener un archivo real (AGENTS.md) y un CLAUDE.md de una línea que lo importe. Ambos agentes leerán el mismo texto; solo hay un lugar para editar.

Aplana tus importaciones antes de continuar. Cada archivo importado con @ debe convertirse en contenido integrado (inline) en el archivo que lo importó, en un AGENTS.md anidado en el directorio correspondiente, o en un archivo de instrucciones con alcance de ruta. Las propias notas de Claude Code señalan que dividir en importaciones "ayuda a la organización pero no reduce el contexto, ya que los archivos importados se cargan al inicio", por lo que aplanar no te cuesta nada en términos de contexto en el lado de Claude, y es la única forma en que el contenido llega a Copilot.

Paso 2: Decidir qué pasa con las capas que no tienen hogar

Tres grupos, y cada uno necesita una decisión real en lugar de una por defecto.

`CLAUDE.local.md`. Léelo y clasifícalo. La mayoría de estos archivos son una mezcla de preferencias genuinamente personales (tu URL de sandbox, tus datos de prueba preferidos) y datos del proyecto que deberían haberse confirmado (commit) hace meses. Confirma el segundo tipo en el archivo raíz (te alegrarás de haberlo hecho, independientemente de Copilot) y vuelve a escribir el primer tipo en las instrucciones personales de Copilot, recordando que estas se aplican a cada repositorio en el que trabajas, no solo a este. Elimina todo lo que no quieras en ninguno de los dos lugares. Un archivo que solo una herramienta en una máquina puede leer no es un almacén de conocimiento.

Memoria automática. Abre el directorio de memoria y lee MEMORY.md junto con los archivos de temas. Esta es la hora de mayor valor de toda la migración, porque es un registro escrito de lo que Claude descubrió sobre tu proyecto y que nunca te molestaste en documentar: peculiaridades de compilación, ideas de depuración, la razón por la que una prueba es inestable. Nada de esto va a llegar a Copilot por sí solo. Promueve los datos duraderos a tu archivo raíz o a un archivo de instrucciones con alcance de ruta. Deja el resto (notas sobre los hábitos de un modelo, seguimientos de depuración únicos) donde están. No están mal, simplemente no son conocimiento compartido.

Mecanismos exclusivos de Copilot que querrás en el camino de regreso. Existen dos cosas en el lado de Copilot que no tienen equivalente en Claude Code, y conocerlas ahora evita sorpresas más adelante. Los archivos de instrucciones específicos de ruta admiten un campo opcional excludeAgent, que evita su uso por parte de "code-review" o "cloud-agent", por lo que una regla que mantuviste deliberadamente fuera de la revisión de código no tiene forma de quedarse fuera en el otro lado. Y las instrucciones de la organización son una capa real que alguien más puede controlar; GitHub las clasifica en último lugar de prioridad, pero aun así las proporciona. Si migras de regreso, o ejecutas ambos, pregúntale a un administrador qué hay en esa capa. Da forma a resultados que nunca configuraste.

Hacer lo anterior una vez es razonable. Hacerlo cada vez que aparece un nuevo agente es el verdadero problema, y la aritmética está empeorando: cada herramienta inventa su propio nombre de archivo, su propio frontmatter, su propio orden de prioridad y su propio almacén de memoria privado, por lo que N herramientas significan N copias del mismo conocimiento del proyecto desincronizándose a N ritmos diferentes.

MemoryLake existe para romper ese patrón: mantén el conocimiento del proyecto en una sola capa de memoria y deja que cada agente lea de ella en lugar de su propia copia local. Los archivos de instrucciones se quedan donde pertenecen (para las reglas que deben estar en el contexto en cada sesión), mientras que el cuerpo de conocimiento acumulado y en crecimiento vive en un lugar al que ambos agentes pueden acceder. La configuración consta de tres pasos.

Paso 1: Crear una clave API

Inicia sesión en MemoryLake y crea una clave API. Una sola credencial, utilizada por cada herramienta que conectes, que es el punto: la credencial sobrevive a tu elección actual de agente.

Paso 2: Sube tus primeras memorias

Comienza con el material que acabas de excavar durante la migración: los datos duraderos de la memoria automática, las verdades del proyecto que se escondían en CLAUDE.local.md, el registro de decisiones, las razones detrás de las convenciones que parecen arbitrarias sin ellas. Mantén las entradas cortas y específicas. La prueba de una buena entrada es si un nuevo compañero de equipo, o un nuevo agente, podría actuar en consecuencia sin hacer una pregunta de seguimiento.

Paso 3: Conecta tu IA y agentes

Conecta tus herramientas. MemoryLake es accesible a través de MCP y de una API, por lo que los agentes nativos de MCP (entre ellos Claude Code, Codex, OpenClaw) se conectan apuntando al servidor MCP, mientras que cualquier otra cosa lee la misma memoria a través de la API. Los archivos de instrucciones siguen haciendo su trabajo específico; el conocimiento compartido deja de duplicarse por herramienta.

Dos límites honestos. MemoryLake no es una capa de imposición: si una regla debe cumplirse independientemente de lo que decida un modelo, eso pertenece a un hook o a una verificación de CI, exactamente como sugieren los documentos de ambos proveedores cuando llaman a las instrucciones contexto en lugar de configuración. Y no lee tus archivos existentes por ti: el inventario de migración anterior sigue siendo un trabajo que haces una sola vez.

El segundo agente cuesta menos que el primero. La parte costosa de agregar Copilot junto a Claude Code no es la configuración, sino volver a deducir el conocimiento que ya estaba implícito en la configuración de la primera herramienta. Haz eso una vez en una capa compartida y el tercer agente será una simple conexión, no un proyecto entero.

Los monorepos dejan de ser un caso especial. La asimetría de los archivos anidados es la forma más común en que las instrucciones fallan silenciosamente al aplicarse. Cuando el conocimiento por área es recuperable en lugar de depender de qué archivo descubre cada herramienta en qué directorio, la estructura de árbol deja de ser una superficie de compatibilidad.

Los archivos de instrucciones se vuelven más cortos, lo que hace que funcionen mejor. Los documentos de Claude Code recomiendan apuntar a menos de 200 líneas por archivo y señalan que los archivos más largos "consumen más contexto y reducen el cumplimiento". La guía de Copilot va en la misma dirección. Mover el conocimiento de referencia fuera del archivo que siempre se carga y llevarlo a algo que se recupera bajo demanda no es solo orden: mejora notablemente la confiabilidad con la que se siguen las reglas restantes.

La revisión detecta la desincronización en lugar de ocultarla. Con una sola fuente de verdad, una entrada desactualizada es un diff. Con cinco copias por herramienta, una entrada desactualizada es un misterio sobre por qué un agente cree algo que el otro no.

Un archivo real por directorio, más un puntero. Mantén AGENTS.md como el contenido y un CLAUDE.md de una línea que lo importe. Ambos agentes leen el mismo texto y hay exactamente un lugar para editar.

Nunca dupliques el archivo raíz. Un CLAUDE.md raíz y un .github/copilot-instructions.md que contengan texto casi idéntico es una inconsistencia futura garantizada. Elige uno.

Mantén los globs idénticos en ambos sistemas. Cuando paths: y applyTo describen el mismo conjunto de archivos con la misma sintaxis, puedes revisarlos como un par. Cuando se desvían, obtienes reglas específicas de área que se aplican en una herramienta y no en la otra, lo cual es peor que no tenerlas.

Verifica qué se cargó después de cada cambio estructural. Claude Code expone la lista de archivos de memoria cargados en la sesión; verifícala después de mover archivos. En el lado de Copilot, confirma que realmente se esté detectando un AGENTS.md anidado antes de asumir que es así. Un archivo que no se lee se ve exactamente como un modelo que ignora las instrucciones, la distinción que se cubre en por qué GitHub Copilot olvida el contexto del código base.

Pregunta sobre la capa de la organización. Si tu repositorio está bajo una organización con instrucciones configuradas, ese texto se le está proporcionando a Copilot lo hayas leído o no. Léelo.

Coloca las reglas que deben cumplirse en la imposición, no en las instrucciones. Ambos proveedores son explícitos en que los archivos de instrucciones moldean el comportamiento en lugar de garantizarlo. Cualquier cosa que deba suceder antes de cada commit pertenece a un hook o a la CI.

El titular de esta migración es inusualmente agradable: Copilot lee un CLAUDE.md raíz, por lo que el archivo que ya mantienes sigue funcionando. El trabajo está en las cuatro capas que lo rodean: archivos anidados que deben promoverse a AGENTS.md, importaciones que deben aplanarse, un archivo local que debe clasificarse y un directorio de memoria automática que contiene conocimiento que nunca fue compartible.

Haz ese inventario una vez y coloca su resultado en un lugar al que ambos agentes puedan acceder. De lo contrario, lo harás de nuevo para la próxima herramienta, desde una posición inicial ligeramente peor, porque para entonces dos copias se habrán desincronizado. Si también te estás moviendo en la otra dirección, migrar GitHub Copilot a Claude Code cubre el viaje inverso, y migrar CLAUDE.md a Cursor maneja el tercer destino común.