Analyse d'issue Linear

Commencer le travail sur l'issue Linear $ARGUMENTS

Prérequis

Cette skill dépend d'outils externes. Avant de continuer, vérifiez leur disponibilité :

Obligatoires :

Linear MCP (mcp__linear) : Doit être connecté. Sans lui, la skill ne peut pas fonctionner du tout.
GitHub CLI (gh) : Doit être installé et authentifié. Exécutez gh auth status pour vérifier. Utilisé pour récupérer les PRs et issues liées.

Optionnels (dégradation gracieuse) :

Notion MCP (mcp__notion) : Nécessaire seulement si l'issue fait référence à des docs Notion. S'il n'est pas disponible, notez les liens Notion dans le résumé et demandez à l'utilisateur de les vérifier manuellement.
Skill loom-transcript (/loom-transcript) : Nécessaire seulement si l'issue contient des vidéos Loom. S'il n'est pas disponible, notez les liens Loom dans le résumé pour que l'utilisateur les regarde.
curl : Utilisé pour télécharger les images. Presque toujours disponible ; s'il manque, ignorez les téléchargements d'images et notez-le.

Si un outil obligatoire manque, arrêtez-vous et indiquez à l'utilisateur ce qui doit être configuré avant de continuer.

Instructions

Suivez ces étapes pour réunir un contexte complet sur l'issue :

1. Récupérer l'issue et les commentaires depuis Linear

Utilisez les outils Linear MCP pour récupérer les détails de l'issue et les commentaires ensemble :

Utilisez mcp__linear__get_issue avec l'ID de l'issue pour obtenir tous les détails, y compris les pièces jointes
Incluez les relations pour voir les issues bloquantes/liées/en doublon
Immédiatement après, utilisez mcp__linear__list_comments avec l'ID de l'issue pour récupérer tous les commentaires

Les deux appels doivent être faits ensemble à la même étape pour réunir le contexte complet au préalable.

2. Vérifier les issues privées/sécurité (OBLIGATOIRE — faire ceci avant toute autre chose)

Après récupération de l'issue, vérifiez immédiatement ses labels :

