Copilot Spaces: cómo crear capas de contexto sin meter todo el repositorio en cada prompt
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 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.
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.
Suscribirme gratisChecklist
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.
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.
Puntos a revisar
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.
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.
Checklist
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.
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.
Puntos a revisar
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.
Checklist de capas de contexto
- Excluye primero rutas sensibles o irrelevantes.
- Mantén `.github/copilot-instructions.md` corto 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.
Checklist
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.
Puntos a revisar
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.
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 proyectoGitHub Agent Finder y ARD para CopilotCopilot coding agent en producciónMCP en producción: seguridad y permisosRTK: reducir tokens en agentes de IARecibe 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.
Suscribirme gratis
