GitHub Copilot en Slack y Microsoft Teams puede convertir una conversación en contexto para investigar un repositorio, planificar cambios, crear issues y abrir pull requests. La actualización anunciada el 25 de septiembre de 2026 amplió los tipos de contexto que las integraciones pueden utilizar y reforzó la trazabilidad entre la conversación y el trabajo creado en GitHub. Para usar este flujo sin perder el origen, el punto principal es entender que un hilo compartido puede convertirse en el contexto de decisión del agente y que la integración mantiene enlaces entre el resultado y la conversación que lo originó.
Esto no significa que cualquier mensaje conceda autoridad para modificar un repositorio. El contexto de la conversación, la identidad utilizada por la integración y la autorización para ejecutar acciones son capas diferentes. En una conversación compartida, los participantes pueden aportar información, pero solo los usuarios con acceso de escritura al repositorio pueden activar cambios. En mensajes directos, el agente utiliza los permisos de la cuenta de GitHub vinculada.
Qué cambió en las integraciones el 25 de septiembre de 2026
Según el changelog oficial de GitHub, Copilot ahora puede aprovechar más material que ya existe en las conversaciones. En Slack, la actualización añadió archivos compatibles, adjuntos y enlaces de mensajes como contexto. En Teams, el agente puede trabajar con imágenes inline, contexto de mensajes reenviados e historial de canales e hilos.
El mismo anuncio también reforzó la conexión entre conversación y ejecución. Antes de crear un nuevo issue, Copilot puede comprobar si ya existen issues similares. Cuando crea trabajo en GitHub, la integración ofrece enlaces directos al resultado y mantiene un enlace de vuelta a la conversación de origen. El objetivo es permitir que alguien que llegue después a un issue o pull request pueda recuperar la discusión que llevó a esa acción en lugar de ver solo el artefacto final sin contexto.
También hay controles de flujo. Es posible cambiar el modelo para el siguiente mensaje y mantener esa elección durante la conversación. En Slack, también se pueden definir repositorios y responsables predeterminados. El changelog registra además mejoras para tareas largas, reconexión tras periodos de inactividad, respuestas interrumpidas, cambio seguro de repositorio y una retención más fiable del historial de hilos de canal en Teams.
Cómo usar el contexto de la conversación sin perder el origen
- Elige la conversación correcta. Si la decisión está en un hilo específico, invoca GitHub en ese hilo. La documentación de Slack y Teams indica que el agente puede usar la conversación completa como contexto. Por lo tanto, mezclar temas sin relación en un mismo hilo también mezcla el contexto.
- Menciona @GitHub con una tarea explícita. Indica qué debe investigarse, planificarse o modificarse y, cuando sea posible, identifica el repositorio y la rama. Una solicitud precisa reduce la posibilidad de que el agente infiera un destino incorrecto a partir de una conversación extensa.
- Confirma el repositorio de trabajo. Slack y Teams pueden utilizar un repositorio predeterminado del canal cuando no se indica ninguno. Si la tarea pertenece a otro proyecto, nombra el repositorio en la solicitud antes de iniciar el trabajo.
- Revisa el alcance del contexto. La documentación advierte que el hilo completo puede ser capturado y almacenado en los artefactos generados por el agente. Si una parte de la conversación no debe incluirse, inicia un nuevo hilo o usa un mensaje directo para reducir el contexto.
- Sigue los enlaces en ambas direcciones. El resultado debe apuntar a los artefactos creados en GitHub, mientras que la integración mantiene la conexión con la conversación que inició la tarea. Esa relación es el principal mecanismo de trazabilidad del flujo.
De dónde viene el contexto en Slack y Teams
| Aspecto | Slack | Microsoft Teams |
|---|---|---|
| Historial de la conversación | El hilo puede utilizarse como contexto completo para la tarea. | El historial del hilo y del canal puede utilizarse como contexto. |
| Contexto adicional destacado en la actualización | Archivos compatibles, adjuntos y enlaces de mensajes. | Imágenes inline, mensajes reenviados e historial de canal e hilo. |
| Repositorio | Un canal puede tener un repositorio predeterminado. Slack también recibió controles para repositorios y responsables predeterminados. | Un canal puede tener un repositorio predeterminado configurado mediante la integración. |
| Continuidad de la tarea | Una tarea puede tener un canal Slack Code dedicado con repositorio, rama, enlaces y estado de la sesión. | La sesión continúa en la conversación, con datos como repositorio, enlace de issue o pull request, modelo y estado. |
| Trazabilidad | El trabajo creado recibe enlaces y permanece conectado con la conversación de origen. | El trabajo creado recibe enlaces y permanece conectado con la conversación de origen. |
La diferencia práctica no está solo en la interfaz. En Slack, la documentación describe un canal dedicado llamado Slack Code para una tarea del agente, que concentra la continuidad de la sesión. En Teams, la iteración ocurre en el propio hilo y el agente incorpora mensajes posteriores para refinar el trabajo. En ambos casos, la conversación compartida es una fuente de contexto, no un sustituto de la revisión del artefacto creado.
Qué significa preservar el origen en la práctica
Preservar el origen tiene dos dimensiones. La primera es técnica: GitHub indica que los artefactos creados pueden permanecer vinculados a la conversación que proporcionó el contexto. La segunda es operativa: el equipo debe utilizar hilos, repositorios y tareas de forma coherente para que ese enlace siga siendo útil.
Si un mismo hilo contiene decisiones sobre tres servicios diferentes, seguirá existiendo un enlace de retorno a esa conversación, pero el origen será menos claro para quien revise el resultado. Por eso, una práctica útil es mantener un hilo por problema o decisión relevante, especificar el repositorio y la rama cuando sea necesario y evitar reutilizar una sesión antigua para un trabajo sin relación con el original.
También conviene revisar los enlaces del artefacto cuando el agente termine. La trazabilidad ayuda a explicar por qué existe un issue o pull request, pero no sustituye la verificación humana del contenido, especialmente porque las páginas oficiales recuerdan que Copilot utiliza IA y puede cometer errores.
Permisos: el contexto de la conversación no es autorización de escritura
Las páginas oficiales de Slack y Teams separan claramente colaboración y autorización. En un contexto compartido, Copilot crea artefactos usando la identidad de la aplicación. En un mensaje directo, utiliza los permisos de la cuenta personal de GitHub vinculada para ejecutar acciones.
- Acceso de escritura: solo los usuarios con permiso de escritura en el repositorio pueden activar al agente para realizar cambios.
- Aporte de contexto: otros participantes de la conversación pueden proporcionar información que el agente tendrá en cuenta, aunque no puedan iniciar una modificación.
- Invitados y colaboradores externos: la documentación indica que estos perfiles no pueden iniciar ni dirigir una sesión de Copilot en estas integraciones.
- Reglas del repositorio: los pull requests creados en un contexto compartido usan la identidad de la aplicación. Si el repositorio ya exige aprobación, las reglas pueden requerir una aprobación adicional porque el autor no es una persona.
También existen permisos de la propia integración. Las páginas de permisos de GitHub en Slack y permisos de GitHub en Teams enumeran los accesos de lectura necesarios para mostrar código y vistas previas, además de permisos de escritura utilizados para crear issues, pull requests e iniciar sesiones del agente. En entornos corporativos, los administradores también pueden restringir a qué repositorios puede acceder la aplicación.
Cómo limitar un contexto excesivo o ambiguo
La recomendación más importante es tratar el hilo como parte de la entrada del agente. Antes de mencionar @GitHub, comprueba si la conversación contiene solo información adecuada para la tarea. La guía general de integraciones de Copilot indica que el agente captura el hilo o elemento de trabajo para comprender el contexto y que ese contexto se almacena en los artefactos que crea.
- Inicia un nuevo hilo cuando el tema haya cambiado o cuando la conversación haya acumulado hipótesis antiguas.
- Usa un mensaje directo si quieres reducir el contexto en lugar de aprovechar una discusión compartida completa.
- Indica el repositorio y la rama cuando exista riesgo de ambigüedad.
- Incluye criterios objetivos, como comportamiento esperado, archivo afectado o condición de aceptación, en vez de depender solo de referencias vagas a mensajes anteriores.
- Después de cambiar de repositorio, verifica el repositorio mostrado por la sesión antes de continuar.
- Para una tarea nueva, evita reutilizar una sesión antigua solo porque ya está abierta.
Disponibilidad y límites que siguen importando
Las integraciones continúan marcadas como preview público en las páginas operativas consultadas. El changelog del 25 de septiembre describe el paquete de mejoras como disponible en preview público para organizaciones con GitHub Copilot Business y Enterprise y señala que algunas capacidades se despliegan gradualmente. Sin embargo, las páginas actuales de Slack y Teams indican que las integraciones están disponibles con planes de Copilot de pago. Como las formulaciones no son idénticas, la disponibilidad real de una capacidad específica debe comprobarse en el propio workspace y en las políticas de la organización.
El uso del agente también depende de sandboxes en la nube y, en organizaciones o empresas, de políticas administrativas que pueden necesitar habilitación. Tener instalada la integración no garantiza acceso a todos los repositorios. El usuario sigue necesitando la autorización adecuada y la aplicación debe tener acceso al repositorio seleccionado.
Por último, más contexto no significa contexto ilimitado ni respuestas infalibles. Los archivos o imágenes deben ajustarse a los formatos y rutas admitidos por la integración, las capacidades pueden desplegarse gradualmente y las tareas interrumpidas o sesiones antiguas siguen requiriendo atención. La actualización mejora la recuperación y el estado de esas situaciones, pero el equipo sigue siendo responsable de comprobar el repositorio, los artefactos generados y el contenido final.
Checklist rápido para usar la función con trazabilidad
- Confirma que la integración de GitHub está instalada y que tu cuenta está vinculada.
- Verifica que el agente y los sandboxes en la nube estén habilitados para tu organización.
- Elige un hilo que represente un único problema o decisión.
- Antes de enviar, comprueba que el hilo no contiene contexto que no deba almacenarse en el artefacto.
- Menciona @GitHub e indica claramente la tarea, el repositorio y la rama cuando sea necesario.
- Confirma que tienes acceso de escritura al repositorio antes de activar cambios.
- Usa archivos, adjuntos, enlaces de mensajes o imágenes solo cuando sean relevantes para la tarea.
- Después de la ejecución, abre los enlaces del issue o pull request y verifica la conexión con la conversación de origen.
- Revisa el resultado de forma humana antes de fusionar o tratar la salida como una decisión concluida.
Fuentes y referencias
- GitHub Changelog: Updates to GitHub Copilot for Slack and Microsoft Teams
- GitHub Docs: About Copilot integrations
- GitHub Docs: Integrating Copilot cloud agent with Slack
- GitHub Docs: Integrating Copilot cloud agent with Teams
- GitHub Docs: Permissions for GitHub in Slack
- GitHub Docs: Permissions for GitHub in Teams
