Skills: Skill de Revisão de Código
Última atualização: 2026-08-31
A revisão de código é a primeira linha de defesa da qualidade — um excelente Skill de revisão é como ter um revisor sênior incansável na equipe.
1. Design das dimensões de revisão
(1) Dimensões centrais de revisão
| Dimensão | Itens de verificação | Severidade |
|---|---|---|
| Segurança | Injeção SQL, XSS, chaves hardcoded, dependências inseguras | 🔴 Crítico |
| Desempenho | Consultas N+1, vazamentos de memória, loops desnecessários | 🟡 Importante |
| Legibilidade | Convenções de nomenclatura, comprimento de funções, adequação de comentários | 🟢 Sugestão |
| Melhores práticas | Tratamento de erros, princípios SOLID, DRY | 🟡 Importante |
| Cobertura de testes | Testes unitários, condições de contorno, caminhos de erro | 🟡 Importante |
(2) Dimensões específicas por linguagem
## Verificações extras para Python
- Completude de type hints
- Formato de docstring (estilo Google/NumPy)
- f-string vs format/concat
- Escopo de captura de exceção (evitar bare except)
## Verificações extras para TypeScript
- Uso do tipo any
- Validade de type assertion
- Completude de definição de interface
- Anotações de propriedades opcionais
2. Design do fluxo de revisão
(1) Fluxo padrão
Fluxo de revisão de código
├── 1. Coletar mudanças
│ ├── Ler git diff (lista de arquivos alterados)
│ └── Determinar escopo da revisão
├── 2. Revisão por arquivo
│ ├── Ler arquivo
│ ├── Grep para contexto relacionado
│ └── Verificar por dimensão
├── 3. Gerar relatório
│ ├── Ordenar por severidade
│ ├── Fornecer sugestões de correção concretas
│ └── Incluir exemplos de código
└── 4. Avaliação sumária
├── Pontuação geral
└── Recomendação de merge
(2) Revisão incremental vs completa
| Tipo | Escopo | Caso de uso |
|---|---|---|
| Revisão incremental | Revisar apenas partes alteradas | Revisão de PR/MR |
| Revisão completa | Revisar módulo inteiro | Revisão de código de novo membro, verificação pós-refatoração |
3. Formato do relatório de revisão
(1) Template de saída padrão
## Relatório de Revisão de Código
### 📊 Visão geral
- Arquivos revisados: 3
- Problemas encontrados: 5 (🔴 1 / 🟡 2 / 🟢 2)
- Pontuação geral: 7/10
- Recomendação: ⚠️ Merge após corrigir problemas críticos
### 🔴 Problemas críticos
**[SEC-001] Risco de injeção SQL**
📍 Localização: src/auth/login.py:42
📝 Uso de concatenação de strings para construir consulta SQL
✅ Sugestão:
```python
query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (username,))
🟡 Problemas importantes
...
🟢 Sugestões de melhoria
...
### (2) Sistema de pontuação
```text
Regras de pontuação:
- 🔴 Problema crítico: -3 cada
- 🟡 Problema importante: -1 cada
- 🟢 Sugestão: -0.5 cada
- Pontuação base: 10
- Pontuação mínima: 0
Recomendação de merge:
- ≥ 8 pontos: ✅ Recomendar merge
- 5-7 pontos: ⚠️ Merge após correções
- < 5 pontos: ❌ Não recomendar merge
4. Skill de revisão na prática
▶ Exemplo: Skill de revisão de dimensão completa
Alice criou um Skill de revisão padronizado para a equipe:
---
name: full-review
description: "Revisão de código de dimensão completa"
triggers:
- keyword: "full-review"
tools:
- Read
- Grep
- Glob
- Bash
---
## Fluxo de revisão
1. Glob para determinar o escopo de arquivos a revisar
2. Para cada arquivo, verificar por dimensão:
- Segurança: Grep para padrões perigosos
- Desempenho: Read para analisar complexidade algorítmica
- Legibilidade: Verificar nomenclatura e estrutura
- Testes: Confirmar cobertura de testes
3. Agregar e exibir relatório de revisão
Bob comentou: "Relatórios padronizados tornam os resultados da revisão claros à primeira vista — sinal vermelho deve corrigir, sinal amarelo verificar a situação, sinal verde é bônus."
❓ Perguntas Frequentes
P: Revisões excessivamente rigorosas atrasam o desenvolvimento? R: Sim. Recomendamos dois níveis — revisão de PR verifica apenas segurança e lógica-chave; revisões completas periódicas cobrem todas as dimensões. P: A revisão por IA pode substituir a revisão humana? R: Não completamente. A IA é excelente em correspondência de padrões e varredura de segurança; humanos são excelentes em revisão de arquitetura e julgamento de lógica de negócio. Os dois se complementam melhor. P: Como evitar que relatórios de revisão fiquem muito longos? R: Configure filtro de severidade; por padrão, exiba apenas problemas 🟡 e acima. Sugestões 🟢 são saída opcional.
📖 Resumo
- Cinco dimensões de revisão: segurança, desempenho, legibilidade, melhores práticas, cobertura de testes
- Fluxo padrão: coletar mudanças → revisão por arquivo → gerar relatório → avaliação sumária
- Formato do relatório: visão geral + problemas classificados + pontuação + recomendação de merge
- Sistema de pontuação: escala de 10 pontos, deduções por severidade do problema
📝 Exercícios
- Básico (dificuldade⭐): Crie um Skill de revisão de segurança que verifique apenas injeção SQL, XSS e chaves hardcoded.
- Intermediário (dificuldade⭐⭐): Crie um Skill de revisão de dimensão completa que exiba um relatório de revisão padrão com pontuação e recomendação de merge.
- Avançado (dificuldade⭐⭐⭐): Crie um Skill de revisão incremental que revise apenas as mudanças no git diff e ajuste automaticamente as dimensões de revisão por linguagem.