Copilot Spaces no va de guardar chats bonitos. Va de crear una capa de contexto curada para una misión concreta. La diferencia entre buen contexto y contexto infinito es lo que separa a un agente útil de un asistente caro y confundido.
Copilot Spaces es una forma de agrupar contexto para Copilot Chat: repositorios, archivos, carpetas, issues, pull requests, notas, texto libre, imágenes y uploads, de manera que las respuestas se anclen en evidencia relevante para una tarea.
TL;DR
La keyword principal es
Copilot Spaces; la intención de búsqueda en español es aprender a usar Spaces junto a instrucciones, MCP, Memory y content exclusion para construir capas de contexto útiles sin sobrecargar al agente.Mi postura: Spaces debe ser la capa de misión, no el vertedero de todo el conocimiento del equipo. Si metes medio monorepo, todos los issues y notas antiguas, el problema deja de ser falta de contexto y pasa a ser exceso de ruido.
El error: pensar que más contexto siempre mejora al agente
Una definición citable: Copilot Spaces es una colección curada de contexto que Copilot puede usar para responder preguntas sobre una tarea, área de producto o sistema concreto, y que puede compartirse con otras personas para alinear conocimiento técnico.
La intuición rápida dice: si el agente falla por falta de contexto, añadamos más. Esa intuición rompe rápido. Más contexto también significa más ambigüedad, más tokens, más material obsoleto, más riesgo de filtrar datos sensibles y más posibilidades de que el modelo preste atención a lo incorrecto.
El objetivo no es que Copilot vea todo. El objetivo es que vea lo suficiente, en la capa correcta, con una frontera clara entre evidencia, reglas, herramientas y memoria.
Recibe una lectura semanal de herramientas IA para devs
Si quieres seguir Copilot Spaces, Agent Finder, MCP, memoria e instrucciones de agentes sin perseguir documentación dispersa, DevAI Semanal te lo resume cada semana en un email de 5 minutos.
La arquitectura mental: cinco capas de contexto
Yo separaría el contexto de Copilot en cinco capas. No porque GitHub lo venda así, sino porque operativamente evita mezclar cosas que cambian a ritmos distintos.
Capa 1: política y exclusión. Lo que nunca debe entrar al modelo: secretos, datos regulados, rutas sensibles, repos que no deberían informar respuestas y archivos excluidos por configuración.
Capa 2: instrucciones estables. Cómo trabaja el repo: convenciones, comandos, estilo, testing, arquitectura, ownership y reglas que aplican casi siempre.
Capa 3: Space de misión. Evidencia concreta para una tarea: archivos, carpetas, issues, PRs, notas, transcripciones, imágenes o documentos necesarios para entender un cambio.
Capa 4: herramientas vivas. Contexto que no conviene congelar en un Space porque cambia: GitHub MCP, toolsets, issues activos, PRs, datos externos y sistemas internos.
Capa 5: memoria. Preferencias y convenciones que Copilot aprende o conserva con el tiempo, y que debes revisar porque una memoria antigua puede convertirse en una regla falsa.
Una arquitectura práctica: lo permanente vive en instrucciones, lo específico de una misión vive en un Space, lo dinámico entra por MCP y lo sensible se excluye antes de empezar.
Dónde encaja Copilot Spaces
Spaces encaja en la tercera capa: contexto de misión. Un Space debería responder a una pregunta concreta: qué necesita saber Copilot para razonar sobre este módulo, esta migración, este bug, este rediseño o esta decisión técnica.
Lo que conviene comprobar
La documentación de GitHub indica que un Space puede incluir repositorios, código, pull requests, issues, texto libre como notas o transcripciones, imágenes y archivos subidos. También puede compartirse con el equipo o hacerse público según el caso.
La parte clave es que Copilot no usa necesariamente todo el contenido del Space en cada respuesta. Lo usa como base recuperable. Por eso añadir fuentes muy relevantes suele funcionar mejor que adjuntar un repo entero por costumbre.
Qué pondría dentro de un Space
Para una feature nueva: el issue de producto, el ADR o spec, los archivos del área afectada, el contrato de API, dos PRs recientes buenos y una nota breve con restricciones no obvias.
Para onboarding de un módulo: README, diagrama de arquitectura, carpeta principal, tests representativos, issues cerrados que explican decisiones, y una nota con vocabulario del dominio.
Para depurar un bug: issue original, logs saneados, pasos de reproducción, archivos sospechosos, test fallido, PR que introdujo el cambio y capturas o imágenes si el bug es visual.
Para una migración: guía oficial, lista de breaking changes, wrappers internos, ejemplos actuales, decisiones de compatibilidad y un checklist de rollout.
Qué no pondría dentro de un Space
No pondría secretos, dumps, datos reales de clientes, tickets con PII, logs sin limpiar ni configuraciones internas que el agente no necesita para razonar.
Tampoco pondría todo el monorepo si la tarea toca tres carpetas. La opción de incluir repositorios completos es útil para exploración, pero no debería ser el patrón por defecto en tareas de precisión.
Y no pondría documentación obsoleta para que
quizá ayude. En un Space, lo viejo compite con lo correcto. Si quieres conservar historia, etiquétala como historia y explica por qué no debe guiar la implementación actual.
Instrucciones estables: el contexto que no debería vivir en Spaces
Las instrucciones de repositorio, como .github/copilot-instructions.md, son mejores para reglas permanentes: cómo ejecutar tests, estilo de código, frameworks, estructura de carpetas, convenciones de commits, restricciones de seguridad y criterios de revisión.
GitHub también documenta soporte variable por superficie para instrucciones de repo, instrucciones por ruta y archivos de agente como AGENTS.md, CLAUDE.md o GEMINI.md. Eso importa porque no todas las experiencias de Copilot cargan las mismas capas igual.
Regla práctica: si una frase debería aplicarse a casi todas las interacciones del repo, no la escondas en un Space. Ponla en instrucciones versionadas. Si solo aplica a una iniciativa concreta, ahí sí tiene sentido el Space.
Path-specific instructions: contexto por zona del repo
En repos grandes, una instrucción global tiende a volverse genérica. Las instrucciones por ruta permiten decir: en api/ usamos contratos OpenAPI; en frontend/ usamos accesibilidad y snapshots visuales; en infra/ no se cambian permisos sin plan de rollback.
Esta capa reduce el tamaño mental del problema. Copilot no necesita una biblia de todo el sistema para tocar un endpoint. Necesita las reglas de esa zona y la evidencia de la tarea.
La combinación buena es: instrucciones globales cortas, instrucciones por ruta concretas y Spaces para misiones que cruzan varias zonas.
MCP: contexto vivo, no documentación congelada
MCP sirve para conectar Copilot con herramientas y sistemas externos. GitHub lo presenta como una forma de extender Copilot con servicios existentes en IDEs, CLI, la app y agentes en GitHub.com.
Esto no compite con Spaces. Lo complementa. Un Space puede contener la explicación de la migración; MCP puede consultar el issue vivo, listar PRs, ver metadata del repo o interactuar con herramientas autorizadas.
La frontera sana: si el dato cambia cada minuto, no lo copies al Space. Conéctalo por una herramienta con permisos mínimos. Si el dato es evidencia estable para la tarea, inclúyelo en el Space.
Copilot Memory: útil, pero con caducidad mental
Copilot Memory permite conservar convenciones, preferencias y detalles aprendidos de interacciones. Bien usado, evita repetir cada vez que prefieres cierto estilo de test o patrón de arquitectura.
Lo que conviene comprobar
El riesgo es convertir memoria en dogma. Una preferencia personal puede no aplicar al repo. Una convención puede cambiar. Una decisión temporal puede quedarse pegada a respuestas futuras.
Yo revisaría Memory como revisas dependencias: de vez en cuando, con intención. Lo que aplica al repo debería estar versionado en instrucciones. Lo personal puede vivir en memoria, pero no debería contradecir al proyecto.
Content exclusion: la primera capa, no el último parche
Content exclusion permite configurar archivos y rutas que Copilot debe ignorar. Según GitHub, el contenido excluido no informa sugerencias inline, respuestas de Chat ni revisiones de código afectadas.
No lo trates como un ajuste de privacidad al final. Es la primera capa de arquitectura de contexto. Antes de construir Spaces, instrucciones o MCP, decide qué no debe entrar nunca.
Ejemplos:
.env, fixtures con datos reales, exports de clientes, claves, dumps, modelos propietarios, contratos bajo NDA o cualquier carpeta donde una respuesta útil no compensa el riesgo.Cómo diseñar un Space bueno
Nómbralo por misión, no por herramienta:
checkout-refactor-q3,onboarding-billing-service,incident-postmortem-payments,migration-react-compiler.Añade una nota inicial con tres cosas: objetivo, límites y definición de terminado. Sin esa nota, el Space puede tener documentos buenos pero carecer de intención.
Incluye evidencia mínima suficiente: cinco archivos buenos valen más que quinientos archivos indiferentes. Añade el issue o PR que motivó la tarea, no toda la historia del proyecto.
Cierra el Space cuando la misión termine o archívalo con una nota de resultado. Un Space abandonado se convierte en contexto fósil.
Checklist de capas de contexto
- Excluye primero rutas sensibles o irrelevantes.
- Mantén
.github/copilot-instructions.mdcorto y estable. - Usa instrucciones por ruta para reglas específicas de carpetas.
- Crea Spaces por misión, feature, bug, migración o onboarding.
- Añade al Space archivos concretos antes que repos completos.
- Incluye issues y PRs solo si explican decisiones vigentes.
- Usa MCP para información viva o acciones, no para reemplazar documentación.
- Revisa Copilot Memory para evitar preferencias obsoletas.
- Mide si el Space reduce preguntas repetidas y cambios fuera de alcance.
- Elimina contexto que no haya cambiado ninguna respuesta.
Errores que evitaría
El primero es crear un Space por equipo y meterlo todo. Eso se convierte en wiki desordenada, no en contexto operativo.
El segundo es duplicar reglas en todos los sitios: instrucciones, Space, Memory y prompt. Cuando una regla cambia, no sabrás cuál manda.
El tercero es tratar issues antiguos como verdad. Un issue cerrado puede explicar una decisión, pero también puede estar obsoleto. Añade notas que distingan evidencia histórica de regla vigente.
El cuarto es usar MCP con permisos amplios para compensar Spaces pobres. Las herramientas vivas necesitan menos permisos, no más confianza.
Implementación recomendada para un equipo
- Semana 1: crea instrucciones globales mínimas y content exclusion para rutas sensibles.
- Semana 2: define tres plantillas de Space: feature, bug y migración. Cada plantilla debe pedir objetivo, límites, archivos clave, issues/PRs y definición de terminado.
- Semana 3: añade instrucciones por ruta para dos zonas críticas del repo y conecta MCP solo en modo lectura si aporta información viva.
- Semana 4: revisa sesiones reales. Qué contexto sobró, qué faltó, qué respuestas fueron mejores y qué archivos se repitieron en varios Spaces.
- Después: convierte conocimiento repetido en instrucciones versionadas. Deja en Spaces solo lo que pertenece a una misión concreta.
Conclusión
Copilot Spaces es más interesante como disciplina de contexto que como feature de organización. Obliga a decidir qué evidencia necesita una tarea y qué debe quedar fuera.
Lo que conviene comprobar
La arquitectura ganadora no es un Space enorme. Es una pila: exclusión para lo sensible, instrucciones para lo estable, Spaces para misiones, MCP para datos vivos y Memory para preferencias revisables. Si separas esas capas, Copilot responde mejor y tu equipo puede auditar por qué el agente sabía lo que sabía.
Preguntas frecuentes
¿Qué es Copilot Spaces?
Copilot Spaces es una forma de organizar contexto para GitHub Copilot usando repositorios, archivos, issues, PRs, notas, imágenes y uploads relevantes para una tarea o área.
¿Copilot usa todo lo que pongo en un Space?
No necesariamente. GitHub indica que Copilot usa contexto relevante del Space para responder, por eso conviene añadir fuentes muy seleccionadas.
¿En qué se diferencia un Space de .github/copilot-instructions.md?
Las instrucciones son reglas persistentes del repo; un Space es contexto curado para una misión, feature, bug o área concreta.
¿Cuándo uso MCP en vez de un Space?
Usa MCP cuando el dato cambia o requiere interacción con sistemas vivos. Usa un Space para evidencia estable que quieres que Copilot tenga presente.
¿Copilot Memory reemplaza a las instrucciones?
No. Memory sirve para preferencias y convenciones aprendidas, pero las reglas de proyecto deberían vivir en archivos versionados.
¿Qué debería excluir antes de crear Spaces?
Secretos, datos reales de clientes, dumps, fixtures sensibles, archivos bajo NDA y cualquier ruta que no deba informar respuestas ni revisiones.
Límite sano
Paraleliza investigación y tareas acotadas. No paralelices criterio técnico ni integración final.
Fuentes y referencias
- GitHub Docs: About GitHub Copilot Spaces
- GitHub Docs: Using GitHub Copilot Spaces
- GitHub Docs: Speeding up development work with GitHub Copilot Spaces
- GitHub Docs: Provide context to GitHub Copilot
- GitHub Docs: Adding repository custom instructions
- GitHub Docs: Custom instructions support
- GitHub Docs: About Model Context Protocol
- GitHub Docs: Content exclusion for Copilot
- GitHub Docs: Managing Copilot Memory
También te puede interesar
- AGENTS.md, CLAUDE.md y memoria de proyecto
- GitHub Agent Finder y ARD para Copilot
- Copilot coding agent en producción
- MCP en producción: seguridad y permisos
- RTK: reducir tokens en agentes de IA
Recibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
