Utiliser Linear avec Ottermind : des listes de tickets aux prochaines actions

Intégrez vos tickets Linear à une conversation sur les prochaines actions à mener. Une fois la compétence Linear configurée dans Ottermind, votre agent peut lire les tickets et commentaires accessibles, vous aider à préparer une revue et rédiger les suites à donner à partir du contexte déjà consigné par votre équipe. Après approbation, les opérations d’écriture prises en charge permettent de reporter ce travail dans Linear.

C’est utile lorsque l’outil de suivi contient les détails, mais qu’il reste à les relier. Quel ticket appelle une décision ? Deux signalements clients décrivent-ils la même défaillance ? Quelles informations rendraient le prochain ticket prêt à être pris en charge par un ingénieur ?

Le scénario ci-dessous présente une livraison fictive comportant un problème de liens d’invitation. Les identifiants des tickets, les faits sources et les exemples de résultats sont illustratifs ; ils ne proviennent pas d’un test sur un espace de travail connecté.

Connecter l’équipe avec laquelle vous souhaitez travailler

Utilisez la compétence API Linear publiée par byungkyu. Cette compétence tierce passe par Maton et nécessite une authentification Maton ainsi qu’une connexion OAuth Linear active. La connexion détermine l’espace de travail et les ressources auxquels l’agent peut accéder.

Activez la compétence et associez-la à l’agent chargé de votre tâche en suivant le guide des compétences Ottermind. Si vous disposez de plusieurs connexions Linear, précisez l’espace de travail souhaité. Commencez par demander à l’agent de lire un ticket connu et de confirmer son identifiant et son titre.

La documentation de la compétence couvre la recherche, les requêtes, la création et la mise à jour des tickets, ainsi que les commentaires. Les écritures nécessitent une approbation explicite et certaines opérations peuvent demander des périmètres d’autorisation supplémentaires. Les instructions de configuration de la compétence détaillent ces exigences.

Préparer la revue autour des décisions que l’équipe doit prendre

Supposons que votre équipe prépare une livraison et que trois tickets mentionnent les liens d’invitation. L’un est déjà attribué, un autre comporte un commentaire récent demandant une précision, et le troisième contient un signalement client dont le problème n’a pas encore été reproduit.

Ouvrir le tableau vous indique où se trouvent les tickets. Préparer la revue demande de comprendre quels faits doivent être examinés ensemble. Demandez à l’agent de lire les descriptions et les commentaires pertinents, puis de dresser un ordre du jour court avec des liens vers les éléments qui l’étayent.

Prépare un ordre du jour de revue de livraison pour [projet] dans l’espace de travail Linear de [équipe].
Lis les tickets actifs et les commentaires nécessaires pour comprendre leur état actuel.

Pour chaque point à discuter, indique l’identifiant, le titre, le statut et la personne responsable du ticket,
le problème ou la question consignée, ainsi qu’un lien vers le ticket correspondant.
Classe les points en décisions à prendre, informations manquantes et blocages confirmés.
Utilise les faits consignés. Ne déduis pas qu’un ticket est bloqué simplement parce qu’il est ancien.
Précise ce que tu as examiné et les éléments que tu n’as pas pu récupérer. Ne modifie aucun ticket.

Un ordre du jour efficace donne assez de détails pour qu’un collègue comprenne la présence de chaque point. Dans notre exemple fictif, cela pourrait donner :

Dans cette demande, le rôle de l’agent consiste à réunir les éléments disponibles et à formuler les questions. Une étape de reproduction manquante est une lacune concrète. Affirmer que toute la livraison est compromise demanderait davantage d’informations.

Linear permet de filtrer les tickets selon leurs propriétés et leurs relations. Définir un projet, une équipe ou un ensemble de tickets précis permet de cibler la revue et d’en évaluer plus facilement la couverture.

Lecture de l’ensemble de tickets: Référence sur les filtres Linear · Guide GraphQL de Linear

Une fois l’ordre du jour prêt, demandez une version plus resserrée : « Prépare une introduction de cinq minutes pour la revue. Commence par la décision sur les invitations, puis place les demandes d’information. » Le tableau détaillé reste disponible si quelqu’un souhaite vérifier un point.

Comparer les signalements similaires sans effacer leurs différences

La phrase « le lien d’invitation ne fonctionne pas » peut recouvrir plusieurs défaillances. Une personne a peut-être ouvert un lien expiré. Une autre est peut-être connectée au mauvais compte. Une troisième peut rencontrer une erreur après avoir accepté une invitation valide.

