Cómo crear un GitHub Copilot Space que se mantenga al día a medida que cambia tu repositorio (Guía 2026)

Comencemos con lo que puede contener un espacio. GitHub enumera "repositorios, código, pull requests, issues, contenido de texto libre como transcripciones o notas, imágenes y subidas de archivos". Añades dos tipos de contexto: instrucciones, descritas como "Texto libre que describe en qué debe centrarse Copilot dentro de este espacio", y fuentes.

La promesa de frescura se limita a un tipo de fuente. La redacción es precisa: "Los archivos de GitHub y otras fuentes basadas en GitHub añadidas a un espacio se actualizan automáticamente a medida que cambian, lo que convierte a Copilot en un experto siempre actualizado en tu proyecto". Los archivos subidos y el texto que pegas no son fuentes basadas en GitHub. La documentación los describe como contenido que tú añades — "Puedes subir archivos directamente desde tu máquina local" y "Puedes escribir o pegar contenido de texto libre" — y no menciona que se actualicen. Trátalos como instantáneas (snapshots).

El código sigue a una sola rama. La guía de creación establece que "Los espacios siempre harán referencia a la última versión del código en la rama main del repositorio". Si el trabajo actual de tu equipo reside en una rama de desarrollo de larga duración, el espacio responderá desde main.

Los repositorios y los archivos se utilizan de forma diferente. "Cuando adjuntas un repositorio, Copilot no carga todo el proyecto en memoria. En su lugar, busca en el repositorio y recupera solo el contenido más relevante para tu pregunta". Por el contrario, "Cuando adjuntas un archivo, todo su contenido se carga en la ventana de contexto de Copilot y se considera para cada consulta en ese espacio". Un documento que necesitas que Copilot siga siempre debe adjuntarse como un archivo, no dejarse a merced de la búsqueda.

El IDE ve menos. Esta es la regla que más sorprende a la gente. La nota de GitHub dice: "Al usar Spaces en tu IDE, el contexto del repositorio y los archivos subidos no son compatibles". Todo lo demás sigue llegando: el contenido de texto que añadiste, los archivos de GitHub, los issues, los pull requests y las instrucciones del espacio. Un espacio construido principalmente a partir de un repositorio completo adjunto y unos pocos PDF subidos puede parecer muy completo en github.com y llegar muy limitado a tu editor.

Acceder a él desde el IDE requiere configuración. Los Spaces llegan a través del servidor MCP de GitHub, y "El conjunto de herramientas de Spaces no está incluido en la configuración predeterminada, por lo que debes habilitarlo explícitamente usando la cabecera X-MCP-Toolsets". Una vez conectado, "Los Spaces solo se pueden usar en modo agente en tu IDE, ya que se accede a ellos a través del servidor MCP de GitHub".

Y la descripción es para las personas, no para Copilot. GitHub señala que "no afecta a las respuestas de Copilot, sino que ayuda a otros a comprender el propósito del espacio".

Nada de esto es un defecto. Cada regla es una decisión de diseño razonable. Juntas significan que un espacio es tan actual y tan completo como las fuentes que hayas elegido para él.

Subir una exportación de la documentación. Es rápido y funciona desde el primer día. Sin embargo, también congela la documentación en el momento de la subida, y los archivos subidos no llegan a Copilot en el IDE.

Adjuntar todo el repositorio y esperar que Copilot lo sepa todo. Adjuntar un repositorio implica realizar búsquedas, no una carga completa. Es posible que los documentos importantes se recuperen o no para una pregunta determinada, y el contexto del repositorio no forma parte del uso en el IDE.

Pegar un bloque largo de notas una sola vez. El contenido de texto sí llega al IDE, lo cual es bueno. Pero las notas pegadas hace meses se siguen tratando como actuales hasta que alguien las edita.

Escribir el contexto en la descripción. GitHub indica que la descripción no afecta a las respuestas de Copilot.

Crear un espacio separado para cada pregunta. Los Spaces funcionan mejor como colecciones duraderas para un sistema, un flujo de trabajo o una funcionalidad. Muchos espacios pequeños con contenido duplicado y sin mantenimiento se desactualizan más rápido que un único espacio bien mantenido.

El objetivo es un espacio cuyo contenido importante se actualice por sí solo, cuyas instantáneas tengan propietarios y cuyo contexto llegue tanto al IDE como a github.com.

