Usa Linear con Ottermind: de las listas de incidencias a los próximos pasos

Incorpora tus incidencias de Linear a una conversación sobre lo que hay que hacer a continuación. Con la habilidad de Linear configurada en Ottermind, tu agente puede leer las incidencias y los comentarios accesibles, ayudarte a preparar una revisión y redactar las siguientes acciones con el contexto que ya ha registrado tu equipo. Tras la aprobación, las operaciones de escritura admitidas permiten llevar ese trabajo de vuelta a Linear.

Resulta útil cuando el gestor de incidencias contiene los detalles, pero aún hay que relacionarlos. ¿Qué incidencia necesita una decisión? ¿Dos informes de clientes describen el mismo fallo? ¿Qué información permitiría que un ingeniero se pusiera a trabajar en el siguiente ticket?

El recorrido que sigue utiliza un lanzamiento ficticio con un problema en los enlaces de invitación. Los identificadores de las incidencias, los hechos de origen y los ejemplos de resultados son ilustrativos; no representan una prueba en un espacio de trabajo conectado.

Conecta el equipo con el que quieras trabajar

Utiliza la habilidad de la API de Linear publicada por byungkyu. Esta habilidad de terceros se conecta a través de Maton y requiere autenticación en Maton y una conexión OAuth activa con Linear. La conexión determina a qué espacio de trabajo y recursos puede acceder el agente.

Activa la habilidad y vincúlala al agente que se encargue de tu tarea siguiendo la guía de habilidades de Ottermind. Si tienes varias conexiones con Linear, especifica el espacio de trabajo que quieras usar. Empieza pidiendo al agente que lea una incidencia conocida y confirme su identificador y título.

La documentación de la habilidad contempla búsquedas, consultas, creación y actualización de incidencias, y comentarios. Las operaciones de escritura requieren aprobación explícita, y algunas operaciones pueden necesitar permisos adicionales. Las instrucciones de configuración de la habilidad describen estos requisitos.

Prepara la revisión en torno a las decisiones que debe tomar el equipo

Supongamos que tu equipo prepara un lanzamiento y tres incidencias mencionan enlaces de invitación. Una ya está asignada, otra tiene un comentario reciente que pide una aclaración y la tercera contiene un informe de un cliente cuyo problema aún no se ha reproducido.

Abrir el tablero te muestra dónde están las incidencias. Preparar la revisión exige entender qué hechos deben debatirse juntos. Pide al agente que lea las descripciones y los comentarios pertinentes y que organice un orden del día breve con enlaces a las pruebas que lo respaldan.

Prepara un orden del día para revisar el lanzamiento de [proyecto] en el espacio de trabajo de Linear de [equipo].
Lee las incidencias activas y los comentarios necesarios para entender su estado actual.

Para cada punto de debate, incluye el identificador, el título, el estado y la persona asignada,
el problema o la pregunta registrada y un enlace a la incidencia que lo respalda.
Agrupa los puntos en decisiones pendientes, información que falta y bloqueos confirmados.
Usa hechos registrados. No deduzcas que una incidencia está bloqueada solo porque sea antigua.
Indica qué has revisado y qué registros no has podido recuperar. No edites incidencias.

Un buen orden del día aporta suficiente detalle para que cualquier compañero entienda por qué figura cada punto. En el ejemplo ficticio, la diferencia podría ser:

En esta petición, el trabajo del agente consiste en reunir pruebas y plantear las preguntas. Que falte un paso de reproducción es una carencia concreta. Afirmar que todo el lanzamiento está en riesgo requeriría más información.

Linear permite filtrar incidencias por sus propiedades y relaciones. Delimitar un proyecto, un equipo o un conjunto de incidencias mantiene la revisión centrada y facilita evaluar su alcance.

Lectura del conjunto de incidencias: Referencia de filtros de Linear · Guía de GraphQL de Linear

Cuando el orden del día esté listo, pide una versión más breve: «Prepara una introducción de cinco minutos para la revisión. Empieza por la decisión sobre las invitaciones y deja las solicitudes de información para después». Seguirás teniendo la tabla de pruebas completa cuando alguien necesite consultar un detalle.

Compara informes parecidos sin borrar sus diferencias

La frase «el enlace de invitación no funciona» puede describir varios fallos. Una persona quizá haya abierto un enlace caducado. Otra puede haber iniciado sesión con la cuenta equivocada. Una tercera puede ver un error tras aceptar una invitación válida.

Antes de crear una incidencia, busca posibles coincidencias. Después, pide una comparación de las descripciones, las condiciones y el comportamiento esperado. Así, una coincidencia amplia de palabras clave se convierte en una hipótesis revisable sobre qué informes conviene tratar juntos.

