Cómo asignar una issue al Copilot coding agent
El recorrido completo de 2026: entrégale una issue de GitHub al agente de código de Copilot —documentado ahora como cloud agent—, mira cómo planifica, abre un draft PR y ejecuta tests dentro de GitHub Actions, y después revisa, itera y fusiona. Cada paso está ajustado al minuto exacto de los vídeos de origen.
TL;DR — asignar issues a Copilot en 2026
- Asignar es un clic: abre la issue, pulsa Assignees, elige Copilot. El agente reacciona con un emoji de ojos, arranca un entorno efímero de GitHub Actions y abre un draft PR que puedes seguir desde la línea temporal de la issue.
- La documentación de GitHub ya lo llama Copilot cloud agent — el mismo producto que la interfaz y los posts del blog siguen llamando coding agent. Ambos nombres funcionan en búsquedas, tickets de soporte y esta guía.
- Necesitas un plan de Copilot de pago y acceso de escritura al repo. Las cuentas del plan gratuito no ven Copilot en la lista de assignees; en Business y Enterprise un administrador debe activar antes la política.
- La revisión sigue siendo humana: Copilot te pide revisión al terminar, los comentarios @copilot devuelven cambios, y el PR solo se fusiona tras la aprobación de una persona. La ejecución de la demo de esta guía terminó en 8 min 14 s.
Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository
Canal: :The Code Wolf13:00
How to Get the Most Out of the Copilot Coding Agent
Canal: :GitHub1:56
How the GitHub Copilot coding agent works | GitHub Checkout
Canal: :GitHub6:58
Starting GitHub Copilot sessions
Docs: :docs.github.com
About the Copilot cloud agent
Docs: :docs.github.com
Los fotogramas de esta guía vienen de las dos grabaciones de pantalla limpias acreditadas arriba; cada imagen se comprobó a tamaño completo. La entrevista de GitHub Checkout se usa solo como fuente de datos — sus segmentos de pantalla llevan la cámara del presentador superpuesta, así que no se tomó ningún fotograma de ella.
Las capturas de pantalla se usan con fines de identificación y comentario. «Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository» © The Code Wolf; «How to Get the Most Out of the Copilot Coding Agent» y «How the GitHub Copilot coding agent works» © GitHub. Todos los nombres de producto son marcas de sus respectivos propietarios.
Asignar, seguir y fusionar: el recorrido en 13 pasos
Antes de asignar la issue
- 1
Abre la pestaña Issues del repo y elige una tarea bien acotada
Las issues suelen llegar de tu product owner, de tu equipo o de la comunidad. En el repositorio de la demo hay tres abiertas — un conector de Snowflake, columnas ordenables y favoritos con nombre. Cada una es una feature del tamaño de un PR, justo el tamaño que mejor maneja el coding agent. Puedes asignar varias issues a la vez; cada una recibe su propia sesión y draft PR.
La pestaña Issues del repo de demo con tres peticiones de la comunidad abiertas.Ver en 9:31 - 2
Escribe el problema y los criterios de aceptación en la issue
Copilot solo ve el título de la issue, la descripción y los comentarios que existan cuando la asignas. Una buena issue plantea el problema, por qué importa y los criterios de aceptación — el ejemplo de GitHub lista criterios en viñetas que hacen verificable el éxito. Lo que olvides puede añadirse después, pero solo como comentario en el pull request que abra Copilot, porque la issue no la vuelve a leer.
Una issue bien acotada: descripción, motivación y criterios de aceptación verificables.Ver en 0:17 - 3
Comprueba que el agente está activado en tu cuenta
Solo puedes asignar issues a Copilot con un plan de pago. Revisa github.com/settings/copilot/features — la página de ajustes personales lista Coding agent (Preview) bajo Copilot en la barra lateral, junto a los interruptores Enabled de Copilot en la CLI, de Chat en GitHub Mobile y de las demás funciones de vista previa del editor. En Copilot Business o Enterprise un administrador debe activar antes la política de la organización para que aparezca la opción.
La página de funciones de Copilot donde Coding agent (Preview) muestra su estado activado.Ver en 4:00
Asigna la issue a Copilot
- 4
Abre el menú Assignees y elige Copilot
Abre la issue y pulsa Assignees en la barra lateral derecha. El desplegable lista personas y additional options — incluido Copilot, subtitulado «Your AI pair programmer». Selecciónalo igual que elegirías a un compañero; la documentación avisa de que asignar issues a Copilot está en public preview y puede cambiar. ¿Prefieres el teclado? gh agent-task create (GitHub CLI 2.80.0 o posterior, public preview) arranca el mismo tipo de sesión desde tu terminal.
El desplegable Assignees con Copilot — Your AI pair programmer — resaltado.Ver en 4:16 - 5
Confirma la asignación y añade indicaciones opcionales
Copilot se coloca ahora junto a los assignees humanos. El diálogo de asignación ofrece además un campo de prompt opcional para contexto, restricciones o requisitos concretos, desplegables para cambiar el repositorio de destino y la rama de partida — necesitas acceso de escritura al repo elegido y el cloud agent debe estar activado allí — más selectores de custom agent, modelo de IA y razonamiento. Todo es opcional: asignado sin extras, Copilot parte solo del texto de la issue.
Material oficial de GitHub con la selección de Copilot en el desplegable Assignees.Ver en 0:04 - 6
Mira la línea temporal confirmar que Copilot lo ha recogido
En segundos la issue reacciona: Copilot añade una reacción de ojos y un evento «Copilot has started work» aterriza en la línea temporal. En esta grabación se ven los eventos de asignación, los comentarios del propio Copilot y —un minuto después— «Copilot linked a pull request that will close this issue» apuntando al nuevo borrador WIP. También recibirás correos conforme avanza la sesión.
Línea temporal de la issue: eventos de asignación, comentarios de Copilot y el pull request WIP enlazado.Ver en 5:22
Sigue la ejecución en segundo plano
- 7
Sigue la ejecución en GitHub Actions
El cloud agent trabaja en un entorno efímero impulsado por GitHub Actions. Abre la pestaña Actions y encontrarás una ejecución con el nombre de la issue —aquí «Fixing issue #5»— con un job copilot cuyos pasos se llaman Prepare Copilot, Start MCP Servers, Processing Request, Clean Up y Save Data. Puede que un revisor tenga que pulsar «Approve and run workflows» antes de que los push de Copilot ejecuten tu CI.
Los pasos en vivo del job copilot dentro de la ejecución de GitHub Actions de la issue.Ver en 5:00 - 8
Abre el draft PR que Copilot levanta
Copilot no se queda callado hasta el final — abre un draft pull request de inmediato y lo va actualizando. La línea temporal de la issue enlaza directo a él («a pull request that will close this issue»), y el cuerpo del PR empieza siendo una copia de la issue para luego llenarse con el plan del agente y el progreso marcado a medida que trabaja. Vigílalo como la rama de un compañero.
El evento de pull request enlazada de la línea temporal apuntando al nuevo draft PR.Ver en 5:31 - 9
Lee las notas del PR de Copilot
Al terminar la sesión, el draft pull request se lee como si lo hubiera escrito un buen compañero: «Copilot wants to merge 3 commits into main from copilot/fix-5-4», una sección What's Added que desglosa la implementación núcleo, la integración de UI y la integración del sistema, más una sección Connection String Format. La barra lateral muestra «Copilot is done — completed after 8m 14s». Esta ejecución tardó unos nueve minutos de punta a punta.
La descripción escrita por el propio draft PR con el tiempo de ejecución en la barra lateral.Ver en 5:38
Revisa, itera, fusiona
- 10
Inspecciona el diff de Files changed
La pestaña Files changed muestra cada commit del agente: aquí seis archivos, incluido un nuevo SnowflakeDatabaseService.cs con 119 líneas añadidas —encabezado por un comentario que indica que fue generado por IA—, el paquete NuGet añadido al csproj y el servicio registrado para inyección de dependencias igual que sus hermanos Oracle, PostgreSQL y SQL Server. Léelo exactamente como el PR de un compañero.
Files changed en el pull request 14: seis archivos y el nuevo servicio generado.Ver en 12:15 - 11
Revisa cuando Copilot te lo pida
Las sesiones terminadas te avisan — un banner muestra «Copilot requested your review on this pull request» con un botón Add your review. Comenta cualquier línea o deja una revisión normal; Copilot recoge los comentarios de revisión y las menciones @copilot de quien tenga acceso de escritura y sube nuevos commits al mismo PR. Las iteraciones van más rápido porque recuerda el contexto de sesiones anteriores en ese pull request.
El banner de revisión solicitada sobre el resumen de cambios del propio Copilot.Ver en 9:38 - 12
Fusiona como cualquier otro pull request
Cuando el diff convence, fusiona con normalidad. La caja de merge hasta te recuerda qué hará cerrar el PR: «Successfully merging this pull request may close these issues» — enlazando la petición de Snowflake de la que partió el agente. La aprobación humana es la puerta; el agente nunca fusiona solo, y las ejecuciones de CI pueden requerir el clic de «Approve and run workflows» antes de correr sobre los commits de Copilot.
La caja de merge enlazando el pull request con la issue que lo originó.Ver en 12:45 - 13
Pilotiza las ejecuciones futuras con copilot-instructions.md
Para reglas permanentes, añade un archivo .github/copilot-instructions.md — convenciones, pasos de build/test/lint, estructura del repo. El ejemplo de GitHub fija Code Standards y una checklist Required Before Each Commit que empieza con npm run lint; la demo de Code Wolf pide comentarios minuciosos atribuidos a la IA, y el diff generado a continuación los sigue. Los servidores MCP para herramientas fuera de GitHub — Notion, Linear, bases de datos — se configuran desde la página de ajustes de Copilot del repositorio.
Un archivo copilot-instructions.md con estándares de código que el agente respeta.Ver en 0:47
Requisitos previos: planes, permisos y el interruptor de activación
Tres cosas condicionan la opción Assignees → Copilot. Primero, el plan: según la documentación de GitHub, «el cloud agent de Copilot está disponible en todos los planes de pago» — Pro, Pro+, Business y Enterprise. Las cuentas gratuitas no ven Copilot en la lista de assignees, que es el motivo más habitual para creer que la función falta.
Segundo, la activación. Las cuentas personales pueden revisar la página de funciones de sus ajustes de Copilot (github.com/settings/copilot/features), donde aparece Coding agent (Preview) bajo Copilot en la barra lateral. En Business y Enterprise «un administrador debe activar la política correspondiente» antes de que nadie de la org tenga la opción — si falta en un repo de la organización, es conversación de admin, no un bug.
- 1Un plan de Copilot de pago (Pro, Pro+, Business o Enterprise) — las cuentas gratuitas no tienen opción de asignar a Copilot
- 2Acceso de escritura al repositorio de destino — solo puedes elegir repos donde puedas escribir y donde el cloud agent esté activado
- 3El agente activado: github.com/settings/copilot/features para cuentas personales, una política a nivel de org para Business y Enterprise
- 4GitHub Actions disponible en el repo — el agente corre en un entorno efímero impulsado por Actions, y los Enterprise Managed Users no pueden usarlo en repos personales
Tercero, conoce el runtime: las asignaciones están en public preview, cada sesión se ejecuta en un entorno efímero de GitHub Actions con un tope duro de 59 minutos y el acceso a internet desde la sandbox está cortado por defecto. Las sesiones atascadas agotan su tiempo pasado el reloj — la solución es desasignar y reasignar la issue.
Registros de sesión: cómo vigilar a un agente en segundo plano
Cada sesión deja rastro de registro en tres sitios. La línea temporal de la issue anota la asignación, los comentarios de Copilot y el draft PR enlazado. La pestaña Actions muestra los pasos internos del job copilot — preparar el entorno, arrancar los servidores MCP, procesar la petición, limpiar. Y el propio PR se convierte en la página de estado del agente: el cuerpo empieza como copia de la issue y se llena con un plan que se va marcando conforme aterriza el trabajo.
No hace falta estar sondeando. Copilot te escribe cuando el draft PR está arriba y otra vez cuando pide tu revisión, y la reacción de ojos junto al evento «Copilot has started work» confirman en segundos que la sesión arrancó de verdad. La vista de registros de sesión de la documentación va más lejos: puedes seguir el trabajo en vivo e incluso abrir el pull request con un clic desde los logs.
En la demo, una feature moderada — un conector completo de Snowflake repartido en seis archivos — se completó tras 8 min 14 s de tiempo de agente, con el enlace del PR apareciendo en la issue unos nueve minutos después de la asignación. Las ediciones simples suelen volver en un par de minutos; lo que siga corriendo cerca de la hora, tómalo como atascado y reasigna.
Iteración y barandillas: comentarios, instrucciones y MCP
El bucle de asignar y revisar parte de que el primer borrador de Copilot no será perfecto. Cinco palancas moldean el resultado sin que abras jamás un IDE:
- 1Comentarios @copilot — menciona a @copilot en un comentario del PR (se requiere acceso de escritura, solo PR abiertos) y arranca una sesión de seguimiento sobre el mismo PR; los comentarios de revisión individuales pueden delegarse con Fix with Copilot o agruparse
- 2copilot-instructions.md — un archivo .github/copilot-instructions.md lleva tus convenciones, comandos de build/test/lint y reglas de commit a cada sesión; el ejemplo de GitHub incluye una checklist Required Before Each Commit
- 3Servidores MCP — configurados desde los ajustes de Copilot del repo, entregan al agente herramientas más allá de GitHub; la demo Checkout de GitHub lo muestra leyendo una especificación de producto en Notion vía MCP
- 4El prompt opcional al asignar — contexto, restricciones y requisitos concretos que viajan con la issue
- 5Selectores de custom agent, modelo y razonamiento — elige otra configuración por sesión desde el diálogo de asignación o cambia el valor por defecto en ajustes
Las barandillas quedan de tu lado: los cambios se limitan a un repositorio por sesión, el agente no puede aprobar ni fusionar su propio trabajo, y los workflows que dispara esperan «Approve and run workflows» salvo que los metas en tu lista de permitidos. La revisión del PR que haces es la red de seguridad — el botón de merge jamás es del agente.