issue-triage

Issue triage: audit open issues, categorize, detect duplicates, cross-ref PRs, risk assessment, post comments. Args: "all" for deep analysis of all, issue numbers to focus (e.g. "42 57"), "en"/"fr" for language, no arg = audit only in French.

By rtk-ai · 902 installs

npx skills add rtk-ai/rtk --skill issue-triage

Source repository · Upstream listing

Issue Triage Quand utiliser Skill Usage Output /issue triage Trier, analyser, commenter les issues Tableaux d'action + deep analysis + commentaires postés /repo recap Récap général pour partager avec l'équipe Résumé Markdown (PRs + issues + releases) Déclencheurs : Manuellement : /issue triage ou /issue triage all ou /issue triage 42 57 Proactivement : quand 10 issues ouvertes sans triage, ou issue stale 30j détectée Langue Vérifier l'argument passé au skill Si en ou english → tableaux et résumé en anglais Si fr , french , ou pas d'argument → français (défaut) Note : les commentaires GitHub (Phase 3) restent TOUJOURS en anglais (audience internationale) Workflow en 3 phases : audit automatique → deep analysis opt in → commentaires avec validation obligatoire. Préconditions Si l'un échoue, stop et expliquer ce qui manque. Phase 1 — Audit (toujours exécutée) Data Gathering (commandes en parallèle) Fallback collaborateurs : si gh api .../collaborators échoue (403/404) : Si toujours ambigu, demander à l'utilisateur via AskUserQuestion . Note : author est un objet {login: "..."} — toujours extraire .author.login . Analyse — 6 dimensions 1. Catégorisation (labels existants inférence titre/body) : Bug : mots clés crash , error , fail , broken , regression , wrong , unexpected Feature : add , implement , support , new , feat: Enhancement : improve , optimize , better , enhance , refactor Question/Support : how , why , help , unclear , docs , documentation Duplicate Candidate : voir dimension 3 ci dessous 2. Cross ref PRs : Scanner body de chaque PR ouverte pour fixes N , closes N , resolves N (case insensitive, regex) Construire un map : issue number [PR numbers] Une issue liée à une PR mergée → recommander fermeture 3. Détection doublons : Normaliser les titres : lowercase, strip préfixes ( bug: , feat: , [bug] , [feature] , etc.) Jaccard sur mots des titres : si score 60% entre deux issues → candidat doublon Keywords body overlap 50% → renforcement du signal Comparer aussi avec issues fermées récentes (20 dernières) Un faux positif peut être confirmé/écarté en Phase 2 4. Classification risque : Rouge : mots clés CVE , vulnerability , injection , auth bypass , security , exploit , unsafe , credentials , leak , RCE , XSS Jaune : breaking change , migration , deprecation , remove API , breaking , incompatible Vert : tout le reste 5. Staleness : 30j sans activité (updatedAt) → Stale 90j sans activité → Very Stale Calculer depuis la date actuelle 6. Recommandations d'action : Accept & Prioritize : issue claire, reproducible, dans scope Label needed : issue sans label Comment needed : info manquante, body insuffisant Linked to PR : une PR ouverte référence cette issue Duplicate candidate : candidat doublon identifié (préciser avec N ) Close candidate : stale + aucune activité récente, ou hors scope (jamais si auteur est collaborateur) PR merged → close : PR liée est mergée, issue encore ouverte Output — 5 tableaux 0 issues → afficher Aucune issue ouverte. et terminer. Note : Âge = jours depuis createdAt , format {N}j . Si 30j, afficher en gras . Copie automatique Après affichage du tableau de triage, copier dans le presse papier : Confirmer : Tableau copié dans le presse papier. (FR) / Triage table copied to clipboard. (EN) Phase 2 — Deep Analysis (opt in) Sélection des issues Si argument passé : "all" → toutes les issues ouvertes Numéros ( "42 57" ) → uniquement ces issues Pas d'argument → proposer via AskUserQuestion Si pas d'argument , afficher : Si "Passer" → fin du workflow. Exécution de l'analyse Pour chaque issue sélectionnée, lancer un agent via Task tool en parallèle : Si issue a 50 commentaires, résumer les 5 derniers uniquement. Agréger tous les rapports. Afficher un résumé après toutes les analyses. Phase 3 — Actions (validation obligatoire) Types d'actions possibles Commenter : gh issue comment {num} body file Labeler : gh issue edit {num} add label "{label}" (skip si label déjà présent) Fermer : gh issue close {num} reason "not planned" (jamais sans validation) Génération des drafts Pour chaque issue analysée, générer les actions (commentaire + labels + fermeture si applicable) en utilisant templates/issue comment.md . Règles : Langue des commentaires : anglais (audience internationale) Ton : professionnel, constructif, factuel Ne jamais re labeler une issue qui a déjà ce label Ne jamais proposer "close" pour une issue d'un collaborateur Toujours afficher le draft AVANT tout gh issue comment Affichage et validation Afficher TOUS les drafts au format : Puis demander validation via AskUserQuestion : (Générer une option par issue + "Toutes" + "Aucune") Exécution Pour chaque action validée, exécuter dans l'ordre : commenter → labeler → fermer. Confirmer chaque action : Commentaire posté sur issue {num}: {title} Si "Aucune" → Aucune action exécutée. Workflow terminé. Gestion des cas limites Situation Comportement 0 issues ouvertes Aucune issue ouverte. + terminer Issue sans body Catégoriser par titre, recommander Comment needed 50 commentaires Résumer les 5 derniers uniquement Faux positif doublon Phase 2 confirme/écarte — ne pas agir sur suspicion seule Labels déjà présents Ne pas re labeler, signaler "label déjà appliqué" Issue d'un collaborateur Jamais close candidate automatique Rate limit GitHub API Réduire limit , notifier l'utilisateur PR mergée liée à issue ouverte Recommander fermeture de l'issue Issue sans activité 90j Very Stale — proposer fermeture avec message bienveillant Duplicate confirmed in Phase 2 Poster commentaire + fermer en faveur de l'issue originale Notes Toujours dériver owner/repo via gh repo view , jamais hardcoder Utiliser gh CLI (pas curl GitHub API) sauf pour la liste des collaborateurs updatedAt peut être null sur certaines issues → traiter comme createdAt Ne jamais poster ou fermer sans validation explicite de l'utilisateur dans le chat Les commentaires draftés doivent être visibles AVANT tout gh issue comment Similarité Jaccard = intersection mots / union mots (exclure stop words : a, the, is, in, of, for, to, with, on, at, by)