Paso 1: Prioriza los archivos de GitHub y decide entre archivo o repositorio para cada fuente

Haz una lista de lo que un compañero de equipo necesita para entender el sistema: la descripción general de la arquitectura, los módulos clave, el runbook, las convenciones, los problemas de diseño abiertos. Luego, decide cómo entra cada elemento al espacio.

Si reside en un repositorio, añádelo como un archivo de GitHub en lugar de subir una copia. Los archivos de GitHub son las fuentes que, según la documentación, "se actualizan automáticamente a medida que cambian" y están disponibles en el IDE. Si el elemento aún no está en un repositorio pero debería estarlo (un registro de decisiones, una nota de diseño), considera hacer un commit primero. Eso lo hace versionable, revisable y fresco en el espacio.

Elige archivo o repositorio deliberadamente. Adjunta archivos individuales para el puñado de documentos que Copilot debería considerar en cada pregunta, ya que "todo el contenido de un archivo se carga en la ventana de contexto de Copilot". Adjunta un repositorio completo cuando el objetivo sea responder preguntas en un gran volumen de código o documentación en github.com, sabiendo que depende de la búsqueda y no llega al IDE.

Enlaza issues y pull requests que contengan decisiones activas. GitHub te permite pegar sus URL como fuentes, y están disponibles en el IDE.

Verifica la rama. Si main no refleja cómo funciona el sistema hoy en día, indícalo en las instrucciones o apunta el espacio a documentación que esté actualizada en main.

Paso 2: Usa instrucciones y contenido de texto para lo que el repositorio no puede contener, y asígnales propietarios

Algunos contextos no pertenecen a un repositorio: el motivo por el que se pospuso una migración, la restricción del cliente detrás de una elección de API, la lista de verificación que aplica un revisor. Para eso sirven las instrucciones y el contenido de texto.

Escribe las instrucciones como un informe para Copilot. La guía de GitHub es incluir "sus áreas de experiencia, con qué tipo de tareas debería ayudar y qué debería evitar". Mantenlas cortas y específicas para el propósito del espacio.

Coloca información de fondo duradera en el contenido de texto, ya que llega al IDE. Pon fecha a cada bloque y nombra a quién lo mantiene. Una nota con fecha hace visible la obsolescencia; una sin fecha parece actualizada para siempre.

Luego, define los roles. Para los espacios propiedad de una organización, "Los editores pueden actualizar los archivos adjuntos, la descripción, el nombre y las instrucciones del espacio", mientras que "Los lectores pueden usar el espacio para hacer preguntas y ver los archivos adjuntos e instrucciones incluidos". Otorga acceso de edición a las personas propietarias de las instantáneas y añade "revisar el espacio" a la misma lista de verificación que la actualización del runbook. El propio ejemplo de incorporación de GitHub sugiere exactamente esto: "Haz que otras personas sean editores para que cualquiera pueda actualizar los recursos incluidos".

Paso 3: Conéctalo en el IDE y prueba qué llega realmente

Configura el servidor remoto MCP de GitHub con el conjunto de herramientas de Spaces habilitado, luego abre Copilot Chat en modo agente. GitHub sugiere confirmar que las herramientas get_copilot_space y list_copilot_spaces estén listadas y habilitadas.

Ahora prueba con dos preguntas. Haz una cuya respuesta resida en un archivo de GitHub o en contenido de texto, y otra cuya respuesta resida únicamente en un archivo subido o en algún lugar de un repositorio adjunto. Haz ambas preguntas en github.com y en el IDE. La diferencia te mostrará exactamente qué partes del espacio ve tu equipo mientras programa.

Mueve cualquier elemento esencial fuera de las fuentes invisibles para el IDE. Si una respuesta clave solo existe en un PDF subido, haz un commit de ese contenido en un repositorio y añádelo como un archivo de GitHub, o pega la parte esencial como contenido de texto.

Finalmente, ten en cuenta el uso. Las preguntas formuladas en un espacio "cuentan como solicitudes de Copilot Chat y consumen créditos de IA según el modelo utilizado y la cantidad de tokens procesados". Un espacio optimizado con archivos bien elegidos es más económico de consultar que uno repleto de todo.

