Clasificación de issues de Jira con IA: etiqueta work items automáticamente con Jira Automation y Jev

Jira Cloud llama ahora work items a las issues y spaces a los proyectos; la documentación de automatización usa los nombres nuevos, aunque los smart values siguen empezando por issue. Los equipos que reciben peticiones de mucha gente, por un service desk, un formulario de entrada o compañeros que abren tickets directamente, dedican tiempo al mismo primer paso: leer cada work item nuevo y decidir qué tipo de trabajo es. Clasificar automatiza ese paso con un label de una lista corta y fija, por ejemplo bug, feature_request, question u other, para que un filtro del tablero, una cola o la siguiente regla lo recojan. Separa esa categoría de una segunda pregunta que suele importar igual: ¿el texto dice que alguien está bloqueado ahora? Hazla como pregunta sí/no independiente, no como label, y úsala para añadir un comentario o avisar a alguien, no para cambiar la prioridad hasta medir cuánto acierta. Empieza por labels porque son baratos de añadir y fáciles de quitar; cambiar el tipo de trabajo, el responsable o el estado afecta a flujos e informes, y un error automático ahí sale caro. Si tus issues están en GitHub y no en Jira, la guía de etiquetado de issues de GitHub cubre la misma idea con GitHub Actions.

Seis componentes. 1) Trigger: Work item created, opcionalmente limitado con JQL a los tipos de trabajo que quieres clasificar. 2) Acción: Re-fetch work item data, para que los campos rellenados al crear estén cargados antes de construir la petición; Jira no refresca por sí solo los datos de {{issue}} durante una ejecución. 3) Acción: Send web request a https://jevmodel.app/api/v1/systemone con método POST, una cabecera Content-Type: application/json, una cabecera Authorization con Bearer y una clave creada en JevModel Console → API keys con una cuenta verificada (marca Hidden para ocultar el valor al guardar) y Custom data como cuerpo. Marca “Delay execution of subsequent rule actions until we’ve received a response for this web request” y también “Continue running the rule even if the request response is not successful” si quieres que la rama de respaldo corra cuando la API devuelva un estado de error. 4) Bloque if/else con condición de comparación avanzada: {{webResponse.body.code}} es igual a 0. 5) En la rama if, Edit work item con el campo Labels en el JSON de campos adicionales, añadiendo ai- más el label elegido; una segunda condición sobre la respuesta sí/no puede añadir un comentario. 6) En la rama else, añade el label needs-triage. Los labels de Jira no admiten espacios, otra razón para usar IDs como feature_request.

Cuatro problemas explican la mayoría de las reglas fallidas. Valores de respuesta vacíos: la base de conocimiento de Atlassian cita como causas habituales no marcar la opción de esperar la respuesta, leer la respuesta fuera del bloque if donde se envió la petición y una respuesta cuyo Content-Type no es application/json; JevModel devuelve JSON, así que revisa las dos primeras. JSON roto: un resumen con comillas o una descripción con saltos de línea generan JSON inválido si se pegan en bruto, así que envuelve cada valor en asJsonString, que escapa los caracteres especiales y añade las comillas. Si la descripción puede estar vacía, añade una condición de que no lo esté o envía solo el resumen. Tamaño: la petición completa de JevModel, state más questions, debe caber en 8.000 caracteres, así que usa abbreviate en la descripción (el ejemplo conserva 5.000). Ejecuciones repetidas: JevModel no tiene clave de idempotencia, de modo que una regla sobre Work item updated enviaría una petición nueva y cobrada en cada edición y podría acumular labels después de que alguien corrija uno; dispara solo al crear. Dos puntos de gobierno importan igual. Atlassian advierte que quien puede editar una regla puede reconfigurar una acción Send web request para enviar datos a otro sitio, así que limita los editores. Los valores Hidden de las cabeceras se pierden al duplicar, exportar o importar la regla o la acción, así que vuelve a introducir la clave. Envía solo resumen y descripción, no nombres ni emails del informante.

Jira Automation también ofrece la acción Use Rovo agent, que pide a un agente generar una respuesta que luego pasas a una acción con salida de texto, como un comentario. La tabla compara la forma de cada vía según la documentación, no la precisión, y ninguna fila es un benchmark.

Las reglas se crean en el generador de reglas, así que el ejemplo muestra cada componente como texto con los valores para pegar. La petición sigue el contrato documentado de JevModel: POST /api/v1/systemone con una clave Bearer de una cuenta verificada, un state y preguntas con nombre, aquí un Choice llamado kind y un Noul llamado blocking; una respuesta correcta trae code 0 y data.answers. No hay campo model porque el sitio siempre llama a typesafe/jev-1.13 vía OpenRouter; JevModel es independiente de TypeSafe AI, que desarrolla Jev. El prefijo ai- hace que los labels automáticos sean fáciles de encontrar y quitar. Los smart values de Jira no permiten consultar fácilmente una probabilidad con una clave dinámica, así que esta regla aplica el label y deja la comprobación de probabilidades a tu muestra de prueba; si necesitas un umbral por label, añade una condición por label sobre {{webResponse.body.data.answers.kind.probabilities.bug}} y sus equivalentes. El 0,8 de blocking es un marcador, no una recomendación. Usa una acción Log con {{webResponse.body}} durante las pruebas y revisa el registro de auditoría de la regla.

# 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" } ] } }

Tus work items resueltos son un conjunto etiquetado listo: su tipo de trabajo, componentes o labels los pusieron personas. Exporta unos cientos con un filtro JQL, por ejemplo los resueltos del último trimestre, conserva resumen, descripción y la categoría humana, y pasa el texto por JevModel Console → Batch con la misma pregunta Choice. Batch devuelve respuestas por fila; no calcula la precisión, así que únelas con la columna humana en una hoja de cálculo. Revisa la concordancia por label, qué pares se confunden (bug y question se mezclan a menudo cuando el informante describe un error de uso como bug) y con qué frecuencia blocking es verdadero en work items que no eran urgentes. Reescribe las definiciones vagas y repite la misma muestra. Después activa la regla en un solo space, lee el registro de auditoría durante una semana y cuenta cuántas veces se quita un label ai-. Recuerda que las categorías antiguas se pusieron con prisa; lee algunos desacuerdos antes de culpar al modelo. Añade cambios de responsable o prioridad solo después, y que sean reversibles.

Elige Send web request más Jev cuando quieras labels de una lista que controlas y en los que puedan apoyarse filtros, tableros y reglas posteriores, y puedas mantener una regla con cuerpo JSON. Elige una acción de agente Rovo cuando el objetivo sea un resumen o sugerencia generados que una persona lea en un comentario. Elige exportar CSV y Console → Batch para probar definiciones o etiquetar un acumulado puntual sin tocar Jira. Si las peticiones te llegan como tickets de Zendesk, mensajes de Slack o issues de GitHub, hay guías específicas para esas fuentes. Lista para cualquiera: 1) define labels con un other explícito; 2) pregunta la urgencia aparte como sí/no; 3) dispara solo al crear, porque JevModel no tiene clave de idempotencia; 4) envía solo resumen y descripción, abreviados por debajo del límite de 8.000 caracteres; 5) limita quién edita la regla y guarda la clave en una cabecera Hidden; 6) empieza con labels ai- y respaldo needs-triage, y amplía la regla solo tras medir la concordancia con work items resueltos. JevModel es solo texto y no es de código abierto; capturas, adjuntos y logs de un work item no se clasifican con esta regla.