Classificação de issues do Jira com IA: rotule work items automaticamente com o Jira Automation e o Jev

O Jira Cloud agora chama issues de work items e projetos de spaces; a documentação de automação usa os nomes novos, mas os smart values ainda começam com issue. Equipes que recebem pedidos de muita gente, por service desk, formulário de entrada ou colegas abrindo tickets direto, gastam tempo no mesmo primeiro passo: ler cada work item novo e decidir que tipo de trabalho ele é. Classificar automatiza esse passo com um rótulo de uma lista curta e fixa, por exemplo bug, feature_request, question ou other, para um filtro do quadro, uma fila ou a próxima regra pegar. Separe essa categoria de uma segunda pergunta que costuma importar tanto quanto: o texto diz que alguém está bloqueado agora? Faça-a como pergunta sim/não independente, não como rótulo, e use para adicionar um comentário ou avisar alguém, não para mudar a prioridade antes de medir o quanto acerta. Comece por rótulos porque são baratos de adicionar e fáceis de remover; mudar tipo de trabalho, responsável ou status afeta fluxos e relatórios, e um erro automático ali custa caro. Se suas issues estão no GitHub e não no Jira, o guia de rotulagem de issues do GitHub cobre a mesma ideia com GitHub Actions.

Seis componentes. 1) Gatilho: Work item created, opcionalmente limitado por JQL aos tipos de trabalho a classificar. 2) Ação: Re-fetch work item data, para que os campos preenchidos na criação estejam carregados antes de montar a requisição; o Jira não atualiza sozinho os dados de {{issue}} durante uma execução. 3) Ação: Send web request para https://jevmodel.app/api/v1/systemone com método POST, um cabeçalho Content-Type: application/json, um cabeçalho Authorization com Bearer e uma chave criada no JevModel Console → API keys com uma conta verificada (marque Hidden para mascarar o valor depois de salvar) e Custom data como corpo. Marque “Delay execution of subsequent rule actions until we’ve received a response for this web request” e também “Continue running the rule even if the request response is not successful” se quiser que o ramo de fallback rode quando a API devolver um status de erro. 4) Bloco if/else com condição de comparação avançada: {{webResponse.body.code}} igual a 0. 5) No ramo if, Edit work item com o campo Labels no JSON de campos adicionais, adicionando ai- mais o rótulo escolhido; uma segunda condição sobre a resposta sim/não pode adicionar um comentário. 6) No ramo else, adicione o rótulo needs-triage. Rótulos do Jira não aceitam espaços, mais um motivo para IDs como feature_request.

Quatro problemas explicam a maioria das regras com falha. Valores de resposta vazios: a base de conhecimento da Atlassian cita como causas comuns a opção de esperar a resposta desmarcada, ler a resposta fora do bloco if em que a requisição foi enviada e uma resposta cujo Content-Type não é application/json; o JevModel devolve JSON, então confira as duas primeiras. JSON quebrado: um resumo com aspas ou uma descrição com quebras de linha geram JSON inválido se colados crus, então envolva cada valor em asJsonString, que escapa caracteres especiais e adiciona as aspas. Se a descrição puder estar vazia, adicione uma condição de não vazia ou envie só o resumo. Tamanho: a requisição inteira do JevModel, state mais questions, precisa caber em 8.000 caracteres, então use abbreviate na descrição (o exemplo mantém 5.000). Execuções repetidas: o JevModel não tem chave de idempotência, então uma regra em Work item updated enviaria uma requisição nova e cobrada a cada edição e poderia empilhar rótulos depois que alguém corrigiu um; dispare só na criação. Dois pontos de governança importam igual. A Atlassian avisa que quem edita uma regra pode reconfigurar uma ação Send web request para mandar dados a outro lugar, então limite os editores. Valores Hidden de cabeçalhos se perdem quando a regra ou a ação é duplicada, exportada ou importada, então digite a chave de novo. Envie só resumo e descrição, não nomes nem e-mails do relator.

O Jira Automation também oferece a ação Use Rovo agent, que pede a um agente uma resposta gerada para depois passar a uma ação com saída de texto, como um comentário. A tabela compara a forma de cada caminho conforme a documentação, não a precisão, e nenhuma linha é benchmark.

