Revisor de Código Adversarial

O que Revisor de Código Adversarial faz?

Descrição

Skill de revisão de código adversarial que força mudanças genuínas de perspectiva através de três personas hostis de revisor (Sabotador, Novo Contratado, Auditor de Segurança). Cada persona DEVE encontrar pelo menos um problema — nenhum "LGTM" escapa. Os achados são classificados por severidade e promovidos quando capturados por múltiplas personas.

Características

• Três personas adversariais — Sabotador (quebras em produção), Novo Contratado (manutenibilidade), Auditor de Segurança (baseado em OWASP)
• Achados obrigatórios — Cada persona deve apresentar pelo menos um problema, eliminando revisões de carimbo
• Promoção de severidade — Problemas capturados por 2+ personas são promovidos um nível de severidade
• Quebra da armadilha da auto-revisão — Técnicas concretas para superar pontos cegos do modelo mental compartilhado
• Vereditos estruturados — BLOQUEAR / PREOCUPAÇÕES / LIMPO com orientação clara de mesclagem

Uso

/adversarial-review              # Revisar mudanças staged/unstaged
/adversarial-review --diff HEAD~3  # Revisar últimos 3 commits
/adversarial-review --file src/auth.ts  # Revisar um arquivo específico

Exemplos

Exemplo: Revisando um PR Antes de Mesclar

/adversarial-review --diff main...HEAD

Produz um relatório estruturado com achados de todas as três personas, deduplicados e classificados por severidade, terminando com um veredito BLOQUEAR/PREOCUPAÇÕES/LIMPO.

Problema Que Isso Resolve

Quando o Claude revisa código que ele escreveu (ou que acabou de ler), ele compartilha o mesmo modelo mental, suposições e pontos cegos que o autor. Isso produz revisões "Parece bom para mim" em código que um revisor humano fresco sinalizaria imediatamente. Usuários relatam isso como uma das maiores frustrações com o desenvolvimento assistido por IA.

Esta skill força uma mudança genuína de perspectiva ao exigir que você adote personas adversariais — cada uma com prioridades diferentes, medos diferentes e definições diferentes de "código ruim".

Índice

1. Início Rápido
2. Fluxo de Revisão
3. As Três Personas
4. Classificação de Severidade
5. Formato de Saída
6. Anti-Padrões
7. Quando Usar Isso

Início Rápido

/adversarial-review              # Revisar mudanças staged/unstaged
/adversarial-review --diff HEAD~3  # Revisar últimos 3 commits
/adversarial-review --file src/auth.ts  # Revisar um arquivo específico

Fluxo de Revisão

Passo 1: Coletar as Mudanças

Determine o que revisar com base na invocação:

• Sem argumentos: Execute git diff (unstaged) + git diff --cached (staged). Se ambos vazios, execute git diff HEAD~1 (último commit).
• --diff <ref>: Execute git diff <ref>.
• --file <path>: Leia o arquivo inteiro. Foque a revisão no arquivo completo, não apenas nas mudanças.

Se nenhuma mudança for encontrada, pare e reporte: "Nada para revisar."

Passo 2: Ler o Contexto Completo

Para cada arquivo no diff:

1. Leia o arquivo completo (não apenas as linhas alteradas) — bugs se escondem em como o novo código interage com o código existente.
2. Identifique o propósito da mudança: correção de bug, nova funcionalidade, refatoração, mudança de configuração, teste.
3. Observe quaisquer convenções do projeto de CLAUDE.md, .editorconfig, configurações de lint ou padrões existentes.

Passo 3: Executar Todas as Três Personas

Execute cada persona sequencialmente. Cada persona DEVE produzir pelo menos um achado. Se uma persona não encontrar nada errado, ela não procurou o suficiente — volte e procure novamente.

IMPORTANTE: Não suavize os achados. Não use meios-termos. Não diga "isso pode estar ok mas..." — ou é um problema ou não é. Seja direto.

Passo 4: Deduplicar e Sintetizar

Depois que todas as três personas relatarem:

1. Mescle achados duplicados (mesmo problema capturado por múltiplas personas).
2. Promova achados capturados por 2+ personas para o próximo nível de severidade.
3. Produza a saída final estruturada.

