SkillProgramaçãoDiagnostica
Entendendo o Escopo do PR
Estabelece um entendimento claro do escopo, da intenção e do risco de impacto de um PR antes da revisão técnica. Use como primeiro passo de qualquer code review, separando o que o autor afirma ter feito do que o diff realmente faz.
Ações
PerfilDev
ProfundidadeMédia
IdiomaInglês (skill original)
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 de contexto
- 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 da 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.
A skill estabelece o contexto do PR em seis passos, sempre antes de qualquer julgamento técnico.
### Passo 1 — Ler a descrição sem olhar o diff
Leia título e corpo por completo antes de abrir arquivos. Registre o tipo declarado (feature, bugfix, refactor, chore, hotfix), o módulo afetado e a referência a ticket ou PRD.
### Passo 2 — Escanear o diff em nível alto
Examine a lista de arquivos e o volume de linhas antes de ler qualquer código: o que foi adicionado, modificado ou removido, quais camadas são afetadas, o tamanho aproximado e a presença de testes, configs, migrations ou contratos de API.
### Passo 3 — Classificar o tipo real da mudança
Com base no diff (não na descrição), classifique como
### Passo 4 — Identificar impactos em contratos externos
Verifique alterações em assinaturas públicas, contratos de API, schemas de banco, eventos e variáveis de configuração. Cada contrato alterado é risco de breaking change.
### Passo 5 — Comparar descrição com diff
Confronte o que a descrição afirma que mudou, o que afirma que não mudou e o que o diff altera sem menção. Registre cada discrepância com arquivo e tipo.
### Passo 6 — Formular perguntas de clarificação
Para cada ponto em que a intenção segue obscura, faça perguntas específicas e direcionadas ao autor, evitando dúvidas genéricas.
### Passo 1 — Ler a descrição sem olhar o diff
Leia título e corpo por completo antes de abrir arquivos. Registre o tipo declarado (feature, bugfix, refactor, chore, hotfix), o módulo afetado e a referência a ticket ou PRD.
### Passo 2 — Escanear o diff em nível alto
Examine a lista de arquivos e o volume de linhas antes de ler qualquer código: o que foi adicionado, modificado ou removido, quais camadas são afetadas, o tamanho aproximado e a presença de testes, configs, migrations ou contratos de API.
### Passo 3 — Classificar o tipo real da mudança
Com base no diff (não na descrição), classifique como
feature, bugfix, refactor, chore ou mixed. Se o tipo real divergir do declarado, registre.### Passo 4 — Identificar impactos em contratos externos
Verifique alterações em assinaturas públicas, contratos de API, schemas de banco, eventos e variáveis de configuração. Cada contrato alterado é risco de breaking change.
### Passo 5 — Comparar descrição com diff
Confronte o que a descrição afirma que mudou, o que afirma que não mudou e o que o diff altera sem menção. Registre cada discrepância com arquivo e tipo.
### Passo 6 — Formular perguntas de clarificação
Para cada ponto em que a intenção segue obscura, faça perguntas específicas e direcionadas ao autor, evitando dúvidas genéricas.
Casos
Exemplos
de uso.
**Contexto:** um PR chega com o título "Fix null pointer on user profile load" e uma descrição de uma linha, mas o diff toca 8 arquivos, incluindo `AuthMiddleware.ts`, um novo `validators.ts` e a dependência `zod@3.22.0`.
**Saída esperada do agente:**
Resumo de escopo: o PR declara um bugfix pontual de null pointer, mas o diff revela mudanças substanciais em serviço, repositório, middleware de autenticação e um novo utilitário de validação, além de uma dependência externa. O escopo real é consideravelmente maior que o declarado.
Tipo real da mudança: `mixed` — combinação de bugfix com refatoração e feature não declarada.
Contratos externos afetados: `AuthMiddleware.ts` alterado (verificar mudança em validação de tokens ou em rotas cobertas) e nova dependência `zod@3.22.0` (confirmar se é de produção).
Discrepâncias: alteração em middleware de autenticação sem menção na descrição; arquivo novo `validators.ts` não citado; volume alto em `UserService.ts` para um bugfix pontual.
Perguntas de clarificação: a mudança em `AuthMiddleware.ts` é intencional e relacionada ao fix? `validators.ts` introduz validação além do fix e tem testes? `zod` precisa ser dependência de produção ou pode ser `devDependency`?Constelação
Onde
ela vive.
Bundles que incluem
Execução
Como usar
com IA.
- 01Copie a skill (botão "Copiar skill para IA", no topo): o texto copiado já é a skill completa, não um resumo.
- 02Abra o Claude ou Claude Code e cole — a IA recebe todas as instruções e fica pronta para a tarefa.
- 03Prefere usar como arquivo reutilizável? Baixe o .zip e coloque o
SKILL.mdem.claude/skills/(Claude Code) ou anexe o arquivo no Claude (claude.ai).