Cómo migrar de GitHub Copilot a Factory Droid sin perder el contexto (2026)

Copilot documenta tres tipos de instrucciones personalizadas de repositorio, además de dos capas más por encima y por debajo de ellas.

Las tres a nivel de repositorio:

"Instrucciones personalizadas para todo el repositorio, que se aplican a todas las solicitudes realizadas en el contexto de un repositorio. Estas se especifican en un archivo copilot-instructions.md en el directorio .github del repositorio."

"Instrucciones personalizadas específicas de la ruta, que se aplican a las solicitudes realizadas en el contexto de archivos que coinciden con una ruta especificada. Estas se especifican en uno o más archivos NAME.instructions.md dentro o debajo del directorio .github/instructions en el repositorio."

"Instrucciones del agente, que son similares a las instrucciones personalizadas para todo el repositorio, pero actualmente no son compatibles con todas las funciones de Copilot. Estas se especifican en archivos llamados AGENTS.md, CLAUDE.md o GEMINI.md."

Por encima de ellas se encuentran las instrucciones personales, que se configuran "en una ventana emergente en la página de Copilot Chat en GitHub.com" y que "Copilot solo te aplicará a ti". Por debajo de ellas se encuentran las instrucciones personalizadas de la organización, que "solo pueden ser configuradas por los propietarios de la organización para organizaciones con una suscripción a Copilot Business o Copilot Enterprise".

La cadena de precedencia está documentada de arriba a abajo: instrucciones personales, luego específicas de la ruta, luego para todo el repositorio, luego instrucciones del agente y, por último, de la organización. Y hay una cláusula en esa sección que cambia la forma en que se debe planificar la migración:

"Se pueden aplicar múltiples tipos de instrucciones personalizadas a una solicitud enviada a Copilot. Las instrucciones personales tienen la prioridad más alta. Las instrucciones del repositorio van a continuación, y luego las instrucciones de la organización se priorizan en último lugar. Sin embargo, todos los conjuntos de instrucciones relevantes se proporcionan a Copilot."

Lee la última frase con atención. La precedencia resuelve conflictos; no excluye nada. Todo lo que sea relevante se incluye.

El modelo de Factory es deliberadamente más estrecho. Su documentación de AGENTS.md describe un archivo con una tarea específica:

"AGENTS.md le da a Droid la sesión informativa del proyecto que debe llevar a cada sesión: cómo instalar, ejecutar, probar, editar, verificar y mantenerse dentro de los límites de tu repositorio."

Y es explícito sobre la estructura y el alcance:

"Agrega AGENTS.md en la raíz del repositorio. Comienza con un archivo, luego agrega archivos anidados solo donde un paquete, aplicación o servicio necesite reglas diferentes."

"Úsalo para obtener orientación que deba cargarse antes de que Droid escriba código. Mantenlo corto, específico y fácil de verificar."

Así que lo que se transfiere es esto. Tu archivo para todo el repositorio se transfiere casi directamente. Tu AGENTS.md —si ya tienes uno para las instrucciones del agente de Copilot— se transfiere tal cual y ahora es la superficie principal en lugar de la de menor precedencia. Tus instrucciones específicas de la ruta se transfieren en contenido pero cambian de mecanismo. Y tus instrucciones personales y de organización no se transfieren en absoluto, porque no hay nada que copiar: unas viven en una ventana emergente web con alcance para ti, las otras en la configuración de la organización con alcance para tu empresa.

Paso 1: Recopilar las dos capas que no son archivos y decidir a dónde van

Este es el paso que se suele omitir, así que hazlo primero.

Instrucciones personales. Abre la página de Copilot Chat en GitHub.com y lee lo que hay en esa ventana emergente. En la mayoría de los equipos contiene dos tipos de cosas: preferencias individuales genuinas ("explicar un solo concepto por línea", "responder siempre en portugués", los propios ejemplos de la documentación) y reglas que nunca deberían haber sido personales en primer lugar, porque describen cómo funciona el proyecto y todos los compañeros de equipo las necesitan.

Divídelas. Las preferencias individuales pertenecen a la configuración a nivel de usuario de Factory, que se encuentra en ~/.factory/settings.json en macOS y Linux, junto con un archivo opcional settings.local.json. Las reglas del proyecto que se ocultaban en tu ventana emergente personal pertenecen al archivo AGENTS.md del repositorio, donde el resto del equipo finalmente las recibe. Este suele ser el resultado individual más valioso de toda la migración, y es invisible si solo migras archivos.

Instrucciones de la organización. Estas requieren que un administrador las lea, y vale la pena capturarlas aunque la superficie de instrucciones de Factory no documente una capa equivalente por organización. Ten en cuenta que la propia documentación de Copilot limita su alcance: "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". Por lo tanto, hay una gran probabilidad de que las instrucciones de la organización nunca hayan afectado a tus sesiones de IDE de todos modos. Confirma esto antes de decidir cuánto transferir.

