Tus issues ya viven en GitHub. Y también el código, la revisión de pull requests y las reglas de ramas que tu equipo tardó un trimestre entero en consensuar. Nadie quiere un segundo tablero que mantener sincronizado con el primero. Lo que falta es una forma de entregarle uno de esos issues a un agente de programación y recibir a cambio un pull request revisable, sin salir del repositorio del que salió.
Eso es precisamente lo que consigues al conectar GitHub con Sharkly. Sharkly es una plataforma todo en uno para dirigir y gestionar Agents: convierte un issue de GitHub en una Task asignable, la enruta a un agente de programación (Claude Code, Codex, Gemini o el Runtime que use tu equipo), ejecuta el trabajo en un Computer dentro de un worktree aislado y devuelve el resultado como un pull request que revisas de la forma habitual. Aquí hay dos cosas que importan por encima del resto: quién puede realmente tocar el repositorio y dónde sigue siendo imprescindible que una persona dé el visto bueno.
El ciclo, en una frase
Conecta GitHub, vincula un repositorio a un Space y un issue nuevo se convierte en una Task. Asígnala a un Agent y el mismo contrato se aplica en todo Sharkly: el Agent investiga, ejecuta, prueba e informa; una persona revisa el diff y decide qué se publica.
Dos conexiones, y por qué no son lo mismo
La integración con GitHub tiene dos capas, y confundirlas es la vía más rápida para no aclararse sobre quién puede ver qué.
La primera capa es la conexión de la organización. Un Owner o Admin de la organización abre Integrations, busca GitHub e instala la GitHub App sobre los repositorios que debe ver. Esa conexión es la que hace posibles el vínculo de pull requests y los comentarios de linkback. Los miembros también pueden conectar una cuenta personal de GitHub, pero eso solo cambia la identidad que aparece en los comentarios sincronizados, no lo que ya hace la conexión de la organización.
La segunda capa es vincular uno de esos repositorios a un Space. Si lo haces, los issues nuevos de GitHub empiezan a aparecer como Tasks; los issues que ya existían no se importan. Un repositorio puede alimentar un Space en un solo sentido (los cambios de issues entran, nunca salen) o en dos sentidos (issues y Tasks se mantienen sincronizados en ambas direcciones), y un Space solo admite un repositorio bidireccional a la vez, así que elige con cuidado.
Aquí está el límite con el que tropieza mucha gente: nada de esto es lo que otorga a un Agent permiso para clonar tu código. La integración con GitHub cubre los vínculos de pull requests, la sincronización de issues y los comentarios de linkback. No le concede a ningún Agent acceso de lectura o escritura a un repositorio.
Concede al Agent el acceso al código por separado
El acceso al código es una configuración aparte, que se define en el Agent o en el Space, no en la conexión de GitHub. Un Agent sin repositorios propios recurre a lo que tenga configurado el Space de la Task. Restringe esa lista en el propio Agent cuando solo deba tocar uno de los varios códigos a los que hace referencia un Space.
En cualquier caso, la ejecución sigue necesitando un acceso Git funcional en el propio Computer: una clave SSH, un token HTTPS o credenciales de host ya configuradas allí. La conexión de la organización no las proporciona ni las sustituye. Si una ejecución no puede clonar, es un problema del Computer, no un ajuste de la GitHub App.
Asigna el issue a un Agent
Una vez vinculado un repositorio, cada issue nuevo de GitHub llega como una Task (Issue, Bug, Feature y Ticket son tipos de tarea válidos, según lo que use tu Space). Asignarlo a un Agent funciona igual que asignarlo a un compañero de equipo: abre el control Assignee y elige al Agent en su lugar.
Un Agent es una configuración de trabajo guardada, no un prompt puntual: sus instrucciones, su Runtime, sus repositorios y sus ajustes de ejecución dan forma al trabajo, igual que la descripción de un puesto define lo que hace una persona recién incorporada. Si la Task cae en Backlog, todavía no se ejecuta nada; eso es una sala de espera. Muévela a un estado de trabajo y Sharkly lanzará la ejecución en cuanto haya un Computer y un Runtime listos.
Cuando dos Agents tocan el mismo repositorio
Esta es la parte que más preocupa a los equipos. El modo predeterminado es Temporary: cada Task recibe un directorio aislado y las ejecuciones respaldadas por un repositorio preparan un worktree nuevo. Dos Agents sobre dos issues distintos del mismo repositorio obtienen cada uno su propio checkout, no uno compartido, así que no pueden sobrescribir los archivos del otro ni pelearse por una rama, ni siquiera en el mismo Computer. Es la misma disciplina que hay detrás de usar git worktrees con agentes de programación con IA a mano, pero automatizada.
La concurrencia tiene su propio techo. Las ejecuciones Temporary usan por defecto aproximadamente la mitad del límite total del Computer; si lo subes a mano, el producto te avisa en cuanto el valor supera la capacidad de directorios disponible, que es donde empiezan de verdad las colisiones. También existe el modo Specified, en el que un Agent reutiliza un directorio fijo en lugar de un worktree nuevo, pero atiende una ejecución a la vez, lo que encaja peor con un repositorio al que varios Agents acceden al mismo tiempo.
Lo que vuelve: el pull request
Cuando el Agent abre un pull request, lo vinculas a la Task escribiendo el ID de la Task en el nombre de la rama, el título o el cuerpo. Con uno de los tres basta; un ID a secas como SH-312 funciona igual que Fixes SH-312, ya que no hay ningún tratamiento especial para palabras como fixes, closes o skip. En un repositorio público, solo se vincula a un autor de confianza —el propietario, un miembro o un colaborador—, así que el pull request de un desconocido no puede colarse en tu Task haciéndose pasar por otro.
Los pull requests vinculados también pueden recibir un comentario de linkback que apunta de vuelta a la Task. Está activado por defecto en los repositorios privados y desactivado por defecto en los públicos; es un interruptor que vive en los ajustes de GitHub, independiente de si el propio Space es público o privado.
La puerta de revisión: dónde reside el criterio
Fusionar un pull request no cambia el estado de la Task, y nunca ocurre por sí solo. Es algo deliberado. El estado de la Task y el estado de trabajo de un Agent se siguen por separado, así que una Task Started también puede mostrar Working, Waiting for human reply, Waiting for human review o Error, y esas señales aparecen en Inbox para quien sea responsable. Cerrar o reabrir el issue subyacente de GitHub sí puede mover el estado de una Task bidireccional; fusionar el pull request, no.
Los Agents investigan, ejecutan, prueban e informan. Las personas leen el diff comparándolo con el issue original, piden cambios o lo aceptan, y deciden por sí mismas la fusión y el despliegue. Esa división se mantiene de principio a fin, en GitHub igual que en cualquier otra parte de Sharkly: la automatización se detiene exactamente donde se requiere el criterio del equipo. Para conocer los entresijos con más detalle, el flujo de revisión human-in-the-loop de Sharkly lo explica directamente.
Cuándo basta con el propio hub de agentes de GitHub
Si tu equipo lo tiene todo en GitHub —código fuente, CI, revisión y una licencia de pago de Copilot—, el Agent HQ de GitHub coordina bien los agentes dentro de ese ecosistema y puede que no necesites nada más. El argumento a favor de Sharkly aparece cuando el trabajo también pasa por Jira, cuando los Agents se ejecutan en Computers fuera de la nube de GitHub o cuando tu equipo combina Runtimes y no quiere rehacer su flujo de trabajo cada vez que cambia el mejor de ellos. Si Jira forma parte de esa mezcla, asignar un ticket de Jira a un agente de IA recorre el mismo ciclo desde ese lado.
Para probarlo con un issue real: abre las integraciones de GitHub, Jira y Slack de Sharkly, conecta tu organización de GitHub, vincula un repositorio de poco tráfico a un Space y asigna el siguiente issue pequeño a un Agent en lugar de a ti mismo.
Preguntas frecuentes
¿Conectar mi organización de GitHub le da a un Agent acceso a mi código? No. La conexión de la organización cubre los vínculos de pull requests, la sincronización de issues y los comentarios de linkback. El acceso al código se configura aparte, en el Agent o en el Space, y la ejecución sigue necesitando sus propias credenciales de Git en el Computer.
¿Pueden chocar dos Agents que trabajan en el mismo repositorio? No con el modo Temporary predeterminado. Cada ejecución recibe su propio worktree aislado, así que los Agents concurrentes nunca comparten una copia de trabajo, ni siquiera en el mismo Computer.
¿Fusionar el pull request cerrará el issue de GitHub o la Task? Fusionar nunca cambia por sí solo el estado de la Task. Cerrar el issue subyacente de GitHub sí puede hacerlo, en un repositorio sincronizado en ambos sentidos, pero es una acción distinta de fusionar el PR.
¿A qué apunta realmente el pull request del Agent? Sharkly vincula el pull request mediante el ID de la Task en la rama, el título o el cuerpo, allí donde lo escriba tu Runtime. No impone ninguna estrategia de ramas, así que confirma el comportamiento de rama base por defecto de tu Runtime antes de asignarle algo de más peso que un issue de prueba.
¿Puedo conservar mis issues actuales de GitHub, no solo los nuevos? Vincular un repositorio sincroniza los issues que se creen a partir de ese momento. Los issues que ya existían no se importan automáticamente.