Busca en las incidencias de [equipo] enlaces de invitación que caducan o no se abren.
Lee las descripciones y los comentarios de las incidencias pertinentes.

Compara el comportamiento notificado, las condiciones de reproducción, el contexto afectado
y el resultado esperado. Incluye el identificador de la incidencia y el enlace de origen en cada fila.
Sugiere pares que merezca la pena revisar como posibles duplicados y justifica cada uno.
Mantén separadas las coincidencias inciertas. No cierres, fusiones ni modifiques incidencias.

Este es un pequeño ejemplo de la comparación que puedes pedir. Los identificadores y los informes son ficticios:

DEMO-41 y DEMO-63 son candidatas a debatirse juntas. Eso no demuestra que compartan la misma causa raíz. DEMO-58 también menciona invitaciones, pero su condición de reproducción apunta a una cuestión distinta.

Una pregunta útil para continuar sería: «¿Qué pruebas nos permitirían saber si DEMO-41 y DEMO-63 deben resolverse en una sola incidencia?». La respuesta podría requerir capturas de pantalla correspondientes, mensajes de error exactos o una comparación de los pasos de reproducción. Debe partir de los informes, sin inventar un diagnóstico.

Esta distinción importa al clasificar incidencias. Se trata de reducir investigaciones duplicadas sin perder información que un ingeniero pueda necesitar más adelante.

Convierte el comportamiento acordado en un ticket que se pueda implementar

Supongamos ahora que en la revisión se toma una decisión: una invitación caducada debe explicar el problema e indicar a la persona que pida una nueva invitación a un administrador del espacio de trabajo. La decisión no incluye cambiar las reglas de validez de las invitaciones.

Esas notas bastan para redactar una incidencia de alcance delimitado. Continúa en la misma conversación para mantener disponibles los informes relacionados y el motivo de la decisión.

Redacta una incidencia de Linear a partir de estas decisiones de producto aprobadas: [notas].
Usa [equipo] y [proyecto]. Enlaza los informes relacionados que acabamos de revisar.

Incluye un título conciso, el comportamiento observado, el comportamiento esperado,
el trabajo incluido, las exclusiones expresamente indicadas en las notas y los criterios de aceptación.
No inventes un enfoque de implementación. Deja sin asignar responsable y prioridad,
salvo que las notas los especifiquen. Muestra el borrador completo antes de crear la incidencia.
Después de que apruebe la creación, devuelve el identificador y la URL de la incidencia.

Para la decisión ficticia, el borrador podría contener:

• Título: Explicar el siguiente paso cuando una invitación haya caducado.
• Comportamiento observado: El flujo notificado del enlace caducado termina sin una acción útil de recuperación.
• Comportamiento esperado: Explicar que la invitación ha caducado e indicar a la persona que solicite una nueva a un administrador.
• Fuera del alcance: Cambios en las reglas de validez de las invitaciones.
• Comprobación de aceptación: Al abrir una invitación caducada, se muestran la explicación y la instrucción de recuperación acordadas.

Este es un ejemplo de redacción, no una afirmación de que Ottermind haya creado o probado una incidencia. Su propósito es mostrar cómo convertir una decisión en trabajo ejecutable sin añadir requisitos de forma implícita.

Revisa conjuntamente el comportamiento esperado y los criterios de aceptación. Si las notas no dicen si la instrucción de recuperación debe ser un botón o texto sin más, señálalo como una cuestión pendiente. Una pregunta precisa ahora resulta más útil que un detalle de diseño inventado en el ticket.

La habilidad seleccionada permite crear incidencias y añadir comentarios. Una vez aprobada la operación de escritura exacta, pide el enlace a la incidencia resultante. Si la decisión corresponde a una incidencia existente, prepara allí un comentario centrado en ella en vez de crear otro lugar donde seguir el mismo trabajo.

Mantén el siguiente paso vinculado al informe original

Una buena sesión puede dejarte tres entregables relacionados: un orden del día para la revisión, una comparación de incidencias y un borrador que refleje la decisión del equipo. Cada uno debe enlazar los registros que explican por qué existe ese trabajo.

Empieza con la habilidad de Linear y un grupo de incidencias que necesite atención. La introducción a las habilidades explica cómo poner esta capacidad a disposición de tu agente. Para conocer el enfoque de trabajo más amplio, la guía de gestión de proyectos con IA aborda la revisión y el traspaso del trabajo, mientras que la guía de espacios de trabajo para agentes muestra cómo el contexto sostiene el trabajo entre pasos.