Créer une issue

Créer un ticket Linear ou une issue GitHub pour : $ARGUMENTS

Déterminer la cible

Décider où l'issue doit être créée selon l'entrée de l'utilisateur :

Si l'utilisateur dit « Linear », « ticket » ou fournit une clé d'équipe (ex. AI, NODE, N8N) → Linear
Si l'utilisateur dit « GitHub », « GH issue » ou « open source » → GitHub
En cas d'ambiguïté, demander à l'utilisateur quelle plateforme il souhaite

Tickets Linear

Prérequis

Vérifier que le MCP Linear est connecté avant de procéder.

Guide de style

Titre

Casse de phrase — mettre en majuscule uniquement le premier mot (ex. « Ajouter la vérification webhook au déclencheur Trello »)
Descriptif — un lecteur doit comprendre la portée sans ouvrir le ticket
5–15 mots — assez long pour être spécifique, assez court pour être lisible
Mode impératif pour les fonctionnalités/améliorations — « Ajouter ... », « Supporter ... », « Améliorer ... »
Titres de bug — préfixer par Bug - suivi d'une description du symptôme (ex. « Bug - Les données épinglées ne se mettent pas à jour après l'édition du workflow »)
Pas d'identifiants de ticket dans les titres — l'identifiant (AI-1234) est attribué automatiquement
Pas de ponctuation finale

Description

Structurer la description à l'aide d'en-têtes markdown. Utiliser le modèle approprié :

Pour les bugs :

## Description
[Explication claire du problème]

## Comportement attendu
[Ce qui devrait se produire]

## Comportement actuel
[Ce qui se passe à la place]

## Pièces jointes
[Captures d'écran, vidéos ou enregistrements d'écran illustrant le problème]

## Étapes pour reproduire
1. [Reproduction étape par étape]

## Contexte supplémentaire
- Version n8n : [version]
- Base de données : [SQLite/PostgreSQL]
- Hébergement : [cloud/auto-hébergé]

Pour les fonctionnalités / améliorations :

## Résumé
[Vue d'ensemble d'un paragraphe de ce que cela ajoute ou modifie]

