gh-issues

• Vous avez un backlog de bugs clairement délimités et souhaitez une première tentative de correction automatisée avant la revue humaine.
• Vous exécutez un pipeline CI/cron planifié et souhaitez que les issues soient automatiquement triées et fassent l'objet de PRs sans intervention manuelle (mode --cron).
• Vous travaillez avec un modèle de contribution basé sur des forks et avez besoin que les branches soient poussées vers votre fork avec des PRs ciblant un dépôt upstream (--fork).
• Vous souhaitez que les commentaires de revue de PR soient traités automatiquement — utilisez --reviews-only pour que gh-issues analyse les PRs fix/issue-* ouvertes et pousse des corrections pour les changements demandés.

• Les issues sont vagues, architecturales ou de grande envergure — les sous-agents du skill s'auto-évaluent en termes de confiance et ignoreront les issues qu'ils notent en dessous de 7/10, mais les issues très complexes doivent être traitées manuellement.
• Vous avez besoin d'une correction garantie — les sous-agents exécutent les tests lorsqu'ils sont disponibles, mais les correctifs générés automatiquement doivent être vérifiés avant d'être fusionnés en production.
• Vous n'avez pas de token GitHub (GH_TOKEN) — le skill ne peut pas s'authentifier auprès d'une API GitHub sans celui-ci.

Jusqu'à 8 sous-agents s'exécutent simultanément, chacun prenant en charge un problème de bout en bout : création de branche, analyse du code, implémentation du correctif, exécution des tests, commit, push et ouverture d'une PR. Chaque agent dispose d'un budget de 60 minutes et d'une vérification de confiance intégrée — il ignore les problèmes qu'il ne peut pas traiter avec un niveau de confiance ≥ 7/10.

Après l'ouverture des PRs, la Phase 6 récupère les revues, les commentaires en ligne, les commentaires généraux sur la PR, ainsi que les revues intégrées par des bots (par exemple, Greptile). Les commentaires nécessitant une action déclenchent des sous-agents supplémentaires qui extraient la branche, appliquent les modifications demandées, poussent une mise à jour et répondent à chaque commentaire avec le SHA du commit.

Passez --fork utilisateur/dépôt pour pousser toutes les branches vers votre fourche et ouvrir des PR depuis la fourche ciblant le dépôt source en amont — correspondant au flux de contribution open-source standard sans nécessiter d'accès en écriture au dépôt en amont.

--cron active la planification en mode fire-and-forget : l'orchestrateur sélectionne un ticket éligible, lance un sous-agent, puis se termine immédiatement — il est ainsi possible de l'appeler depuis une tâche cron toutes les quelques minutes. --watch maintient l'orchestrateur actif, en surveillant les nouveaux tickets et les commentaires de révision selon un intervalle configurable.

Avant de lancer un sous-agent, la compétence gh-issues vérifie l'existence de PR ouvertes, de branches en cours sur le dépôt push, ainsi qu'un fichier de réclamations local avec une expiration de 2 heures. Cela empêche les sous-agents en double de se disputer la même issue lors d'exécutions cron ou de cycles de surveillance qui se chevauchent.

Passez --notify-channel avec un identifiant de canal Telegram pour recevoir un message de résumé final contenant les liens des PR et les résultats par problème. Seul le résultat final est envoyé — pas les mises à jour de statut intermédiaires.

Exécutez /gh-issues owner/repo --label bug --limit 10 --cron depuis une tâche planifiée. Chaque invocation sélectionne le prochain problème de bug non pris en charge, lance un sous-agent pour implémenter un correctif, puis se termine. Au fil du temps, le backlog est traité de manière incrémentielle sans intervention humaine entre les exécutions.

Utilisez /gh-issues upstream/project --fork myfork/project --label good-first-issue pour que le skill récupère les issues du dépôt upstream, pousse les branches de correctif vers votre fork et ouvre des PR ciblant le dépôt upstream — en respectant le workflow standard du contributeur.

Planifiez /gh-issues owner/repo --reviews-only --cron en parallèle de votre pipeline de PR existant. Chaque exécution analyse les PR fix/issue-* ouvertes à la recherche de revues CHANGES_REQUESTED ou de commentaires en ligne non traités, sélectionne la première PR non prise en charge et lance un agent pour appliquer les modifications demandées et répondre.

Exécutez /gh-issues owner/repo --label enhancement --watch --interval 10 lors d'une session de planification de sprint. La compétence récupère les tickets, vous demande de confirmer lesquels traiter, lance des agents, et interroge le dépôt toutes les 10 minutes pour détecter les nouveaux tickets et les retours de révision — en présentant les résultats cumulés jusqu'à ce que vous disiez « stop ».