Vérification de préparation des PR communautaires

Étant donné un numéro de PR ou un nom de branche, déterminez si elle est prête pour un examen humain et prenez la bonne action de suivi.

Arbre de décision

1. Auteur bot (n8n-cat-bot / aikido-autofix) → cleanup-only, pas d'examen. Voir « Internal automation PRs » ci-dessous.
2. Auto-rejection screen matches (typo-only / unsanctioned new node) → chemin d'action D — close avec le template correspondant.
3. Tous les contrôles passent (readyForReview === true) → chemin d'action B — triage to team.
4. Un ou plusieurs contrôles échouent → chemin d'action A (si le titre est minor-fix only) puis C — post comment.

Étape 1 — Résoudre la PR

Si un nom de branche est fourni, trouvez d'abord le numéro de PR :

gh pr view <branch> --repo n8n-io/n8n --json number --jq .number

Étape 2 — Récupérer et prétraiter

gh pr view <number> --repo n8n-io/n8n \
  --json number,title,body,author,headRefName,headRefOid,files,isDraft,state,labels

Internal automation PRs (auteurs bots)

Si author.login est l'un des bots internes de n8n — n8n-cat-bot / app/n8n-cat-bot ou aikido-autofix / app/aikido-autofix — ignorez la PR entièrement et effectuez les actions de nettoyage ci-dessous. Ne pas produire de sortie JSON.

1. Relabéliser la PR (les deux bots) : remplacer community → n8n team :

   gh pr edit <number> --repo n8n-io/n8n --remove-label community --add-label "n8n team"

2. Mettre à jour le ticket Linear lié (extraire GHC-XXXX selon l'étape 5) :
   • n8n-cat-bot — cancel: mcp__linear-server__save_issue avec state: "Canceled", pas de labels.
   • aikido-autofix — router vers Dev Platform: mcp__linear-server__save_issue avec team: "Developer Platform", state: "Triage", pas de labels.

Lors de l'examen d'un lot, omettez la PR ignorée de la sortie. Pour une seule PR, produisez une note d'une ligne (ex. Skipped & cleaned up #30591 (n8n-cat-bot): relabeled to n8n team, cancelled GHC-8398.).

Collision guard

Si triage:in-progress est déjà sur la PR, un autre relecteur est en cours de triage — bailout pour éviter le double traitement. Produisez une note d'une ligne (ex. Skipped #30205: already has triage:in-progress) et passez à la PR suivante. Ne pas exécuter les contrôles, ne pas modifier les labels, ne pas toucher à Linear.

Si l'utilisateur demande explicitement de retraiter une PR bloquée sur triage:in-progress (ex. une exécution précédente a crashé), il peut effacer le label manuellement et révoquer.

Sinon — marquer en cours

Supprimez tout label d'état triage:* existant avant d'ajouter triage:in-progress, pour que l'invariant single-state tienne même lors de la relecture d'une PR précédemment renvoyée avec triage:needs-info ou triage:tests-needed :

gh pr edit <number> --repo n8n-io/n8n \
  --remove-label "triage:pending" \
  --remove-label "triage:needs-info" \
  --remove-label "triage:tests-needed" \
  --remove-label "triage:complete" \
  --add-label "triage:in-progress"

Un seul de ces labels triage:* sera réellement présent ; --remove-label génère une erreur quand un label est absent, donc lancez chaque suppression comme un appel séparé (ou regroupez et ignorez les erreurs) puis faites l'ajout. Une PR porte exactement un label triage:<state> à la fois ; le skill remplace triage:in-progress par un état terminal avant la sortie (voir reference/label-flow.md).

Récupérez aussi (en parallèle)

# cubic-dev-ai PR review comments (pour le contrôle E)
gh api --paginate "repos/n8n-io/n8n/pulls/<number>/comments" \
  --jq '.[] | select(.user.login == "cubic-dev-ai[bot]") | {body: .body, path: .path}'

# n8n-assistant issue comments (pour la référence du ticket Linear)
gh api --paginate "repos/n8n-io/n8n/issues/<number>/comments" \
  --jq '[.[] | select(.user.login == "n8n-assistant[bot]" or .user.login == "n8n-assistant") | .body] | join("\n")'

Étape 2.5 — Auto-rejection screen

Selon CONTRIBUTING.md, deux patterns de PR devraient être fermés immédiatement plutôt qu'examinés :

• Typo-only PR — le diff ne contient que des corrections de spelling/grammaire sans logique ni tests.
• New-node PR — ajoute un node entièrement nouveau, sauf accord explicite de l'équipe n8n.

Si l'un des deux correspond, définissez checks.AutoReject et allez directement à l'action D. Règles complètes et comment vérifier chaque pattern : voir reference/checks.md.

Étape 3 — Exécuter les cinq contrôles

Exécutez quand AutoReject est null. Règles complètes pour chacun dans reference/checks.md :

• A. CLA — label cla-signed présent.
• B. Title — correspond au regex conventional-commit. Règles faisant autorité dans .github/pull_request_title_conventions.md.
• C. Description — chaque en-tête de section et élément de checklist du .github/pull_request_template.md est présent dans le corps de la PR. Le template est lu au moment du contrôle, donc les modifications s'appliquent automatiquement.
• D. Tests — les changements de logique source ont des fichiers de test correspondants. Ignorer pour les PRs docs/ci/chore/build.
• E. cubic-dev-ai — aucun commentaire non résolu (résolu = marqueur "Addressed in commit").

Étape 4 — Identifier l'équipe responsable

Lancez node .github/scripts/owners.mjs sur la liste des fichiers modifiés et mappez l'équipe GitHub gagnante à une équipe Linear. Table de mapping complète, procédure fallback sub-agent et règles de label : voir reference/teams.md.

Étape 5 — Extraire le ticket Linear

n8n-assistant laisse un commentaire sur chaque PR communautaire contenant This PR has been added to our internal tracker as "GHC-XXXX". Cherchez dans le corps de commentaire n8n-assistant concaténé \bGHC-\d+\b, prenez le premier match.

Si aucun commentaire n8n-assistant n'existe (PRs plus anciennes antérieures à l'automation), linearTicket est null.