Cualquier cosa que se aplique genuinamente a cada repositorio va a la configuración de .factory/ a nivel de usuario o de proyecto y al AGENTS.md del repositorio. Cualquier texto estándar de cumplimiento que nunca llegó al IDE se puede descartar con una nota que explique el motivo.

Paso 2: Resolver los conflictos que Copilot te permitió posponer, luego reconstruir el alcance

Debido a que Copilot proporciona todos los conjuntos de instrucciones relevantes y utiliza la precedencia solo para resolver desacuerdos, un equipo puede trabajar durante un año con dos capas que se contradicen entre sí sin darse cuenta. La de mayor precedencia gana y la inferior se queda ahí.

La guía de Factory va en la dirección opuesta. Su documentación de AGENTS.md solicita reglas que sean "cortas, específicas y fáciles de verificar", recomienda colocar primero los comandos exactos de instalación, desarrollo, prueba, verificación de tipos, lint y compilación, y traza una línea clara sobre qué pertenece a cada lugar:

"Mantén la incorporación de humanos, las capturas de pantalla y los antecedentes de los colaboradores en README.md. Coloca los comandos específicos de Droid, las barandillas de seguridad y los criterios de finalización en AGENTS.md."

También solicita algo que el formato de Copilot no pide: una sección de verificación que indique la prueba requerida antes de que Droid considere terminado el trabajo. La documentación contrasta las reglas concretas que cambian la forma en que funciona Droid con las "reglas vagas que no se pueden verificar". Si tu copilot-instructions.md contiene una línea como "escribir buen código", aquí es donde se elimina en lugar de portarse.

Así que escribe un AGENTS.md raíz con los comandos primero, luego el mapa del repositorio, las convenciones, las reglas de prueba, las reglas de archivos generados, los límites de seguridad y los pasos de verificación. Donde dos capas antiguas no estaban de acuerdo, elige una. Esa decisión es un trabajo real, y es el trabajo que la cadena de precedencia de Copilot estaba absorbiendo por ti. Si ya mantienes un CLAUDE.md junto a tus archivos de Copilot, convertir un CLAUDE.md al formato de instrucciones de Copilot cubre lo que suele sobrevivir a ese tipo de consolidación y lo que no, y lo que los agentes de programación realmente leen merece una revisión antes de decidir qué tan largo puede ser el nuevo archivo.

Luego maneja los archivos específicos de la ruta. Los archivos .github/instructions/NAME.instructions.md de Copilot apuntan a patrones de archivos, y la documentación explica por qué existen: "Al usar instrucciones específicas de la ruta, puedes evitar sobrecargar tus instrucciones para todo el repositorio con información que solo se aplica a archivos de ciertos tipos o en ciertos directorios".

Ese propósito sobrevive; el mecanismo cambia. Factory define el alcance de los archivos AGENTS.md anidados por directorio: "agrega archivos anidados solo donde un paquete, aplicación o servicio necesite reglas diferentes". Una regla con alcance a un directorio se porta limpiamente: coloca un AGENTS.md en ese directorio. Una regla con alcance a un tipo de archivo en todo el árbol no tiene un directorio donde vivir, por lo que tienes dos opciones honestas. Si el tipo de archivo se concentra en un área, colócalo allí. Si realmente abarca todo el repositorio, indica el alcance en la primera frase de la propia regla y acepta que ahora está declarado en lugar de coincidir por patrón.

Una cosa más que verificar mientras estás en el repositorio: si encuentras un .droid.yaml, es una superficie obsoleta. La documentación de configuración de Factory dice que uses los archivos .factory/ actuales en su lugar, y que "uses AGENTS.md para las instrucciones del repositorio, las convenciones y los comandos de validación".

Los dos pasos anteriores son una traducción más un conjunto de decisiones. Las decisiones son la parte costosa y, en este momento, existen solo en la cabeza de quien las tomó durante la migración.

Esa es la capa que vale la pena colocar en un lugar duradero. Cuando resolviste un conflicto entre una instrucción personal y una del repositorio, tomaste una decisión sobre qué convención sigue realmente el proyecto. Cuando eliminaste "escribir buen código", decidiste que no era verificable. Dentro de seis meses, alguien encontrará la regla sobreviviente y preguntará por qué dice lo que dice.

MemoryLake guarda esas decisiones fuera de ambos productos y las sirve a cualquier agente que las solicite, a través de MCP o la API. Las propias funciones de memoria de Copilot y la propia configuración de Factory se quedan exactamente donde están y siguen funcionando de la manera que documentan sus proveedores.

Paso 1: Crear una clave API