Avant de créer un ticket, recherchez les correspondances possibles. Demandez ensuite une comparaison des descriptions, des conditions et du comportement attendu. Vous passez ainsi d’une simple correspondance de mots-clés à une hypothèse vérifiable sur les signalements à traiter ensemble.

Recherche dans les tickets de [équipe] les liens d’invitation qui expirent ou ne s’ouvrent pas.
Lis les descriptions et commentaires des tickets pertinents.

Compare le comportement signalé, les conditions de reproduction, le contexte concerné
et le résultat attendu. Indique l’identifiant du ticket et le lien source sur chaque ligne.
Propose des paires à examiner comme doublons possibles, en justifiant chaque proposition.
Garde les correspondances incertaines séparées. Ne ferme, ne fusionne et ne modifie aucun ticket.

Voici un petit exemple de la comparaison à demander. Ces identifiants et signalements sont fictifs :

DEMO-41 et DEMO-63 pourraient faire l’objet d’une même discussion. Cela ne prouve pas qu’ils ont la même cause racine. DEMO-58 mentionne aussi les invitations, mais sa condition de reproduction soulève une autre question.

Une relance utile serait : « Quels éléments permettraient de savoir si DEMO-41 et DEMO-63 doivent être traités dans un seul ticket ? » La réponse peut demander des captures d’écran correspondantes, les messages d’erreur exacts ou une comparaison des étapes de reproduction. Elle doit découler des signalements, sans inventer de diagnostic.

Cette distinction compte lors du tri des tickets. Il s’agit d’éviter les investigations en double tout en conservant les informations dont un ingénieur pourrait avoir besoin plus tard.

Transformer le comportement validé en ticket réalisable

Supposons maintenant que la revue aboutisse à une décision : une invitation expirée doit expliquer le problème et inviter la personne à demander une nouvelle invitation à un administrateur de l’espace de travail. La décision ne prévoit pas de modifier les règles de validité des invitations.

Ces notes suffisent à rédiger un ticket au périmètre délimité. Poursuivez dans la même conversation afin de conserver les signalements liés et les raisons de la décision à disposition.

Rédige un ticket Linear à partir de ces décisions produit approuvées : [notes].
Utilise [équipe] et [projet]. Ajoute les liens vers les signalements associés que nous venons d’examiner.

Inclus un titre concis, le comportement observé, le comportement attendu,
les travaux inclus, les exclusions explicitement mentionnées dans les notes et les critères d’acceptation.
N’invente pas d’approche technique. Ne définis ni responsable ni priorité,
sauf si les notes les précisent. Montre le brouillon complet avant de créer le ticket.
Après mon approbation de la création, renvoie l’identifiant et l’URL du ticket.

Pour cette décision fictive, le brouillon pourrait contenir :

• Titre : Expliquer la prochaine étape lorsqu’une invitation a expiré.
• Comportement observé : Le parcours signalé pour un lien expiré se termine sans action de récupération utile.
• Comportement attendu : Expliquer que l’invitation a expiré et inviter la personne à demander une nouvelle invitation à un administrateur.
• Hors périmètre : Modification des règles de validité des invitations.
• Vérification d’acceptation : L’ouverture d’une invitation expirée affiche l’explication et la consigne de récupération convenues.

Il s’agit d’un exemple de rédaction, et non de l’affirmation qu’Ottermind a créé ou testé un ticket. Son objectif est de montrer comment rendre une décision exploitable sans ajouter discrètement des exigences.

Examinez ensemble le comportement attendu et les critères d’acceptation. Si les notes ne précisent pas si la consigne de récupération doit prendre la forme d’un bouton ou d’un simple texte, signalez ce point comme non résolu. Une question précise maintenant vaut mieux qu’un détail de conception inventé dans le ticket.

La compétence choisie permet de créer des tickets et d’ajouter des commentaires. Une fois l’écriture exacte approuvée, demandez le lien du ticket obtenu. Si la décision concerne un ticket existant, préparez-y un commentaire ciblé plutôt que de créer un autre endroit où suivre le même travail.

Relier la prochaine étape au signalement d’origine

Une bonne session peut produire trois livrables liés : un ordre du jour de revue, une comparaison de tickets et un brouillon fidèle à la décision de l’équipe. Chacun doit renvoyer aux éléments qui expliquent la raison d’être du travail.

Commencez par la compétence Linear et un groupe de tickets qui mérite votre attention. L’introduction aux compétences explique comment mettre cette capacité à disposition de votre agent. Pour une approche plus globale, le guide de gestion de projet avec l’IA aborde la revue et la transmission du travail, tandis que le guide des espaces de travail pour agents montre comment le contexte accompagne le travail d’une étape à l’autre.