gh-issues

O que gh-issues faz?

Use para automação de issue para PR. Prefira a CLI gh; recorra a gh api apenas quando um comando de alto nível não tiver o campo necessário.

Argumentos

• owner/repo posicional: opcional; caso contrário, infere de git remote get-url origin.
• --label <label>: filtro.
• --limit <n>: padrão 10.
• --milestone <titulo>: filtro.
• --assignee <login|@me>: filtro.
• --state open|closed|all: padrão open.
• --fork <owner/repo>: envia branches para o fork, PR para a origem.
• --watch: monitora issues e revisões.
• --interval <minutos>: padrão 5.
• --dry-run: apenas lista.
• --yes: sem confirmação.
• --reviews-only: pula correção de issues; gerencia revisões de PR.
• --cron: executa e sai; implica --yes.
• --model <id>: passa para os workers quando suportado.
• --notify-channel <id>: destino opcional de notificação final.

Fase 1: resolver repositório

git remote get-url origin
if [ -z "${GH_TOKEN:-}" ]; then
  CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}"
  GH_TOKEN=$(jq -r '.skills.entries["gh-issues"].apiKey // empty' "$CONFIG_PATH" 2>/dev/null || true)
  if [ -n "$GH_TOKEN" ]; then export GH_TOKEN; fi
fi
gh auth status
gh repo view OWNER/REPO --json nameWithOwner,defaultBranchRef

Se gh auth status falhar e GH_TOKEN estiver ausente, pare e solicite autenticação/configuração do GitHub.

Derivado:

• SOURCE_REPO: repositório da issue.
• PUSH_REPO: fork se definido, senão origem.
• BASE_BRANCH: branch padrão da origem, a menos que o usuário especifique outro.
• PUSH_REMOTE: fork no modo fork, senão origin.

Pare se a árvore de trabalho estiver suja, a menos que o usuário confirme que os workers devem ignorar alterações não commitadas.

No modo fork, não altere remotos antes da confirmação ou durante --dry-run.

Verifique apenas autenticação/acesso de leitura:

gh auth token >/dev/null || test -n "${GH_TOKEN:-}"
gh repo view "$PUSH_REPO" --json nameWithOwner
git ls-remote --exit-code origin HEAD

Fase 2: buscar issues

Construa filtros e busque:

gh issue list --repo "$SOURCE_REPO" --state open --limit 10 --json number,title,labels,url,body,assignees,milestone

Adicione --label, --milestone, --assignee, --state, --limit conforme solicitado. gh issue list já exclui PRs.

Se nenhum for encontrado: reporte sem correspondências. Se --dry-run: mostre lista compacta e pare.

Fase 3: evitar trabalho duplicado

Para cada candidato:

gh pr list --repo "$SOURCE_REPO" --search "$SOURCE_REPO#<n>" --state open --json number,url,title,headRefName
gh pr list --repo "$SOURCE_REPO" --head "fix/issue-<n>" --state open --json number,url
gh api "repos/$PUSH_REPO/branches/fix/issue-<n>" >/dev/null

Pule candidatos com um PR aberto, branch existente ou claim local ativa.

Arquivo de claim:

${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/gh-issues-<owner>-<repo>.json

Expire claims mais antigas que 2 horas. Crie o diretório pai antes de escrever.

Fase 4: confirmar

A menos que --yes ou --cron, pergunte ao usuário para escolher:

• all
• números de issue separados por vírgula
• cancel

Após confirmação, no modo fork, configure o push remote antes de entregar o trabalho aos agentes:

gh auth setup-git
git remote get-url fork || git remote add fork "https://github.com/$PUSH_REPO.git"
git remote set-url fork "https://github.com/$PUSH_REPO.git"
git ls-remote --exit-code fork HEAD

Fase 5: disparar workers

Inicie até 8 workers em segundo plano. Não bloqueie em cada worker quando --cron.

Antes de cada disparo, escreva uma claim para SOURCE_REPO#<n> com o timestamp ISO atual. Após um worker reportar PR/falha, remova ou atualize a claim. Isso evita sobreposição de watch/cron antes que um branch ou PR exista.

O prompt do worker deve incluir:

• URL, título, corpo e labels da issue.
• SOURCE_REPO, PUSH_REPO, BASE_BRANCH, PUSH_REMOTE, modo fork.
• branch alvo fix/issue-<n>.
• prova necessária e corpo do PR.
• rota de notificação.

Instruções do worker:

Use gh e git. Não simplifique demais.
Checkout/crie fix/issue-<n> a partir de BASE_BRANCH.
Implemente correção mínima.
Execute testes relevantes.
Commit com mensagem convencional.
Envie para PUSH_REMOTE.
Abra PR contra SOURCE_REPO BASE_BRANCH.
Corpo do PR: Qual Problema Isso Resolve + Por Que Esta Alteração Foi Feita + Impacto no Usuário + Evidência + Correções Visíveis Corrige SOURCE_REPO#<n>.
Reporte URL do PR ou motivo da falha.
Envie conclusão/falha com openclaw message send se a rota for fornecida.

Use regras de lançamento coding-agent quando disponíveis.

Fase 6: coletar

Monitore workers com process ou registro de tarefas. Reporte:

• número da issue + título.
• status: PR aberto, pulado, falhou, expirou.
• URL do PR ou motivo.

Notifique o canal apenas com sumário compacto final.

Apenas revisões / monitorar revisões

Descubra PRs abertos:

gh pr list --repo "$SOURCE_REPO" --state open --json number,title,url,headRefName,reviewDecision \
  --jq '[.[] | select(.headRefName | startswith("fix/issue-"))]'

Busque threads/comentários de revisão:

gh pr view <n> --repo "$SOURCE_REPO" --json url,headRefName,comments,reviews
gh api "repos/$SOURCE_REPO/pulls/<n>/comments"
gh api "repos/$SOURCE_REPO/issues/<n>/comments"

Processe apenas PRs fix/issue-* criados por este workflow, a menos que o usuário nomeie explicitamente números de PR. Agrupe comentários acionáveis por PR. Ignore elogios, status, duplicatas e comentários já respondidos. Dispare um worker por PR selecionado/escopo, mesmas regras de segundo plano.

Instruções do worker de revisão:

Checkout branch do PR.
Leia todos os comentários de revisão acionáveis.
Aplique alterações mínimas.
Execute testes relevantes.
Commit e envie normalmente; não force push a menos que explicitamente instruído.
Responda a comentários respondidos com correção + referência de commit/arquivo.
Reporte comentários respondidos/pulados e evidência.

Modo de observação

Loop:

1. Busque issues.
2. Dispare workers de issues elegíveis.
3. Processe revisões de PR acionáveis.
4. Durma --interval.
5. Pare quando o usuário disser.

Mantenha o sumário cumulativo pequeno.