## Problème
[Quelle limitation ou lacune existe aujourd'hui]

## Solution proposée
[Comment cela devrait fonctionner — approche technique si connue]

## Hors du champ d'application
[Explicitement noter ce que cela NE couvre PAS, si utile]

Pour la dette technique :

## Résumé
[Quelle amélioration technique est nécessaire]

## État actuel
[À quoi ressemble le code/système aujourd'hui et pourquoi c'est problématique]

## Amélioration proposée
[À quoi devrait ressembler l'état amélioré]

## Motivation
[Pourquoi cela importe — maintenabilité, performance, expérience développeur, etc.]

## Portée
[Ce qui est inclus / exclu de ce travail]

Pour les spikes / investigations :

## Objectif
[Quelle question essayons-nous de répondre]

## Contexte
[Pourquoi cette investigation est nécessaire maintenant]

## Résultat attendu
[Quel livrable est attendu — RFC, PoC, document de décision, etc.]

Pièces jointes (Captures d'écran / Vidéos)

Si l'utilisateur fournit des captures d'écran, des vidéos ou des enregistrements d'écran :

URLs — incorporer directement dans la description en utilisant la syntaxe markdown pour images (![description](url))
Chemins de fichiers — si l'utilisateur fournit un chemin de fichier local, lui demander de l'uploader sur un service d'hébergement (ex. GitHub, Imgur) ou utiliser mcp__linear-server__create_attachment pour l'attacher au ticket Linear après la création
Images collées dans la conversation — décrire ce que l'image montre dans la description du ticket et noter qu'une capture d'écran a été fournie. Vous ne pouvez pas uploader directement des données binaires.

Toujours mentionner dans la description quand des preuves visuelles ont été fournies, même si elles ne peuvent pas être directement incorporées.

Priorité

Valeur	Niveau	Quand l'utiliser
4	Basse	Optionnel, pas d'impact utilisateur
3	Normale	Par défaut — travail planifié standard
2	Haute	Bloque d'autres travaux ou affecte significativement les utilisateurs
1	Urgente	Casse la production, faille de sécurité, perte de données
0	Aucune	Pas encore évaluée

Garde-fous :

Par défaut Normale (3) sauf si l'utilisateur déclare explicitement autre chose
Ne jamais définir Urgente (1) sauf si l'utilisateur dit explicitement « urgent », « P0 », « production down » ou « faille de sécurité »
Ne jamais définir Aucune (0) — toujours faire une évaluation de priorité. En cas de doute, utiliser Normale (3)

Statut

Garde-fous :

Ne jamais créer d'issues en statut Triage — Triage est pour les issues signalées en externe entrant via des pipelines automatisés (sync GitHub, escalade support). Les tickets créés par un agent ont un contexte connu et doivent ignorer le triage
Par défaut Backlog — utiliser quand l'issue est reconnue mais pas encore planifiée pour un sprint
Utiliser Todo uniquement quand l'utilisateur indique que le travail est planifié pour le cycle actuel ou doit être traité bientôt
Ne jamais définir In Progress, Review ou Done au moment de la création

Équipe

Essayer de récupérer les domaines de responsabilité actualisés des équipes depuis Notion en utilisant mcp__notion__notion-search (rechercher « areas of responsibility » ou similaire). Utiliser les données récupérées pour déterminer la meilleure équipe pour l'issue.
Si le MCP Notion n'est pas disponible ou la recherche échoue, revenir à ces équipes communes : Engineering (N8N), AI, NODES, Identity & Access (IAM), Catalysts (CAT), Lifecycle & Governance (LIGO), Cloud Platform, Docs (DOC)
Toujours demander à l'utilisateur quelle équipe si ce n'est pas évident d'après le contexte ou la recherche Notion
Si l'issue est spécifique à un nœud, elle appartient probablement à NODES
Si elle implique des nœuds AI/LangChain, elle appartient probablement à AI

Labels

Appliquer les labels des groupes suivants le cas échéant :

Type (en choisir un) :

bug — quelque chose est cassé
feature — capacité entièrement nouvelle
enhancement — amélioration de la fonctionnalité existante
tech debt — amélioration de la qualité interne
spike — investigation délimitée dans le temps
doc — modification de documentation uniquement

Domaine (à appliquer le cas échéant) :

frontend, backend, performance, testing, infra, DX, Security-Team

Source (à appliquer le cas échéant) :

Internal — créé par des membres de l'équipe
GitHub — provenant d'une issue GitHub
Sentry — provenant de la surveillance des erreurs
Zammad — provenant du support

Bucket (à appliquer le cas échéant) :

Utiliser le bucket de domaine fonctionnel pertinent (ex. Credentials, Canvas/Node, RBAC, LangChain nodes, Form Trigger, etc.)

Garde-fous :

Toujours appliquer un label de type — chaque ticket a besoin d'au moins un type
Ne pas appliquer les labels d'état de triage (Triage: Pending, Triage: Complete, etc.) — ces labels sont gérés par l'automatisation du triage
Ne pas appliquer les labels de version (n8n@1.36.0, etc.) — ces labels sont gérés par l'automatisation de version
Ne pas appliquer les labels docs-automation — ces labels sont gérés par l'automatisation de documentation

Estimations

Définir une estimation uniquement si l'utilisateur en fournit une ou la demande explicitement. Utiliser les t-shirt sizes :

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

Créer le ticket

Recueillir les champs obligatoires — si l'un d'eux manque, demander à l'utilisateur :
- Titre
- Équipe
- Description (en rédiger une à partir de l'entrée de l'utilisateur en utilisant les modèles ci-dessus)
Présenter un aperçu avant de créer — montrer à l'utilisateur :
- Titre
- Équipe
- Statut
- Priorité
- Labels
- Description (abrégée si longue)
Attendre la confirmation de l'utilisateur — ne pas créer avant l'approbation

Créer le ticket en utilisant mcp__linear-server__save_issue :

title: <title>
team: <team name>
description: <markdown description>
priority: <priority number>
state: <status name>
labels: [<label names>]

Rapporter avec l'identifiant et l'URL de l'issue

Choses à ne jamais faire (Linear)

Ne jamais créer d'issues en statut Triage
Ne jamais définir la priorité Urgente sans instruction explicite de l'utilisateur
Ne jamais appliquer les labels d'état de triage, de version ou docs-automation
Ne jamais définir l'assigné sauf si l'utilisateur le demande explicitement
Ne jamais définir un cycle ou une étape clé sauf si l'utilisateur le demande explicitement
Ne jamais créer d'issues en double — si l'utilisateur décrit quelque chose qui semble pouvoir exister, rechercher d'abord avec mcp__linear-server__list_issues

Issues GitHub

Prérequis

Vérifier que le CLI gh est authentifié : gh auth status

Contexte important

Le suivi des issues GitHub de n8n (n8n-io/n8n) est bugues uniquement. Les demandes de fonctionnalités et les questions sont redirigées vers le forum communautaire. Les issues vierges sont désactivées — le modèle de bug doit être utilisé.

Guide de style

Titre

Casse de phrase — identique à Linear
Descriptif du symptôme — ce qui est cassé, pas ce que vous voulez
Pas de préfixes requis — ne pas ajouter « Bug: » ou « Bug Report: » (le modèle gère la catégorisation)
Pas de ponctuation finale

Corps

Les issues GitHub doivent suivre la structure du modèle de rapport de bug :

### Description du bug

[Explication claire du bug]

### Étapes pour reproduire

1. [Étape 1]
2. [Étape 2]
3. [Étape 3]

### Comportement attendu

[Ce qui devrait se produire]

### Informations de débogage

[Si disponible — résultat de Aide > À propos de n8n > Copier les informations de débogage]

### Système d'exploitation

[ex. macOS 14.2, Ubuntu 22.04]

### Version de n8n

[ex. 1.72.1]

### Version de Node.js

[ex. 20.11.0]

### Base de données

SQLite / PostgreSQL

### Mode d'exécution

main / queue

### Hébergement

n8n cloud / auto-hébergé

Garde-fous :

Toujours inclure les étapes de reproduction — les issues sans elles sont fermées en tant que closed:incomplete-template
Inclure les infos de débogage si disponibles — c'est critique pour le triage
Ne jamais créer de demandes de fonctionnalités comme issues GitHub — rediriger l'utilisateur vers le forum communautaire ou suggérer de créer un ticket Linear

Labels

Ne pas appliquer manuellement de labels lors de la création d'issues GitHub. L'automatisation du triage gère l'étiquetage :

triage:pending est appliqué automatiquement
status:in-linear est appliqué automatiquement lors de la synchronisation

Créer l'issue

Vérifier que c'est un bug — si l'utilisateur décrit une demande de fonctionnalité, l'informer que les issues GitHub sont réservées aux bugs et suggérer des alternatives (ticket Linear ou forum communautaire)
Rédiger l'issue en utilisant le modèle ci-dessus, en remplissant les champs à partir de l'entrée de l'utilisateur
Présenter un aperçu avant de créer — montrer à l'utilisateur :
- Titre
- Corps (abrégé si long)
- Dépôt (par défaut : n8n-io/n8n)
Attendre la confirmation de l'utilisateur

Créer l'issue en utilisant gh :

gh issue create --repo n8n-io/n8n --title "<title>" --body "$(cat <<'EOF'
<body content>
EOF
)"

Rapporter avec le numéro et l'URL de l'issue

Choses à ne jamais faire (GitHub)

Ne jamais créer de demandes de fonctionnalités comme issues GitHub
Ne jamais créer d'issues sans étapes de reproduction
Ne jamais appliquer manuellement de labels — laisser l'automatisation s'en charger
Ne jamais créer d'issues dans des dépôts autres que n8n-io/n8n sauf si l'utilisateur le spécifie explicitement

Liaison croisée

Quand un ticket Linear et une issue GitHub existent pour le même problème :

Linear → GitHub : Ajouter l'URL de l'issue GitHub comme pièce jointe de lien sur le ticket Linear
GitHub → Linear : Ajouter https://linear.app/n8n/issue/<TICKET-ID> dans le corps de l'issue GitHub

Si l'utilisateur crée l'une et mentionne que l'autre existe, proposer d'ajouter la liaison croisée.

n8n:create-issue

Créer une issue

Déterminer la cible

Tickets Linear

Prérequis

Guide de style

Titre

Description

Pièces jointes (Captures d'écran / Vidéos)

Priorité

Statut

Équipe

Labels

Estimations

Créer le ticket

Choses à ne jamais faire (Linear)

Issues GitHub

Prérequis

Contexte important

Guide de style

Titre

Corps

Labels

Créer l'issue

Choses à ne jamais faire (GitHub)

Liaison croisée

Skills similaires