Étape 6 — Sortie JSON

{
  "readyForReview": <true si tous les contrôles de passage autorisent la fusion, false sinon>,
  "messageForUser": "<Message court au contributeur listant ce qu'il doit adresser. 'N/A' si prêt.>",
  "team": "<Nom d'équipe Linear (depuis reference/teams.md), ou 'Engineering' par défaut>",
  "linearTicket": "<GHC-XXXX ou null>",
  "checks": {
    "AutoReject": <"typo-only" | "new-node" | null>,
    "CLA": <bool>,
    "Title": <bool>,
    "Description": <bool>,
    "TestsNeeded": <bool>,
    "TestsIncluded": <bool>,
    "CubicIssues": <true si des problèmes cubic non résolus existent, false sinon>
  }
}

readyForReview est true seulement quand : AutoReject est null ; CLA, Title et Description sont tous true ; CubicIssues est false ; et soit TestsNeeded est false soit TestsIncluded est true. Si AutoReject est défini, readyForReview est toujours false.

Produisez d'abord le JSON, puis prenez le chemin d'action approprié ci-dessous.

Étape 7 — Chemins d'action

Utilisez AskUserQuestion pour chaque prompt. Les sub-agents appelés pour analyse seulement doivent s'arrêter après l'étape 6 et laisser l'appelant diriger l'étape 7.

A — Correction mineure du titre

Un problème de titre est mineur s'il peut être réparé par une transformation déterministe :

• Espaces en début ou fin.
• Première lettre du résumé avec la mauvaise casse.
• Point final.
• revert: avec casse mixte nécessitant minuscules (pas de changement requis, juste signaler).

Si le seul contrôle défaillant est Title (ou Title + CubicIssues) et le problème est mineur, proposez le fix et demandez Apply proposed / Edit before applying / Skip. Appliquez avec :

gh pr edit <number> --repo n8n-io/n8n --title "<new title>"

Puis re-évaluez Title (maintenant passant) et continuez vers B ou C. Les problèmes de titre non-mineurs (mauvais/absent type, pas de colon, scope avec tiret) ont besoin d'input du contributeur — ignorez A et allez à C.

B — Triage to team (readyForReview === true)

Demandez : "PR is ready for review. Assign Linear ticket <linearTicket> to team <team> and move to <destination state>?" Options : Yes, assign and triage / No, leave as-is.