Regardez les labels retournés avec l'issue.
Si un label est n8n-private : a. Exécutez git remote -v (via Bash) pour lister tous les remotes configurés. b. Si un URL de remote contient n8n-io/n8n sans le suffixe -private (c'est-à-dire correspond au repo public), arrêtez immédiatement et dites à l'utilisateur :

Cette issue est marquée n8n-private et doit être développée dans un clone propre du repository privé.

Un ou plusieurs de vos remotes pointent vers le repo public n8n-io/n8n. Les remotes mixtes ne sont pas autorisés — vous devez travailler dans un clone local séparé de n8n-io/n8n-private sans aucune référence au repo public. Pour le processus complet, voir : https://www.notion.so/n8n/Processing-critical-high-security-bugs-vulnerabilities-in-private-2f45b6e0c94f803da806f472111fb1a5

Ne continuez pas avec d'autres étapes — retournez après avoir affiché ce message.
Si le label n'est pas présent, ou si tous les remotes pointent exclusivement vers n8n-io/n8n-private, continuez normalement.

3. Analyser les pièces jointes et les médias (OBLIGATOIRE)

IMPORTANT : Cette étape n'est PAS optionnelle. Vous DEVEZ scanner et récupérer tout le contenu visuel de la DESCRIPTION de l'issue ET de TOUS les commentaires.

Captures d'écran/Images (TOUJOURS récupérer) :

Scannez la description de l'issue ET tous les commentaires pour TOUTES les URLs d'images :
- Balises <img>
- Images Markdown ![](url)
- URLs brutes (github.com/user-attachments, imgur.com, etc.)
Pour CHAQUE image trouvée (en description ou commentaires) :
- Téléchargez avec curl -sL "url" -o /path/to/image.png (les URLs GitHub nécessitent de suivre les redirections) OU avec le linear mcp
- Utilisez l'outil Read sur le fichier téléchargé pour le visualiser
- Décrivez en détail ce que vous voyez
Ne sautez PAS les images — elles contiennent souvent un contexte critique comme les messages d'erreur, les états d'interface ou les configurations

Vidéos Loom (TOUJOURS récupérer la transcription) :

Scannez la description de l'issue ET tous les commentaires pour les URLs Loom (loom.com/share/...)
Pour CHAQUE vidéo Loom trouvée (en description ou commentaires) :
- Utilisez la skill /loom-transcript pour récupérer la transcription COMPLÈTE
- Résumez les points clés, les timestamps et tout problème démontré
Les vidéos Loom contiennent souvent des étapes de reproduction cruciales et un contexte que le texte seul ne peut pas fournir

4. Récupérer le contexte associé

Issues Linear liées :

Utilisez mcp__linear__get_issue pour toute issue mentionnée dans les relations (bloquante, bloquée par, liée, en doublon)
Résumez comment elles se rapportent à l'issue principale

PRs et issues GitHub :

Si des liens GitHub sont mentionnés, utilisez la CLI gh pour récupérer les détails des PRs/issues :
- gh pr view <number> pour les pull requests
- gh issue view <number> pour les issues
Téléchargez les images attachées aux issues : curl -H "Authorization: token $(gh auth token)" -L <image-url> -o image.png

Documents Notion :

Si des liens Notion sont présents, utilisez mcp__notion__notion-fetch avec l'URL Notion ou l'ID de page pour récupérer le contenu du document
Résumez la documentation pertinente

5. Examiner les commentaires

Les commentaires ont déjà été récupérés à l'étape 1. Examinez-les pour :

Le contexte supplémentaire et l'historique de discussion
Tout contenu attaché ou médias liés dans les commentaires (à traiter à l'étape 3)
Les clarifications ou mises à jour apportées à la description de l'issue originale

6. Identifier le nœud affecté (si applicable)

Déterminez si cette issue est spécifique à un nœud n8n particulier (par ex. un trigger, une action ou un tool node). Recherchez les indices dans :

Le titre de l'issue (par ex. « Linear trigger », « Slack node », « HTTP Request »)
La description et les commentaires mentionnant des noms de nœuds
Les labels ou tags sur l'issue (par ex. node:linear, node:slack)
Les captures d'écran montrant la configuration ou l'erreur d'un nœud spécifique

Si l'issue est spécifique à un nœud :

Trouvez l'ID du type de nœud. Utilisez Grep pour chercher le nom d'affichage du nœud (ou des mots-clés de celui-ci) dans packages/frontend/editor-ui/data/node-popularity.json pour trouver l'ID exact du type de nœud. Pour référence, les motifs d'ID courants sont :
- Nœuds core : n8n-nodes-base.<camelCaseName> (par ex. « HTTP Request » → n8n-nodes-base.httpRequest)
- Variantes trigger : n8n-nodes-base.<name>Trigger (par ex. « Gmail Trigger » → n8n-nodes-base.gmailTrigger)
- Variantes tool : n8n-nodes-base.<name>Tool (par ex. « Google Sheets Tool » → n8n-nodes-base.googleSheetsTool)
- Nœuds LangChain/AI : @n8n/n8n-nodes-langchain.<camelCaseName> (par ex. « OpenAI Chat Model » → @n8n/n8n-nodes-langchain.lmChatOpenAi)

Recherchez le score de popularité du nœud — vérifiez d'abord une évaluation Flaky (voir ci-dessous), sinon utilisez le fichier de popularité :

Primaire : Vérifiez l'évaluation de Flaky dans les commentaires Linear. Flaky est un agent d'auto-triage qui publie l'analyse des issues comme commentaire. Cherchez dans les commentaires déjà récupérés à l'étape 1 un commentaire d'un utilisateur nommé « Flaky » (ou contenant « Flaky » dans le nom de l'auteur) — ne re-récupérez pas les commentaires. S'il est trouvé, extrayez le score de popularité et le niveau directement de l'analyse de Flaky et utilisez ces valeurs.

Fallback (si aucun commentaire Flaky n'existe) : Recherchez le score de popularité du nœud dans packages/frontend/editor-ui/data/node-popularity.json. Utilisez Grep pour chercher l'ID du nœud dans ce fichier. Le score de popularité est une valeur sur une échelle log entre 0 et 1. Utilisez ces seuils pour classifier :

Score	Niveau	Description	Exemples
≥ 0,8	Élevé	Nœuds core/largement utilisés, top ~5 %	HTTP Request (0,98), Google Sheets (0,95), Postgres (0,83), Gmail Trigger (0,80)
0,4–0,8	Moyen	Intégrations régulièrement utilisées	Slack (0,78), GitHub (0,64), Jira (0,65), MongoDB (0,63)
< 0,4	Faible	Nœuds de niche ou rarement utilisés	Amqp (0,34), Wise (0,36), CraftMyPdf (0,33)

Incluez le score brut et le niveau (élevé/moyen/faible) dans le résumé, et notez si cela provient de Flaky ou du fichier de popularité.

Si le nœud ne figure pas dans le fichier de popularité (et aucun commentaire Flaky n'existe), notez qu'il peut s'agir d'un community node ou d'un nœud très nouveau/de niche.

7. Évaluer l'effort/la complexité

Primaire : Vérifiez l'estimation d'effort de Flaky dans les commentaires Linear. Cherchez un commentaire Flaky dans les commentaires déjà récupérés à l'étape 1 — ne re-récupérez pas. S'il est trouvé, extrayez l'estimation d'effort/complexité directement de celui-ci et utilisez-la comme évaluation.

Fallback (si aucun commentaire Flaky n'existe) : Après avoir réuni tout le contexte, évaluez l'effort requis pour corriger/implémenter l'issue. Utilisez les tailles de T-shirt suivantes :

Taille	Effort approximatif
XS	≤ 1 heure
S	≤ 1 jour
M	2-3 jours
L	3-5 jours
XL	≥ 6 jours

Pour faire cette évaluation, tenez compte de :

Scope des changements : Combien de fichiers/packages doivent être modifiés ? Est-ce une correction de nœud unique ou un changement transversal ?
Complexité : Est-ce un simple changement de paramètre, une nouvelle intégration API, un nouveau type de credential ou un changement architectural ?
Tests : Combien de couverture de test est nécessaire ? Des tests E2E sont-ils nécessaires ?
Risque : Cela pourrait-il casser une fonctionnalité existante ? Faut-il une compatibilité rétroactive ?
Dépendances : Y a-t-il des changements d'API externe, de nouveaux packages ou une coordination inter-équipes nécessaire ?
Documentation : Faut-il des mises à jour de docs, des guides de migration ou des entrées changelog ?

Fournissez la taille de T-shirt ainsi qu'une brève justification expliquant les facteurs clés qui ont motivé l'estimation. Notez si cela provient de Flaky ou de votre propre évaluation.

8. Présenter le résumé

Avant de présenter, vérifiez que vous avez complété :

[ ] Téléchargé et visualisé TOUTES les images de la description ET des commentaires
[ ] Récupéré les transcriptions pour TOUTES les vidéos Loom de la description ET des commentaires
[ ] Récupéré TOUTES les issues/PRs GitHub liées via la CLI gh
[ ] Listé tous les commentaires sur l'issue
[ ] Vérifié si l'issue est spécifique à un nœud et recherché la popularité si applicable
[ ] Évalué l'effort/la complexité avec la taille de T-shirt

Après avoir réuni tout le contexte, présentez un résumé complet incluant :

Aperçu de l'issue : Titre, statut, priorité, assigné, labels
Description : Description complète de l'issue avec les clarifications des commentaires
Contexte visuel : Résumé des captures d'écran/vidéos (ce que vous avez observé dans chacune)
Nœud affecté (si applicable) : Nom du nœud, ID du type de nœud (n8n-nodes-base.xxx), score de popularité avec niveau (par ex. 0,64 — popularité moyenne)
Issues liées : Comment ceci se connecte à d'autres travaux
Contexte technique : Tous les PRs, références de code ou documentation
Estimation d'effort : Taille de T-shirt (XS/S/M/L/XL) avec justification
Prochaines étapes : Approche suggérée basée sur tout le contexte réuni

Notes

L'ID de l'issue peut être fourni dans les formats : AI-1975, node-1975 ou simplement 1975 (sera recherché)
Si aucun ID d'issue n'est fourni, demandez-en un à l'utilisateur

n8n:linear-issue