Solicitação de Revisão de Código

O que você leva

• Solicitação de revisão de código pronta para colar no PR/MR, com checklist de foco, critérios de severidade e plano de tratamento do feedback.
• Transforme mudanças de código em pedidos de revisão objetivos, seguros e acionáveis.
• Problema: Pedidos de revisão chegam vagos, sem requisitos, sem escopo de commits e sem critérios claros para decidir o que bloqueia ou não bloqueia o merge.
• Fluxo: Analisar

Exemplo de pedido pronto

Terminei uma feature de login. Gere a solicitação de revisão usando BASE_SHA=abc123 e HEAD_SHA=def456, requisitos de autenticação, testes unitários e integração, e risco de dados pessoais.

Esta é uma das skills que a gente deixa aberta pra leitura. O arquivo abaixo é exatamente o que quem tem o catálogo completo recebe — entrada, passos, revisão e formato de saída. Use no seu assistente e adapte ao seu contexto.

---
name: "solicitacao-code-review"
description: "Use para montar uma solicitação de revisão de código clara, segura e acionável antes de atualizar PR/MR, continuar uma task ou fazer merge."
---

# Solicitação de Revisão de Código

Padroniza como pedir revisão de código em times brasileiros que usam Git, GitHub, GitLab, Bitbucket ou Azure DevOps. A skill não aprova código nem substitui o revisor: ela organiza contexto, escopo, riscos, critérios de severidade e próximos passos para reduzir regressões e merges frágeis.

## Quando Usar

- Antes de abrir, atualizar ou pedir aprovação em um pull request/merge request.
- Depois de concluir uma etapa relevante de feature, bugfix ou refatoração.
- Quando o PR envolve autenticação, autorização, pagamentos, Pix, boleto, dados pessoais, NF-e/NFS-e, migração de dados ou lógica crítica.
- Quando o feedback do revisor precisa virar uma lista clara de correções.
- Não use para “aprovar” código sem diff, testes, CI e revisão humana quando o risco for relevante.

## Resultado Esperado

Uma solicitação pronta para colar no PR/MR ou enviar ao revisor, contendo: contexto da mudança, escopo por BASE_SHA..HEAD_SHA ou link do PR, requisitos esperados, áreas de foco, riscos, testes executados, formato de feedback por severidade e regra de bloqueio para merge.

## Entradas Necessarias

Forneça o máximo possível:
- Descrição curta da mudança e objetivo de negócio/técnico.
- BASE_SHA e HEAD_SHA, ou link do PR/MR, ou resumo do diff.
- Issue/tarefa relacionada: Jira, Linear, GitHub Issue, Trello etc.
- Requisitos funcionais e não funcionais.
- Arquivos, módulos, endpoints, migrations ou jobs afetados.
- Testes executados e resultado do CI.
- Riscos conhecidos: segurança, performance, compatibilidade, dados, rollback.
- Prazo/contexto: hotfix, release, experimento, refatoração, débito técnico.

Se faltar dado essencial, peça antes de concluir. Se não houver SHAs, gere um template preenchível e explique como obter: `git rev-parse HEAD`, `git log --oneline`, `git diff BASE..HEAD`.

## Processo

1. **Confirmar escopo**: identificar se a revisão será por PR/MR, diff colado ou intervalo `BASE_SHA..HEAD_SHA`. Não inventar análise técnica sem acesso ao conteúdo.
2. **Resumir mudança**: explicar em 3-6 bullets o que mudou, por que mudou e quais requisitos devem ser validados.
3. **Mapear riscos**: marcar áreas sensíveis: auth, permissão, criptografia, Pix/boleto, fiscal, dados pessoais, migração, performance, concorrência, cache, filas, observabilidade.
4. **Montar checklist do revisor**:
   - Correção funcional e aderência aos requisitos.
   - Regressões e compatibilidade com fluxos existentes.
   - Segurança, autorização e validação de entrada.
   - Tratamento de erro, logs sem dados sensíveis e mensagens ao usuário.
   - Testes unitários, integração, contrato, e2e ou regressão.
   - Performance, transações, idempotência e rollback quando aplicável.
