Seus problemas já vivem no GitHub. Assim como o código, a revisão do pull request e as regras de branch que sua equipe passou um trimestre inteiro acertando. Ninguém quer um segundo quadro para manter sincronizado com o primeiro. O que falta é uma forma de entregar um desses problemas a um agente de código e receber de volta um pull request revisável, sem sair do repositório de onde ele veio.
É isso que conectar o GitHub ao Sharkly faz. O Sharkly é uma plataforma tudo-em-um de comando e gestão de Agentes: transforma um problema do GitHub em uma Task atribuível, encaminha para um agente de código (Claude Code, Codex, Gemini ou qualquer Runtime que sua equipe use), executa o trabalho em um Computer dentro de um worktree isolado e devolve o resultado como um pull request que você revisa do jeito de sempre. Duas coisas importam mais aqui: quem de fato pode mexer no repositório e onde uma pessoa ainda precisa dar o aval.
O ciclo em uma frase
Conecte o GitHub, vincule um repositório a um Space, e um novo problema se torna uma Task. Atribua-a a um Agente e o mesmo contrato vale em todo o Sharkly: o Agente pesquisa, executa, testa e reporta; uma pessoa revisa o diff e decide o que entra.
Duas conexões, e por que elas não são a mesma coisa
A integração com o GitHub tem duas camadas, e confundi-las é o caminho mais rápido para se perder sobre quem pode ver o quê.
A primeira camada é a conexão da organização. Um Owner ou Admin da Organização abre Integrations, encontra o GitHub e instala o GitHub App nos repositórios que ele deve enxergar. É essa conexão que possibilita a vinculação de pull requests e os comentários de linkback. Membros também podem conectar uma conta pessoal do GitHub, mas isso só muda qual identidade aparece nos comentários sincronizados, não o que a conexão da organização já faz.
A segunda camada é vincular um desses repositórios a um Space. Ao fazer isso, novos problemas do GitHub começam a aparecer como Tasks; problemas já existentes não são importados. Um repositório pode alimentar um Space em uma direção (mudanças no problema fluem para dentro, nunca de volta) ou em duas direções (problemas e Tasks permanecem sincronizados nos dois sentidos), e um Space recebe apenas um repositório bidirecional por vez, então escolha com cuidado.
Aqui está a fronteira que confunde as pessoas: nada disso é como um Agente recebe permissão para clonar seu código. A integração com o GitHub cobre links de pull request, sincronização de problemas e comentários de linkback. Ela não concede a nenhum Agente acesso de leitura ou escrita a um repositório.
Dê acesso ao código ao Agente separadamente
O acesso ao código é uma configuração separada, definida no Agente ou no Space, não na conexão do GitHub. Um Agente sem repositórios próprios recorre ao que estiver configurado no Space da Task. Restrinja essa lista no próprio Agente quando ele só puder tocar em um único código entre vários que um Space referencia.
De qualquer forma, a execução ainda precisa de acesso Git funcional no próprio Computer: uma chave SSH, um token HTTPS ou credenciais de host já configuradas ali. A conexão da organização não fornece nem substitui essas credenciais. Se uma execução não consegue clonar, isso é um problema do Computer, não uma configuração do GitHub App.
Atribua o problema a um Agente
Depois que um repositório está vinculado, um novo problema do GitHub chega como uma Task (Issue, Bug, Feature e Ticket são todos tipos de tarefa válidos, dependendo do que seu Space usa). Atribuí-la a um Agente funciona igual a atribuí-la a um colega de equipe: abra o controle de Assignee e escolha o Agente.
Um Agente é uma configuração de trabalho salva, não um prompt descartável: suas instruções, Runtime, repositórios e configurações de execução moldam o trabalho, do mesmo jeito que a descrição de um cargo molda o que uma pessoa recém-contratada faz. Se a Task cair no Backlog, nada é executado ainda, isso é uma área de espera. Mova-a para um status de trabalho e o Sharkly dispara a execução assim que um Computer e um Runtime estiverem prontos.
Quando dois Agentes mexem no mesmo repositório
Esta é a parte que mais preocupa as equipes. O modo padrão é Temporary: cada Task recebe um diretório isolado, e execuções baseadas em repositório preparam um worktree novo. Dois Agentes em dois problemas diferentes do mesmo repositório recebem cada um seu próprio checkout, não um compartilhado, então não conseguem sobrescrever os arquivos um do outro nem disputar um branch, mesmo no mesmo Computer. É a mesma disciplina por trás de usar git worktrees com agentes de código de IA manualmente, só que automática.
A concorrência tem seu próprio teto. Execuções Temporary usam por padrão cerca de metade do limite total do Computer; aumente manualmente e o produto avisa quando o valor ultrapassa a capacidade de diretórios disponível, que é onde as colisões realmente começam. O modo Specified também existe, um Agente reutilizando um diretório fixo em vez de um worktree novo, mas ele atende uma execução por vez, o que se encaixa pior em um repositório que vários Agentes acessam ao mesmo tempo.
O que volta: o pull request
Quando o Agente abre um pull request, você o conecta à Task escrevendo o ID da Task no nome do branch, no título ou no corpo. Qualquer um dos três basta; um ID puro como SH-312 funciona igual a Fixes SH-312, já que não há tratamento especial para palavras como fixes, closes ou skip. Em um repositório público, apenas um autor confiável, o owner, um membro ou um colaborador, é vinculado, então o pull request de um estranho não consegue se passar por sua Task.
Pull requests vinculados também podem receber um comentário de linkback apontando de volta para a Task. Isso vem ativado por padrão para repositórios privados e desativado por padrão para os públicos, um interruptor que fica nas configurações do GitHub, separado de o Space em si ser público ou privado.
O portão de revisão: onde mora o julgamento
Fazer o merge de um pull request não muda o status da Task, e isso nunca acontece sozinho. E é proposital. O status da Task e o estado de trabalho de um Agente são acompanhados separadamente, então uma Task iniciada também pode exibir Working, Waiting for human reply, Waiting for human review ou Error, e esses sinais aparecem no Inbox para quem for responsável. Fechar ou reabrir o problema subjacente do GitHub pode mover o status de uma Task bidirecional; fazer o merge do pull request não pode.
Os Agentes pesquisam, executam, testam e reportam. As pessoas leem o diff em relação ao problema original, pedem mudanças ou aceitam, e tomam a decisão de merge e release por conta própria. Essa divisão se mantém do começo ao fim, no GitHub igual a qualquer outro lugar do Sharkly: a automação para exatamente onde o julgamento da equipe é necessário. Para os mecanismos mais profundos, o fluxo de revisão human-in-the-loop do Sharkly cobre isso diretamente.
Quando o próprio hub de agentes do GitHub já basta
Se sua equipe está totalmente dentro do GitHub, código-fonte, CI, revisão e uma assinatura paga do Copilot, o Agent HQ do próprio GitHub coordena agentes muito bem dentro desse ecossistema, e você pode não precisar de mais nada. O argumento a favor do Sharkly aparece quando o trabalho também passa pelo Jira, quando os Agentes rodam em Computers fora da nuvem do GitHub, ou quando sua equipe mistura Runtimes e não quer reconstruir seu fluxo de trabalho toda vez que o melhor deles mudar. Se o Jira faz parte dessa mistura, atribuir um ticket do Jira a um Agente de IA percorre o mesmo ciclo por esse lado.
Para experimentar com um problema real: abra as integrações do Sharkly com GitHub, Jira e Slack, conecte sua organização do GitHub, vincule um repositório de baixo tráfego a um Space e atribua o próximo problema pequeno a um Agente em vez de a você mesmo.
Perguntas frequentes
Conectar minha organização do GitHub dá a um Agente acesso ao meu código? Não. A conexão da organização cobre links de pull request, sincronização de problemas e comentários de linkback. O acesso ao código é configurado separadamente, no Agente ou no Space, e a execução ainda precisa de suas próprias credenciais Git no Computer.
Dois Agentes trabalhando no mesmo repositório chegam a colidir? Não no modo Temporary padrão. Cada execução recebe seu próprio worktree isolado, então Agentes simultâneos nunca compartilham uma cópia de trabalho, mesmo no mesmo Computer.
Fazer o merge do pull request fecha o problema do GitHub ou a Task? O merge nunca muda o status da Task por si só. Fechar o problema subjacente do GitHub pode, em um repositório com sincronização bidirecional, mas isso é uma ação separada do merge do PR.
Para onde o pull request do Agente realmente aponta? O Sharkly vincula o pull request pelo ID da Task no branch, no título ou no corpo, o que o seu Runtime escrever. Ele não impõe uma estratégia de branch, então confirme o comportamento padrão de branch base do seu Runtime antes de atribuir qualquer coisa de maior risco que um problema de teste.
Posso manter meus problemas existentes do GitHub, e não apenas os novos? Vincular um repositório sincroniza os problemas criados daqui para frente. Problemas existentes não são importados automaticamente.