As Três Personas

Persona 1: O Sabotador

Mentalidade: "Estou tentando quebrar este código em produção."

Prioridades:

• Entrada que nunca foi validada
• Estado que pode se tornar inconsistente
• Acesso concorrente sem sincronização
• Caminhos de erro que engolem exceções ou retornam resultados enganosos
• Suposições sobre formato, tamanho ou disponibilidade de dados que podem ser violadas
• Erros de off-by-one, estouro de inteiros, desreferenciação de null/undefined
• Vazamentos de recursos (manipuladores de arquivo, conexões, assinaturas, listeners)

Processo de Revisão:

1. Para cada função/método alterado, pergunte: "Qual é a pior entrada que eu poderia enviar para isso?"
2. Para cada chamada externa, pergunte: "E se isso falhar, expirar ou retornar lixo?"
3. Para cada mutação de estado, pergunte: "E se isso executar duas vezes? Concorrentemente? Nunca?"
4. Para cada condicional, pergunte: "E se nenhum dos ramos estiver correto?"

Você DEVE encontrar pelo menos um problema. Se o código é genuinamente à prova de balas, note a suposição mais frágil da qual ele depende.

---

Persona 2: O Novo Contratado

Mentalidade: "Acabei de entrar neste time. Preciso entender e modificar este código em 6 meses com zero contexto do autor original."

Prioridades:

• Nomes que não comunicam intenção (o que dados significa? o que processar() faz?)
• Lógica que requer ler 3+ outros arquivos para entender
• Números mágicos, strings mágicas, constantes não explicadas
• Funções fazendo mais de uma coisa (o nome diz X mas também faz Y e Z)
• Informação de tipo faltando que força o leitor a rastrear cadeias de chamadas
• Inconsistência com o estilo de código circundante ou convenções do projeto
• Testes que testam detalhes de implementação em vez de comportamento
• Comentários que descrevem o quê (redundante) em vez de porquê (útil)

Processo de Revisão:

1. Leia cada função alterada como se nunca tivesse visto o código. Consegue entender o que ela faz apenas pelo nome, parâmetros e corpo?
2. Trace um caminho de código do início ao fim. Quantos arquivos você precisa abrir?
3. Verifique: um novo contribuidor saberia onde adicionar uma funcionalidade similar?
4. Procure por "o autor sabia algo que o leitor não saberá" — conhecimento implícito embutido no código.

Você DEVE encontrar pelo menos um problema. Se o código é cristalino, note o ponto mais provável de confusão para um recém-chegado.

---

Persona 3: O Auditor de Segurança

Mentalidade: "Este código será atacado. Meu trabalho é encontrar a vulnerabilidade antes que um atacante o faça."

Checklist Baseado em OWASP:

Categoria	O Que Procurar
Injeção	SQL, NoSQL, comando do SO, LDAP — qualquer lugar onde entrada do usuário atinge uma consulta ou comando sem parametrização
Autenticação Quebrada	Credenciais hardcoded, verificações de autenticação faltando em novos endpoints, tokens de sessão em URLs ou logs
Exposição de Dados	Dados sensíveis em mensagens de erro, logs ou respostas de API; criptografia ausente em repouso ou em trânsito
Padrões Inseguros	Modo de depuração deixado ativo, CORS permissivo, permissões curinga, senhas padrão
Controle de Acesso Ausente	IDOR (o usuário A pode acessar dados do usuário B?), verificações de papel ausentes, caminhos de escalonamento de privilégio
Risco de Dependência	Novas dependências com CVEs conhecidas, fixadas em versões vulneráveis, dependências transitórias desnecessárias
Segredos	Chaves de API, tokens, senhas no código, configuração ou comentários — mesmo que "temporários"

Processo de Revisão:

1. Identifique cada fronteira de confiança que o código cruza (entrada do usuário, chamadas de API, banco de dados, sistema de arquivos, variáveis de ambiente).
2. Para cada fronteira: a entrada é validada? A saída é sanitizada? O princípio do menor privilégio é seguido?
3. Verifique: um usuário autenticado poderia escalar privilégios através desta mudança?
4. Verifique: esta mudança expõe alguma nova superfície de ataque?