As regras são montadas no construtor de regras, então o exemplo mostra cada componente como texto com os valores para colar. A requisição segue o contrato documentado do JevModel: POST /api/v1/systemone com uma chave Bearer de conta verificada, um state e perguntas nomeadas, aqui um Choice chamado kind e um Noul chamado blocking; uma resposta bem-sucedida tem code 0 e data.answers. Não há campo model porque o site sempre chama typesafe/jev-1.13 via OpenRouter; o JevModel é independente da TypeSafe AI, que desenvolve o Jev. O prefixo ai- deixa os rótulos automáticos fáceis de achar e remover. Smart values do Jira não consultam com facilidade uma probabilidade por chave dinâmica, então esta regra aplica o rótulo e deixa a checagem de probabilidades para a amostra de teste; se precisar de limiar por rótulo, adicione uma condição por rótulo em {{webResponse.body.data.answers.kind.probabilities.bug}} e equivalentes. O 0,8 de blocking é um marcador, não uma recomendação. Durante os testes, use uma ação Log com {{webResponse.body}} e leia o log de auditoria da regra.

# Illustrative only. Jira Cloud automation rule, written out component by component.
# Trigger:  Work item created            (optional JQL: type in (Bug, Task, Story))
# Action:   Re-fetch work item data
# Action:   Send web request
#   Web request URL:  https://jevmodel.app/api/v1/systemone
#   HTTP method:      POST
#   Headers:          Content-Type = application/json
#                     Authorization = Bearer <your JevModel key>   [x] Hidden
#   Web request body: Custom data
#   [x] Delay execution of subsequent rule actions until we've received a response
#   [x] Continue running the rule even if the request response is not successful
{
  "state": {
    "summary": {{issue.summary.asJsonString}},
    "description": {{issue.description.abbreviate(5000).asJsonString}}
  },
  "questions": {
    "kind": {
      "type": "choice",
      "instructions": "Which kind of work item is this, based on its summary and description?",
      "criteria": {
        "bug": "Something that used to work is broken, slow, or shows an error.",
        "feature_request": "Asks for new behavior the product does not have yet.",
        "question": "Asks how to do something; nothing is broken.",
        "other": "Anything that fits none of the labels above."
      }
    },
    "blocking": {
      "type": "noul",
      "instructions": "Does the text say that users, customers, or a release are blocked right now?",
      "criteria": {
        "true": "Someone cannot continue their work until this is resolved.",
        "false": "Work can continue while this waits in the backlog."
      }
    }
  }
}
# If:  Advanced compare  {{webResponse.body.code}}  equals  0
#   Action: Edit work item → More options → Additional fields:
{ "update": { "labels": [ { "add": "ai-{{webResponse.body.data.answers.kind.choice}}" } ] } }
#   If:  Advanced compare  {{webResponse.body.data.answers.blocking.noul}}  greater than  0.8   (placeholder)
#     Action: Comment on work item: "Automatic check: this may be blocking someone. Please confirm."
# Else:
#   Action: Edit work item → Additional fields:
{ "update": { "labels": [ { "add": "needs-triage" } ] } }

Seus work items resolvidos são um conjunto rotulado pronto: tipo de trabalho, componentes ou rótulos foram definidos por pessoas. Exporte algumas centenas com um filtro JQL, por exemplo os resolvidos no último trimestre, mantenha resumo, descrição e a categoria humana e rode o texto no JevModel Console → Batch com a mesma pergunta Choice. O Batch devolve respostas por linha; não calcula a precisão, então junte com a coluna humana numa planilha. Confira a concordância por rótulo, quais pares se confundem (bug e question se misturam quando o relator descreve um erro de uso como bug) e com que frequência blocking é verdadeiro em work items que não eram urgentes. Reescreva definições vagas e rode a mesma amostra de novo. Depois ative a regra num único space, leia o log de auditoria por uma semana e conte quantas vezes alguém remove um rótulo ai-. Lembre que as categorias antigas foram definidas com pressa; leia algumas divergências antes de culpar o modelo. Só depois adicione mudanças de responsável ou prioridade, e mantenha-as reversíveis.

Escolha Send web request mais Jev quando quiser rótulos de uma lista que você controla, confiáveis para filtros, quadros e regras seguintes, e puder manter uma regra com corpo JSON. Escolha uma ação de agente Rovo quando o objetivo for um resumo ou sugestão gerados para uma pessoa ler num comentário. Escolha exportar CSV e Console → Batch para testar definições ou rotular um acumulado pontual sem mexer no Jira. Se os pedidos chegam como tickets do Zendesk, mensagens do Slack ou issues do GitHub, há guias específicos para essas fontes. Checklist para qualquer caminho: 1) defina rótulos com um other explícito; 2) pergunte a urgência à parte como sim/não; 3) dispare só na criação, porque o JevModel não tem chave de idempotência; 4) envie só resumo e descrição, abreviados abaixo do limite de 8.000 caracteres; 5) restrinja quem edita a regra e guarde a chave num cabeçalho Hidden; 6) comece com rótulos ai- e fallback needs-triage, e amplie a regra só depois de medir a concordância com work items resolvidos. O JevModel é só texto e não é open source; prints, anexos e logs de um work item não são classificados por esta regra.