SkillEngenhariaDiagnostica
Understanding PR Scope
Estabelece entendimento claro do escopo, intenção e risco de impacto de um PR antes da revisão técnica.
Ações
PerfilDev
ProfundidadeMédia
Idiomaen-US
Objetivo
Em uma frase.
Mapear o escopo real, a intenção e o impacto de um PR antes de qualquer revisão técnica — identificando o que de fato foi alterado, o propósito por trás das mudanças e toda discrepância entre a descrição do PR e o diff.
Aplicação
Quando
faz sentido.
Usar
- Como primeira etapa de qualquer revisão de PR, antes de analisar lógica, segurança ou performance.
- Quando a descrição do PR está incompleta ou vaga e o revisor precisa estabelecer contexto antes de prosseguir.
- Quando o PR toca múltiplos módulos e é necessário delimitar o escopo antes de dividir a revisão.
- Quando há suspeita de que o diff contém mudanças além do escopo declarado.
Não usar
- Como substituto de revisão técnica — esta skill estabelece contexto; não valida corretude.
- Após já ter executado a revisão técnica completa — o escopo deve ser mapeado primeiro, sempre.
Prompt
Instruções
para a IA.
Passo 1 — Ler a descrição do PR sem olhar o diff
Leia o título e o corpo do PR completamente antes de abrir qualquer arquivo alterado. O objetivo é registrar o que o autor afirma ter feito — sem contaminação do que o diff realmente mostra.
Anote mentalmente:
- Qual é o tipo declarado de mudança: feature, bugfix, refactor, chore, hotfix?
- Qual módulo ou funcionalidade o PR afirma afetar?
- Há menção a ticket, issue ou PRD?
- Há seção de "como testar" ou "impacto esperado"?Passo 2 — Escanear o diff em nível alto
Examine a lista de arquivos alterados e o volume de linhas modificadas **antes** de ler qualquer linha de código.
Registre:
- Quais arquivos foram adicionados, modificados ou removidos.
- Quais módulos, camadas ou serviços são afetados.
- Volume aproximado: pequeno (< 50 linhas), médio (50–300 linhas), grande (> 300 linhas).
- Presença de arquivos de teste entre os alterados.
- Presença de arquivos de configuração, migrations, contratos de API, ou dependências.Passo 3 — Classificar o tipo real de mudança
Com base no diff (não na descrição), classifique o tipo real da mudança:
| Tipo | Critério |
|------------|-----------------------------------------------------------------------|
| `feature` | Novo comportamento sendo adicionado ao sistema |
| `bugfix` | Correção de comportamento incorreto existente |
| `refactor` | Mudança estrutural sem alteração de comportamento externo |
| `chore` | Configuração, dependências, formatação, sem lógica nova |
| `mixed` | Combinação de tipos — sinalizar como risco de escopo |Se o tipo real divergir do tipo declarado na descrição, registrar explicitamente.
Passo 4 — Identificar impactos em contratos externos
Verifique se o PR altera qualquer interface que afete consumidores externos:
- Assinaturas de funções ou métodos públicos.
- Contratos de API (endpoints, payloads, status codes, headers).
- Esquemas de banco de dados (migrations, índices, colunas).
- Eventos publicados ou consumidos.
- Variáveis de ambiente ou configuração.Cada contrato alterado representa risco de breaking change e deve ser sinalizado separadamente.
Passo 5 — Comparar descrição com diff
Com o contexto do diff em mãos, compare sistematicamente:
1. O que a descrição afirma que mudou ↔ o que o diff realmente alterou.
2. O que a descrição afirma que **não** mudou ↔ o que o diff mostra.
3. Mudanças no diff sem qualquer menção na descrição.Cada discrepância deve ser registrada com arquivo e tipo de discrepância.
### Passo 6 — Formular perguntas de clarificação
Para cada ponto em que a intenção não está clara após os passos anteriores, formule uma pergunta específica e direcionada ao autor. Evitar perguntas genéricas como "por que foi feito assim?". Preferir perguntas como "O arquivo X foi alterado sem menção na descrição — esta mudança é intencional e coberta pelos testes?".
---
Casos
Exemplos
de uso.
---
## Exemplo 1 — PR com escopo real maior que o declaradoConstelação
Onde
ela vive.
Bundles que incluem