Un espacio bien construido cubre un sistema dentro de GitHub. Algunos contextos abarcan más que eso: decisiones que afectan a varios repositorios, convenciones que se aplican a distintos equipos, el razonamiento detrás de elecciones que ningún archivo individual registra y la misma información de fondo que tus compañeros de equipo necesitan en herramientas fuera de GitHub. MemoryLake es el lugar para mantener esa capa de modo que llegue a cada asistente que use tu equipo.

Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de tus Copilot Spaces, tus repositorios ni del almacenamiento de ningún proveedor.

Paso 1: Crea una clave de API

Inicia sesión y genera una clave desde el panel de control. La clave es lo que permite a un asistente leer las entradas que has escrito, independientemente de la herramienta que abra un compañero de equipo.

Paso 2: Sube tus primeros recuerdos

Comienza con el contexto del Paso 2 que sea más amplio que un solo espacio: decisiones entre repositorios, convenciones de equipo y las razones detrás de ellas. Una decisión por entrada, con fecha y propietario.

Paso 3: Conecta tu IA y agentes

Conecta Copilot y los demás asistentes que utiliza tu equipo. De este modo, la misma información de fondo estará disponible junto con el espacio, incluso en herramientas que nunca lo leen.

La primera diferencia es que lo de "siempre actualizado" se vuelve real para las partes que importan. Cuando los documentos clave son archivos de GitHub, el espacio se actualiza solo a medida que cambian el código y la documentación, que es el comportamiento que GitHub promete para esas fuentes.

La segunda es que el IDE y la web muestran el mismo espacio. Una vez que el contexto esencial reside en archivos de GitHub, issues, pull requests, contenido de texto e instrucciones, los desarrolladores obtienen la misma base en el modo agente que obtienen en github.com.

La tercera es que la obsolescencia tiene un responsable. El contenido de texto con fecha y los roles de editor claros convierten el "el espacio está desactualizado" de una queja vaga en una tarea que alguien puede asumir. Es la misma disciplina que evita que Copilot olvide el contexto de tu base de código en primer lugar.

La cuarta es que los Spaces encajan junto con tu otro contexto de Copilot. Los archivos de instrucciones del repositorio deciden cómo se comporta Copilot en el código; los espacios deciden qué sabe sobre un sistema; y configurar la memoria de Copilot en VS Code añade su propia capa. Mantener estos roles diferenciados evita los conflictos descritos en qué archivo de instrucciones de Copilot tiene prioridad.

Añade el contenido del repositorio como archivos de GitHub, no como subidas. Las fuentes basadas en GitHub son las que están documentadas para actualizarse automáticamente.

Adjunta archivos para los documentos que Copilot siempre debe considerar. Los archivos adjuntos se cargan por completo; en los repositorios adjuntos se realizan búsquedas.

Verifica lo que dice main. Los Spaces utilizan el código más reciente en main.

Coloca la información de fondo esencial en contenido de texto, con fecha y propietario. Llega al IDE, y las fechas hacen visible la obsolescencia.

Prueba en el IDE, no solo en github.com. El contexto del repositorio y los archivos subidos no forman parte del uso en el IDE.

Mantén la descripción para los humanos. En su lugar, coloca las pautas para Copilot en las instrucciones.

Haz commit de las decisiones que pertenecen al código. Convertir documentos de proyectos dispersos en memoria de IA comienza por llevarlos a un lugar al que las herramientas puedan acceder de manera confiable, y el mismo instinto ayuda cuando mueves el contenido de CLAUDE.md a Copilot.

Los Copilot Spaces son una forma práctica de dar a Copilot, y a tu equipo, una visión compartida de un sistema. La promesa de GitHub de que los espacios "se mantienen sincronizados a medida que evoluciona tu proyecto" se cumple para las fuentes basadas en GitHub, que se actualizan automáticamente a medida que cambian.

El resto requiere diseño. Las subidas y el texto pegado son instantáneas. Los espacios siguen a main. Los repositorios adjuntos se buscan en lugar de cargarse por completo, y en el IDE, "el contexto del repositorio y los archivos subidos no son compatibles".

Construye a partir de archivos de GitHub siempre que puedas, elige archivo o repositorio deliberadamente, pon fecha y asigna propietarios a las instantáneas, y prueba el espacio en el IDE. Para el contexto que abarca más de un espacio, mantenlo donde cualquier herramienta que use tu equipo pueda acceder a él. Si estás comparando opciones para esa capa, herramientas de memoria de base de código para equipos de ingeniería cubre este campo, y el flujo de trabajo por solicitud de Copilot explica por qué el contexto debe vivir fuera de cualquier solicitud individual.