5. **Definir severidade do feedback**:
   - **Crítico**: vulnerabilidade, perda/corrupção de dados, vazamento, CI quebrado, regra de negócio essencial errada, risco financeiro/fiscal. Bloqueia merge.
   - **Importante**: bug provável, teste faltante relevante, performance ruim, manutenção difícil, requisito ambíguo. Corrigir antes do merge ou justificar formalmente.
   - **Menor**: estilo, clareza, nomes, pequenos ajustes sem impacto. Pode ir para follow-up se combinado.
6. **Gerar a solicitação** no formato:
   - Contexto da mudança
   - Escopo da revisão
   - Requisitos esperados
   - Áreas de foco
   - Testes/CI
   - Riscos e cuidados
   - Formato solicitado de feedback
   - Próximos passos pós-feedback
7. **Tratar feedback recebido**: listar achados por severidade, decidir ação, dono e status. Não avançar com crítico aberto.

## Ferramentas E Artefatos

- Git, GitHub PR, GitLab MR, Bitbucket PR, Azure DevOps Repos.
- VS Code, JetBrains IDEs, GitHub Desktop, linha de comando Git.
- Jira, Linear, Trello, GitHub Issues para vínculo com tarefa.
- Slack ou Microsoft Teams para acionar revisor.
- Artefatos: diff, commit SHA, descrição de PR/MR, checklist, plano de correção, evidências de teste, link do CI.

## Exemplo Brasileiro

**Cenário**: e-commerce brasileiro adicionou checkout com Pix e boleto.

Entrada resumida: `BASE_SHA=abc123`, `HEAD_SHA=def456`, PR no GitHub, módulos `payments/`, `orders/`, `webhooks/`, requisitos: gerar cobrança Pix, registrar boleto, confirmar webhook, não logar CPF/CNPJ completo, testes de integração passando.

Saída esperada: pedido de revisão pedindo foco em idempotência de webhook, autorização, validação de valor, tratamento de falha do provedor, logs mascarados, testes de regressão do checkout, ausência de tokens no diff e bloqueio de merge se houver risco de cobrança duplicada ou vazamento de dados.

## Criterios De Qualidade

- Usa linguagem clara de time técnico brasileiro, sem tradução literal desnecessária.
- Delimita escopo com SHAs, link de PR/MR ou diff; se faltar, solicita.
- Não afirma que está aprovado, seguro ou correto sem revisão real.
- Inclui requisitos, riscos, testes e áreas de foco específicas.
- Classifica feedback em Crítico, Importante e Menor.
- Bloqueia merge com crítico aberto, CI quebrado ou risco sensível sem revisão humana.
- Protege segredos, credenciais, dados pessoais e código proprietário fora de ambiente autorizado.

## Cuidados, LGPD E Escalacao Humana

- Não incluir `.env`, tokens, chaves privadas, senhas, dumps de banco, logs com CPF/CNPJ/e-mail/telefone reais ou dados de clientes.
- Para LGPD, usar dados fictícios ou mascarados e compartilhar apenas no ambiente autorizado do time.
- Escalar para tech lead, security engineer, DPO/privacidade ou especialista quando envolver autenticação, autorização, criptografia, pagamentos, Pix, boleto, fiscal, saúde, folha, dados pessoais, migração ou produção.
- Não orientar a ignorar vulnerabilidades, checks quebrados ou achados críticos por pressão de prazo.
- Esta skill organiza a revisão; a decisão final de merge é humana e deve respeitar política do repositório.

## Smoke Test

Prompt: “Terminei uma feature de login. Gere a solicitação de revisão usando BASE_SHA=abc123 e HEAD_SHA=def456, requisitos de autenticação, testes unitários e integração, e risco de dados pessoais.”

Deve retornar: solicitação estruturada com contexto, escopo `abc123..def456`, requisitos de login, foco em auth/autorização/sessão/logs/testes, severidade Crítico/Importante/Menor, alerta LGPD e recomendação de não fazer merge com crítico aberto. Não deve inventar que o código está correto sem ver o diff.