gh-issues

• Você tem um backlog de issues de bug com escopo bem definido e quer uma primeira tentativa de correção automatizada antes da revisão humana.
• Você executa um pipeline de CI/cron agendado e quer que as issues sejam triadas e transformadas em PRs automaticamente, sem intervenção manual (modo --cron).
• Você trabalha com um modelo de contribuição baseado em fork e precisa que as branches sejam enviadas para o seu fork com PRs apontando para um repositório upstream (--fork).
• Você quer que os comentários de revisão de PR sejam tratados automaticamente — use --reviews-only para que o gh-issues escaneie PRs abertos do tipo fix/issue-* e envie correções para as mudanças solicitadas.

• Issues são vagas, arquiteturais ou de grande escopo — os sub-agentes da skill fazem uma autoavaliação de confiança e vão ignorar issues com pontuação abaixo de 7/10, mas issues altamente complexas devem ser tratadas manualmente.
• Você precisa de correção garantida — os sub-agentes executam testes quando disponíveis, mas correções geradas automaticamente devem ser revisadas antes de serem mescladas em produção.
• Você não tem um token do GitHub (GH_TOKEN) — a skill gh-issues não consegue se autenticar em nenhuma API do GitHub sem ele.

Até 8 sub-agentes são executados simultaneamente, cada um resolvendo uma issue de ponta a ponta: criação de branch, análise de código, implementação de correção, execução de testes, commit, push e abertura de PR. Cada agente tem um orçamento de 60 minutos e uma verificação de confiança integrada — ele ignora issues que não consegue tratar com confiança ≥7/10.

Após a abertura dos PRs, a Fase 6 busca revisões, comentários inline, comentários gerais do PR e até revisões incorporadas de bots (ex.: Greptile). Comentários acionáveis disparam sub-agentes adicionais que fazem checkout do branch, aplicam as alterações solicitadas, enviam uma atualização e respondem a cada comentário com o SHA do commit.

Passe --fork usuario/repositorio para enviar todas as branches para o seu fork e abrir PRs a partir do fork direcionados ao repositório de origem upstream — seguindo o fluxo de contribuição padrão de código aberto sem exigir acesso de escrita ao repositório upstream.

--cron habilita o agendamento do tipo dispara-e-esquece: o orquestrador seleciona uma issue elegível, inicia um sub-agente e encerra imediatamente — seguro para ser chamado por um cron job a cada poucos minutos. --watch mantém o orquestrador ativo, verificando periodicamente novas issues e comentários de revisão em um intervalo configurável.

Antes de iniciar, a skill verifica a existência de PRs abertos, branches em andamento no repositório de push e um arquivo local de reivindicações com expiração de 2 horas. Isso evita que sub-agentes duplicados disputem a mesma issue em execuções de cron sobrepostas ou ciclos de monitoramento simultâneos.

Passe --notify-channel com um ID de canal do Telegram para receber uma mensagem de resumo final contendo links de PRs e resultados por issue. Apenas o resultado final é enviado — não as atualizações intermediárias de status.

Execute /gh-issues owner/repo --label bug --limit 10 --cron a partir de um job agendado. Cada invocação seleciona o próximo bug não atribuído, inicializa um sub-agente para implementar a correção e encerra. Com o tempo, o backlog é processado de forma incremental sem envolvimento humano entre as execuções.

Use /gh-issues upstream/project --fork myfork/project --label good-first-issue para que a skill busque issues do repositório upstream, envie branches de correção para o seu fork e abra PRs direcionados ao upstream — respeitando o fluxo de trabalho padrão do contribuidor.

Agende /gh-issues owner/repo --reviews-only --cron junto ao seu pipeline de PR existente. Cada execução verifica os PRs abertos fix/issue-* em busca de revisões CHANGES_REQUESTED ou comentários inline não tratados, seleciona o primeiro PR pendente e inicia um agente para aplicar as mudanças solicitadas e responder.

Execute /gh-issues owner/repo --label enhancement --watch --interval 10 durante uma sessão de planejamento de sprint. A skill busca as issues, solicita que você confirme quais processar, cria agentes e verifica a cada 10 minutos se há novas issues e feedbacks de revisão — apresentando resultados acumulados até que você diga 'stop'.