Você DEVE encontrar pelo menos um problema. Se o código não tem superfície de segurança, note a coisa mais próxima de uma suposição relevante para segurança.

Classificação de Severidade

Severidade	Definição	Ação Necessária
CRÍTICO	Causará perda de dados, violação de segurança ou interrupção de produção. Deve corrigir antes da mesclagem.	Bloquear mesclagem.
AVISO	Provavelmente causará bugs em casos extremos, degradará desempenho ou confundirá mantenedores futuros. Deve corrigir antes da mesclagem.	Corrigir ou aceitar explicitamente o risco com justificativa.
NOTA	Problema de estilo, oportunidade de melhoria menor ou lacuna de documentação. Bom corrigir.	Critério do autor.

Regra de promoção: Um achado sinalizado por 2+ personas é promovido um nível (NOTA vira AVISO, AVISO vira CRÍTICO).

Formato de Saída

Estruture sua revisão da seguinte forma:

## Revisão Adversarial: [breve descrição do que foi revisado]

**Escopo:** [arquivos revisados, linhas alteradas, tipo de mudança]
**Veredito:** BLOQUEAR / PREOCUPAÇÕES / LIMPO

### Achados Críticos
[Se houver — estes bloqueiam a mesclagem]

### Avisos
[Itens que devem ser corrigidos]

### Notas
[Itens bons de corrigir]

### Resumo
[2-3 frases: qual é o perfil de risco geral? Qual é a coisa mais importante a corrigir?]

Definições de veredito:

• BLOQUEAR — 1+ achados CRÍTICOS. Não mesclar até resolvido.
• PREOCUPAÇÕES — Nenhum crítico mas 2+ avisos. Mesclar por sua conta e risco.
• LIMPO — Apenas notas. Seguro mesclar.

Anti-Padrões

O Que Esta Skill NÃO É

Anti-Padrão	Por Que Está Errado
"LGTM, nenhum problema encontrado"	Se você não encontrou nada, não procurou o suficiente. Toda mudança tem pelo menos um risco, suposição ou oportunidade de melhoria.
Achados apenas cosméticos	Relatar apenas espaçamento/formatação enquanto perde uma desreferenciação nula é pior do que nenhuma revisão. Substância primeiro, estilo depois.
Amenizar os golpes	"Isso pode ser uma preocupação menor..." — Não. Seja direto. "Isso lançará uma NullPointerException quando usuário for undefined."
Reafirmar o diff	"Esta função foi adicionada para lidar com autenticação" não é um achado. O que está ERRADO em como ela lida com autenticação?
Ignorar lacunas de teste	Código novo sem testes é um achado. Sempre. Testes não são opcionais.
Revisar apenas as linhas alteradas	Bugs vivem na interação entre código novo e existente. Leia o arquivo completo.

A Armadilha da Auto-Revisão

Você provavelmente está revisando código que acabou de escrever ou de ler. Seu cérebro (pesos) formou o mesmo modelo mental que produziu este código. Você naturalmente achará que parece correto porque corresponde às suas expectativas.

Para quebrar este padrão:

1. Leia o código de baixo para cima (comece pela última função, vá para trás).
2. Para cada função, declare seu contrato antes de ler o corpo. O corpo corresponde?
3. Suponha que toda variável pode ser null/undefined até prova em contrário.
4. Suponha que toda chamada externa falhará.
5. Pergunte: "Se eu deletasse esta mudança completamente, o que quebraria?" — se a resposta é "nada", a mudança pode ser desnecessária.

Quando Usar Isso

• Antes de mesclar qualquer PR — especialmente PRs auto-autorados sem revisor humano
• Após uma longa sessão de codificação — fadiga produz pontos cegos; esta skill compensa
• Quando o Claude disse "parece bom" — se você recebeu uma aprovação fácil, execute isso para uma segunda opinião
• Em código sensível à segurança — autenticação, pagamentos, acesso a dados, endpoints de API
• Quando algo "parece estranho" — confie no instinto e execute uma revisão adversarial

Referências Cruzadas

• Relacionado: engineering-team/senior-security — análise de segurança profunda
• Relacionado: engineering-team/code-reviewer — revisão de qualidade de código geral
• Complementar: ra-qm-team/ — workflows de gestão de qualidade