Babysit a PR

Quando Usar

• Um PR/MR acumulou threads de revisão de bots que precisam de verificação, correções, respostas e resolução.
• Você quer levar um PR de "acabou de abrir" para "nada mais a responder" em várias rodadas de revisão.

Objetivo: levar um pull request (GitHub) ou merge request (GitLab) de "acabou de abrir" para "nada mais a responder", sem que o humano precise ficar sentado atualizando a página. "PR" abaixo significa ambos.

Bots de revisão são amostras ancoradas em diffs. Cada push gera uma nova rodada, e uma correção em um lugar pode acender comentários em algo adjacente. Deixado sozinho, um PR acumula threads meio respondidas que ninguém resolve, e o bug real na terceira rodada fica enterrado sob críticas de rodadas um e dois. Seu trabalho é ser a pessoa que lê cada achado, decide o que é realmente verdade, corrige o que bloqueia e fecha todos os loops por escrito.

Você sabe como operar gh (GitHub), glab (GitLab) e git. O que se segue é apenas o julgamento que este loop precisa e as poucas chamadas de API que são fáceis de errar. O script de coleta pega o forge do git origin do cwd; tudo o que ele retorna tem a mesma forma em ambos, com um bloco capabilities nomeando o que esse forge não pode lhe dizer.

As três regras que mais importam

Verifique antes de acreditar. O selo de severidade de um bot é um palpite feito sem executar nada. Trate cada achado, incluindo os P1s, como uma afirmação a ser verificada contra o código. Bots frequentemente estão certos (é por isso que vale a pena executar este loop), e também estão confiantemente errados com frequência suficiente que enviar suas sugestões sem exame introduzirá bugs. Leia o caminho real do código antes de concordar ou discordar.

Cada thread recebe uma resposta. Um achado que você corrigiu, rejeitou ou adiou só é fechado depois que você o disse naquela thread e o resolveu. O silêncio é lido como "ignorado" para o próximo humano que abrir o PR, e é assim que um bug real se perde.

Publique antes de responder. Uma resposta "corrigido" só é verdadeira quando o branch remoto carrega a correção. Nunca poste uma resposta confirmada, ou resolva sua thread, enquanto a correção existir apenas localmente. Rejeições não precisam de push. Responda com evidências e resolva imediatamente.

Colete a rodada

Achados chegam em duas superfícies diferentes, e uma rodada que lê apenas uma delas silenciosamente perde metade deles. Esta é a maneira mais comum de um loop de babysit dar errado:

• Threads de revisão inline. É aqui que debate-review e Codex postam seus achados (Codex anexa comentários inline com selo P1/P2 a um corpo de revisão de outra forma boilerplate; um corpo com aparência vazia não prova nada). Cada thread carrega um thread_id (para resolver) e um reply_to (para responder dentro da thread). No GitHub, estas são threads de revisão GraphQL; no GitLab, são discussões.
• Corpos de revisão de nível superior. É aqui que Greptile resume, Codex às vezes posta uma lista numerada e debate-review posta seu resumo da rodada. Estes não têm thread para resolver; responda-os com um comentário de PR por rodada. No GitHub, são objetos de revisão; no GitLab, são notas simples.

O script empacotado retorna ambos em uma chamada, já correlacionados (<skill-dir> é a pasta que contém este SKILL.md):

"<skill-dir>/scripts/threads.sh" <N> > /tmp/pr-<N>-round-<k>.json

Nunca confie em uma contagem filtrada sem seu gêmeo não filtrado. Antes de aplicar qualquer filtro jq à coleta, imprima os totais brutos (jq '{threads: (.threads|length), reviews: (.reviews|length)}') e compare. Um filtro que elimina 100% dos itens é presumido quebrado até que os nomes dos campos sejam verificados contra o esquema real (jq '.threads[0] | keys'). jq seleciona em um campo mal escrito falha silenciosamente vazio, e uma "rodada limpa" construída sobre um é como um P1 recebe uma menção de merge-gate postada sobre ele. Isso aconteceu. Ferramentas do GitHub falham retornando menos dados, não por erro; emparelhe isso com a regra de paginação.

Nunca descreva um objeto que você não buscou. Se uma consulta para um id específico retornar vazio, esse é um sinal de parada. Diga "Não consigo ver" e busque de outra forma (gh api .../reviews/<id>), nunca narre seu conteúdo presumido. Armadilha relacionada: cada resposta de thread inline chega embrulhada em um objeto de revisão COMMENTED de byte zero, então um evento "nova revisão" de um observador pode ser apenas um wrapper de resposta, não uma nova rodada. O .reviews de threads.sh não inclui esses wrappers, então um id de revisão de um evento que está faltando na coleta significa "wrapper", não "ausente".

Compare com o arquivo da rodada anterior para ver o que é genuinamente novo. outdated: true em uma thread

…