O ticket já está escrito. Ele tem título, descrição, critérios de aceite e um lugar na sprint. A única coisa que separa esse ticket de um diff é uma pessoa que abre um terminal, cola o ticket em um agente de código, acompanha a execução e depois copia o resultado de volta para o Jira na mão. O trabalho e o registro do trabalho vivem em duas janelas diferentes, e manter as duas em sincronia é o que consome a tarde de alguém.
Atribuir um ticket do Jira a um agente de IA significa fechar essa lacuna: a issue se torna uma unidade de trabalho que um agente pode assumir, executar no seu repositório e devolver como uma mudança revisável, sem sair do rastreador que sua equipe já usa. Você não tira a equipe do Jira. Você adiciona uma camada onde o ticket pode, de fato, ser trabalhado.
Essa camada é o Sharkly, uma plataforma tudo-em-um de comando e gestão de Agentes. Ela se conecta ao Jira, transforma issues em Tarefas atribuíveis, encaminha essas tarefas para seus agentes de código (Claude Code, Codex, Gemini e outras ferramentas de linha de comando), executa cada uma em isolamento e devolve o resultado à Tarefa. Este guia percorre todo o ciclo: o ticket entra, o Agente é atribuído, o trabalho acontece em um worktree isolado e o pull request e a discussão voltam para o registro.
O ciclo em uma frase
A Tarefa do Sharkly é o registro compartilhado de um trabalho e, quando você conecta o Jira, cada issue do Jira se torna uma dessas Tarefas. A partir daí, o contrato é simples: os Agentes pesquisam, executam, testam e reportam; as pessoas definem a direção, concedem autoridade e aceitam o resultado. O restante deste artigo é apenas a mecânica dessa frase.
Mantenha o Jira e adicione a camada de execução
O Sharkly não substitui o Jira. Ele adiciona a camada de Tarefa compartilhada, Computador conectado, execução e revisão em volta do rastreador que sua equipe já usa. Ninguém precisa aprender um novo board nem migrar um backlog para começar.
Você conecta os dois com um link de sincronização. Abra a integração com o Jira, conecte a conta (o Jira Cloud usa seu host *.atlassian.net, o e-mail da conta e um token de API do Atlassian; Server e Data Center usam a URL base, o nome de usuário e um token de acesso pessoal) e depois pareie um projeto do Jira com um Espaço do Sharkly. Os mapeamentos principais são o que você esperaria:
- issue do Jira se torna uma Tarefa do Sharkly
- épico do Jira se torna um Projeto do Sharkly
- Responsável, status, comentários e anexos são transferidos
Aqui está o par de decisões, sem rodeios. Use sync quando quiser que um projeto ativo permaneça conectado, para que as mudanças circulem entre Jira e Sharkly daqui em diante. Use import quando quiser copiar issues históricas para uma migração controlada; a sincronização sozinha não preenche o passado de um projeto. A maioria das equipes que está começando quer apenas um link de sincronização bidirecional em um projeto ativo, e nada mais. A configuração completa, incluindo a etapa de webhook que um admin do Jira faz uma única vez, está na documentação do Sharkly.
Atribua o ticket a um Agente
Depois que o projeto está vinculado, a issue aparece como uma Tarefa no Espaço. Atribuí-la a um Agente funciona do mesmo jeito que atribuí-la a um colega: você escolhe o Agente em vez de uma pessoa.
Um Agente é mais do que uma escolha de modelo. Suas instruções, o Runtime, os repositórios e as configurações de execução definem como ele conduz o trabalho, do mesmo modo que a descrição de um cargo molda o que uma nova contratação faz. O Runtime é o motor por trás: Claude Code, Codex ou qualquer agente de CLI que sua equipe já use. O uso do modelo continua pelas assinaturas ou chaves de API configuradas nessas ferramentas, então seu acesso aos agentes e seu código permanecem no seu próprio hardware. O Sharkly coordena a atribuição; ele não fica com a posse das suas credenciais.
Se esta for sua primeira execução, mantenha o escopo pequeno e os limites explícitos. Escrever uma tarefa que um agente realmente consiga executar é uma habilidade à parte, e vale a pena acertar isso antes de apontar um Agente para algo crítico. Um ticket enxuto, com uma definição de pronto clara, gera um diff enxuto; um ticket vago gera um diff vago.
Execução em um worktree isolado
Quando o Agente começa, a execução acontece em um Computador conectado, dentro do seu próprio worktree isolado. Esse isolamento é o que torna seguro repetir o processo. Cada execução recebe um diretório de trabalho novo, então dois Agentes trabalhando em dois tickets no mesmo repositório nunca sobrescrevem os arquivos um do outro nem disputam um branch. É a mesma disciplina que você aplicaria à mão com git worktrees para agentes de código de IA, só que resolvida para você e repetível em todas as Tarefas.
É também isso que permite que o fluxo escale além de um único ticket. No momento em que o isolamento é automático, executar vários agentes em paralelo deixa de ser um malabarismo, porque aquilo que costuma quebrar (estado compartilhado em disco) é eliminado por design. Se você é novo nesse modelo, atribuir sua primeira tarefa a um agente de IA é uma entrada mais suave antes de conectar o Jira.
Traga o PR de volta para o registro
O trabalho do Agente volta para a Tarefa: a conversa, os logs de execução, os bloqueios e a mudança resultante ficam todos em um só lugar, em vez de se espalharem entre um terminal e uma conversa de chat. Quando o Agente abre um pull request, você o conecta à Tarefa escrevendo o ID da Tarefa no nome do branch, no título do PR ou no corpo do PR. A integração do Sharkly com o GitHub identifica o ID, vincula o pull request à Tarefa e pode deixar um comentário de retorno para que qualquer pessoa no ticket vá direto ao código.
Como o link de sincronização com o Jira é bidirecional, essa atividade também continua fluindo para a issue original. Quem abriu o ticket vê o trabalho avançar sem abrir um único terminal. Esse é o ganho de encaminhar o trabalho por uma Tarefa compartilhada em vez de um prompt privado: contexto, progresso, bloqueios, resultados e revisão permanecem visíveis da solicitação até a entrega.
O limite honesto: quem aceita é um humano
Nada é mesclado sozinho. Isso é intencional e vale dizer com todas as letras, porque o leitor pode supor o contrário: mesclar um pull request não altera o status da Tarefa e nunca acontece automaticamente. A automação para onde o julgamento da equipe é necessário.
A divisão de trabalho se mantém até o fim. O Agente executa o trabalho, abre o PR e relata o que fez, o que verificou e onde está inseguro. Uma pessoa lê o diff à luz dos critérios de aceite originais, pede mudanças ou aceita, e toma a decisão de merge e de release. Um agente preenche o silêncio com iniciativa sem pensar duas vezes, então a etapa de revisão não é cerimônia; é o controle que faz a parte automática merecer confiança. As decisões finais de aceite e de release continuam com as pessoas.
Esse é o ciclo completo. Um ticket do Jira entra, um Agente o assume, o trabalho roda isolado e volta para o registro como um pull request que você pode ler, e você decide se ele vai para produção. Para uma visão mais ampla de como isso se encaixa em um time de agentes, e não em uma única execução, veja o que a orquestração de agentes de IA significa para equipes de desenvolvimento, ou a visão geral do Sharkly para conhecer a plataforma inteira.
Para testar em um ticket real: baixe o Sharkly, entre em app.sharkly.ai, conecte um Computador e vincule um projeto do Jira de baixo risco.
Perguntas frequentes
O Sharkly substitui o Jira? Não. O Sharkly adiciona a camada de execução e revisão em volta do Jira. Suas issues, épicos, status e fluxos de trabalho permanecem onde estão; o link de sincronização os mantém conectados enquanto os Agentes fazem o trabalho avançar.
Quais versões do Jira funcionam? Ambas. O Jira Cloud se conecta com seu host, o e-mail da conta e um token de API do Atlassian. O Jira Server e o Data Center se conectam com a URL base, o nome de usuário e um token de acesso pessoal.
Preciso migrar meu backlog primeiro? Não. Um link de sincronização conecta um projeto ativo e mantém as mudanças futuras fluindo, sem importar o histórico. Faça uma importação separada apenas quando quiser especificamente copiar issues antigas.
Mesclar o pull request fecha o ticket? Não. Mesclar um PR não altera o status da Tarefa, por design. Uma pessoa aceita o resultado e decide a etapa de merge e de release. Veja atribuir sua primeira tarefa a um agente de IA para entender como funciona o ciclo de revisão.
Onde ficam meu código e meu acesso aos modelos? No seu próprio hardware. Os Agentes rodam em um Computador que você conecta, usando as assinaturas ou chaves de API já configuradas nas suas ferramentas de código. O Sharkly coordena atribuição, contexto e revisão; ele não hospeda seu repositório nem sua cota de modelo.
