Explicador de PR + Quiz de Compreensão

O que Explicador de PR + Quiz de Compreensão faz?

A codificação assistida por IA torna fácil aprovar código que você nunca entendeu de verdade. Esta skill explica uma mudança no nível que um revisor precisa, e depois verifica a compreensão com algumas perguntas pontuais — para que "LGTM" signifique algo.

1. Colete a mudança

Escolha o que se aplica:

gh pr view <num> --json title,body,baseRefName,headRefName,files   # PR do GitHub
gh pr diff <num>
git diff <base>...<head>                                            # branch
git show <sha>                                                     # commit único

Leia a descrição da PR e a issue vinculada, se houver. Depois leia o código circundante das funções alteradas (chamadores, chamados, testes) — um diff sozinho esconde o contexto que importa.

2. Explique — nesta ordem

1. Resumo de um parágrafo: qual comportamento muda para um usuário ou chamador. Não é uma lista de arquivos.
2. Por que: o problema sendo resolvido, a partir da descrição/issue/mensagens de commit. Se o motivo não estiver declarado em lugar nenhum, diga isso — é um achado de revisão.
3. Diagrama: um sequenceDiagram ou flowchart do Mermaid do novo fluxo, destacando o que é novo/alterado (use uma nota ou classe :::changed). Mantenha abaixo de ~15 nós; diagrame o caminho central, não tudo.
4. Explicação por conceito, não por arquivo: agrupe hunks relacionados ("a lógica de retry", "a nova flag de configuração"). Para cada um: o que faz, e qualquer coisa não óbvia (concorrência, tratamento de erros, casos de borda, desempenho).
5. Notas de risco: coisas que um revisor deve examinar com mais cuidado — interfaces públicas alteradas, migrações, testes deletados, caminhos de erro suprimidos, código sensível à segurança, testes ausentes para novos ramos. Seja específico com arquivo:linha.

3. Quiz

Faça 3 a 5 perguntas, uma de cada vez, aguardando a resposta antes da próxima. Boas perguntas exigem compreensão, não memorização:

• "O que acontece agora se <dependência> expirar durante <operação>?"
• "Qual chamador existente é afetado pela mudança de assinatura, e como?"
• "Por que <linha> precisa vir antes de <linha>?"
• "Se desfizermos isso depois que a migração for executada, o que quebra?"

Evite trivia ("qual é o nome da nova função?"). Misture: pelo menos uma sobre comportamento de falha/casos de borda, uma sobre por que uma escolha de design foi feita.

Após cada resposta: diga se está correta e dê a explicação correta em 1 a 3 frases com uma referência de código. Se estiverem errados em algo importante, sugira qual parte do diff reler.

4. Conclusão

Pontuação (ex.: 4/5) e um veredito curto: "pronto para revisar" ou "releia X antes de aprovar". Ofereça-se para redigir comentários de revisão para quaisquer riscos encontrados.

Escopo conforme a solicitação

O fluxo completo (resumo → por que → diagrama → explicação → riscos → quiz) é o padrão para "me explique isso" ou "me ajude a revisar". Quando o usuário restringir a solicitação, respeite:

• "sem quiz" / "pule o quiz": etapas 1–2 sem a etapa 3.
• "apenas o resumo e riscos": o resumo de um parágrafo e as notas de risco, nada mais: sem diagrama, sem explicação. Ofereça o restante em uma única linha final.
• "apenas o diagrama": o diagrama mais uma legenda de duas frases.

O primeiro risco listado deve ser aquele que altera o comportamento para usuários ou dinheiro (como uma cobrança errada silenciosa), não o mais tecnicamente interessante.