Genera una clave y realiza tu primera solicitud en unos treinta segundos. Hazlo antes de comenzar el Paso 2 anterior, para que haya un lugar donde colocar cada decisión a medida que la tomes.

Paso 2: Subir tus primeras memorias

Cada conflicto que resuelves es una memoria que vale la pena conservar: qué regla ganó, cuál perdió y por qué. Agrega las reglas que surgieron de un incidente específico y las bibliotecas o patrones que deliberadamente no utilizas. Los documentos y otros archivos de soporte van al mismo lugar.

Paso 3: Conectar tu IA y agentes

Dale acceso a Claude, Codex, OpenClaw y Droid a través de MCP o la API. Una vez conectados, la pregunta "por qué esta es la convención" se responde con el motivo adjunto, que es lo que permite que el AGENTS.md raíz se mantenga tan corto como recomienda Factory.

El primer cambio es que el problema de las instrucciones personales deja de repetirse. Una vez que las reglas del proyecto que se ocultaban en la ventana emergente de una persona están en el repositorio y el razonamiento está en un almacén compartido, ya no hay una capa privada que supere silenciosamente a la del equipo.

El segundo cambio tiene que ver con el Spec Mode, que es donde Factory produce su artefacto más valioso y también donde se encuentra la brecha de durabilidad. El Spec Mode es una planificación de solo lectura que finaliza solicitando aprobación; Droid "no debe editar archivos, cambiar la configuración, realizar confirmaciones (commits), iniciar servicios ni escribir en sistemas externos" mientras se encuentra en él. El plan que produce es el razonamiento de un cambio, redactado exactamente en el momento adecuado. Pero la ubicación de guardado predeterminada es ~/.factory/specs, que es un directorio por usuario fuera del repositorio. Ese es un valor predeterminado razonable y se puede configurar a través de specSaveDir. También es la razón por la que un buen plan puede existir en una computadora portátil y en ningún otro lugar. Apunta specSaveDir a algo confirmado en el repositorio (committed) o acostúmbrate a mover las conclusiones al almacén compartido.

El tercer cambio llega con la próxima migración de herramientas. El archivo de instrucciones se vuelve a escribir; eso es inevitable, y el formato de cada herramienta es un poco diferente. Las decisiones detrás de él no cambian, porque nunca estuvieron en el formato de instrucciones de nadie.

Lee la ventana emergente de instrucciones personales antes de tocar un archivo. Es la capa con la mayor precedencia y la menor visibilidad, y parte de lo que contiene pertenece a todo el equipo.

Pídele a un administrador las instrucciones de la organización, luego verifica si alguna vez se aplicaron. La documentación de Copilot limita su soporte a superficies específicas. Transferir reglas que nunca llegaron a tu IDE es trabajo perdido.

Elimina cualquier cosa que no sea verificable en lugar de portarla. La documentación de Factory solicita reglas que se puedan comprobar y las contrasta con las vagas. Una regla que nadie puede verificar tampoco estaba haciendo nada en Copilot.

Coloca los comandos primero. Instalar, ejecutar, probar, verificar tipos, lint, compilar. El propio orden de pasos de Factory recomienda esto, y es la parte de tu archivo de instrucciones que se amortiza en la primera sesión.

Escribe la sección de verificación. Indica la prueba requerida antes de que Droid considere terminado el trabajo. Nada en el formato de instrucciones de Copilot pedía esto, por lo que probablemente aún no lo tengas.

Decide dónde viven las especificaciones desde el primer día. El valor predeterminado es un directorio por usuario fuera del repositorio. Apunta specSaveDir a algún lugar compartido o mueve el razonamiento manualmente.

La migración de Copilot a Factory Droid es una copia de archivos más dos cosas que no son archivos. Las instrucciones personales viven en una ventana emergente en GitHub.com y superan a todo lo demás; las instrucciones de la organización viven en la configuración de la empresa y, según la propia documentación de Copilot, solo llegan a ciertas superficies. Ninguna de las dos se puede migrar copiando algo, y la primera suele contener reglas del proyecto que nunca debieron ser privadas.

La segunda mitad del trabajo consiste en resolver los conflictos que la cadena de precedencia de Copilot estaba absorbiendo. Debido a que se proporcionan todos los conjuntos de instrucciones relevantes y la precedencia solo resuelve los desacuerdos, las contradicciones podrían pasar desapercibidas durante mucho tiempo. Factory solicita un archivo raíz corto con reglas concretas y comprobables, lo que significa que alguien tiene que elegir un ganador.

Haz primero las dos capas que no son archivos, resuelve los conflictos deliberadamente, decide dónde se guardan las especificaciones y mantén el razonamiento en un lugar donde ningún formato de instrucciones pueda dejarlo varado.