Destination state : Review pour NODES, Triage pour chaque autre équipe. Composition du label : voir reference/teams.md.

Sur Yes :

# 1. Linear
mcp__linear-server__save_issue(
  id=linearTicket,
  team=<team>,
  state=<destination>,
  labels=<computed labels>,
)
# 2. GitHub (seulement si Linear a réussi) — voir reference/label-flow.md
gh pr edit <number> --repo n8n-io/n8n \
  --remove-label "triage:in-progress" \
  --remove-label "status:pending-assignment" \
  --add-label "team:<slug>" \
  --add-label "status:team-assigned" \
  --add-label "triage:complete"

Si linearTicket est null, demandez s'il faut créer un nouveau ticket Linear avant de trier (PRs plus anciennes antérieures à n8n-assistant). Sinon ignorer B et demander à l'utilisateur.

C — Post contributor comment (readyForReview === false, pas auto-reject)

Montrez messageForUser et demandez Post as-is / Edit before posting / Skip. À la publication :

gh pr comment <number> --repo n8n-io/n8n --body "<final message>"

Puis appliquez le bon label triage terminal — exactement un, priorité triage:tests-needed > triage:needs-info. Voir reference/label-flow.md. Sur Skip, laissez la PR sur triage:in-progress pour que la boucle suivante la reprenne.

Ignorez C entièrement si A a déjà géré le seul contrôle défaillant et la PR est maintenant prête — lancez B à la place.

D — Close the PR

Utilisé quand la PR devrait être fermée plutôt qu'examinée. Trois triggers courants :

1. Auto-rejection (AutoReject défini) — typo-only ou new node non autorisé.
2. Duplicate — une autre PR ouverte adresse le même changement.
3. Out of scope / bundled — plusieurs fixes non liés qui doivent être séparés, ou scope que l'équipe n8n a refusé.

Demandez Close + comment / Edit before closing / Skip. Templates ci-dessous ; choisissez-en un et adaptez au contributeur et aux spécificités.

Typo-only:

Thanks for taking the time to send this in! Per our contributing guide we don't accept typo-only PRs — they create review overhead without changing functionality, and our spell-checker rules cover most cases automatically. Closing this for now; please feel free to open a PR that pairs a typo fix with a related logic change. 🙏

New node:

Thanks for the contribution! n8n no longer accepts new nodes directly into the core monorepo unless the team has explicitly agreed to scope one in. Please publish this as a community node instead — that gives you full ownership and avoids the long review queue here. Closing this PR per our contributing guide.

Duplicate of another PR:

Thanks for the contribution! This change is already being handled in #<other-pr>, which is further along in review. Closing this in favour of that PR to keep the queue tidy — please feel free to chime in over there if there's anything missing.

Bundled / out of scope:

Thanks for the contribution! Per our contributing guide we ask for one focused change per PR. This PR bundles <N> unrelated fixes — please reopen them as separate, focused PRs, each with the template filled in and a unit test that locks in the regression. Closing this one in the meantime. 🙏

Close action (identique pour chaque raison) :

gh pr comment <number> --repo n8n-io/n8n --body "<final message>"
gh pr close <number> --repo n8n-io/n8n
gh pr edit <number> --repo n8n-io/n8n \
  --remove-label "triage:in-progress" \
  --remove-label "status:pending-assignment" \
  --add-label "status:internal-closed" \
  --add-label "triage:complete"

Si linearTicket est défini, annulez-le aussi : mcp__linear-server__save_issue(id=linearTicket, state="Canceled"). Si gh pr close signale que la PR est déjà fermée (contributeur vous a devancé), procédez malgré tout avec le commentaire, les labels et l'annulation du ticket.

Notes

• Draft PRs — rapportez toutes les conclusions mais notez que la PR est un brouillon.
• Déjà fusionnée ou fermée — dites-le et ignorez les contrôles (n'appliquez pas les labels triage).
• Relecture d'une PR sur laquelle vous avez déjà commenté — utilisez la GitHub Timeline API pour détecter l'activité contributeur depuis le dernier touch du skill. Voir reference/re-review.md.
• Label state machine — single label triage:<state> à tout moment ; transitions documentées dans reference/label-flow.md.