Adversarial Reviewer

Revisor de Código Adversarial

Descrição

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

Funcionalidades

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

Uso

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

Exemplos

Exemplo: Revisando um PR Antes do Merge

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

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

Problema que Esta Skill Resolve

Quando o Claude revisa código que escreveu (ou que acabou de ler), ele compartilha o mesmo modelo mental, as mesmas suposições e os mesmos pontos cegos que o autor. Isso produz revisões do tipo "Parece bom para mim" em código que um revisor humano novo sinalizaria imediatamente. Usuários relatam isso como uma das maiores frustrações no 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."

Sumário

1. Início Rápido
2. Fluxo de Trabalho 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 Esta Skill

Início Rápido

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

Fluxo de Trabalho de Revisão

Passo 1: Coletar as Mudanças

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

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

Se nenhuma mudança for encontrada, parar e reportar: "Nada para revisar."

Passo 2: Ler o Contexto Completo

Para cada arquivo no diff:

1. Ler 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. Identificar o propósito da mudança: correção de bug, nova funcionalidade, refatoração, mudança de configuração, teste.
3. Anotar quaisquer convenções do projeto do CLAUDE.md, .editorconfig, configurações de linting ou padrões existentes.

Passo 3: Executar Todas as Três Personas

Executar cada persona sequencialmente. Cada persona DEVE produzir pelo menos um resultado. Se uma persona não encontrar nada errado, ela não olhou com atenção suficiente — volte e olhe novamente.

IMPORTANTE: Não suavize os resultados. Não hesite. Não diga "isso pode estar bem, mas..." — ou é um problema ou não é. Seja direto.

Passo 4: Deduplicar e Sintetizar

Após todas as três personas terem reportado:

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

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 poderiam ser violadas
• Erros de off-by-one, overflow de inteiros, referências nulas/undefined
• Vazamentos de recursos (file handles, 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 ramo estiver correto?"

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

Persona 2: O Novo Contratado

Mentalidade: "Acabei de entrar nesta equipe. Preciso entender e modificar este código em 6 meses sem nenhum contexto do autor original."

Prioridades:

• Nomes que não comunicam intenção (o que data significa? o que process() faz?)
• Lógica que requer ler 3+ outros arquivos para entender
• Números mágicos, strings mágicas, constantes inexplicadas
• Funções fazendo mais de uma coisa (o nome diz X, mas também faz Y e Z)
• Informações de tipo ausentes que forçam o leitor a rastrear por 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 que (redundante) em vez do porquê (útil)

Processo de Revisão:

1. Ler cada função alterada como se você nunca tivesse visto o codebase. Você consegue entender o que ela faz apenas pelo nome, parâmetros e corpo?
2. Rastrear um caminho de código de ponta a ponta. Quantos arquivos você precisa abrir?
3. Verificar: um novo contribuidor saberia onde adicionar uma funcionalidade semelhante?
4. Procurar 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, anote 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."

Lista de Verificação Baseada em OWASP:

Processo de Revisão:

1. Identificar 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. Verificar: um usuário autenticado poderia escalar privilégios por meio desta mudança?
4. Verificar: 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, anote a coisa mais próxima de uma suposição relevante à segurança.

Classificação de Severidade

Regra de promoção: Um resultado sinalizado por 2+ personas é promovido um nível (NOTA torna-se AVISO, AVISO torna-se CRÍTICA).

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]
**Veredicto:** BLOQUEAR / PREOCUPAÇÕES / LIMPO

### Resultados Críticos
[Se houver — estes bloqueiam o merge]

### Avisos
[Itens a corrigir]

### Notas
[Itens bons de corrigir]

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

Definições de veredicto:

• BLOQUEAR — 1+ resultados CRÍTICOS. Não fazer merge até que seja resolvido.
• PREOCUPAÇÕES — Sem críticos, mas 2+ avisos. Merge por sua conta e risco.
• LIMPO — Apenas notas. Seguro para merge.

Anti-Padrões

O que Esta Skill NÃO É

A Armadilha da Auto-Revisão

Você provavelmente está revisando código que acabou de escrever ou ler. Seu cérebro 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. Ler o código de baixo para cima (começar pela última função, trabalhar de trás para frente).
2. Para cada função, declarar seu contrato antes de ler o corpo. O corpo corresponde?
3. Assumir que toda variável poderia ser nula/undefined até prova em contrário.
4. Assumir que toda chamada externa falhará.
5. Perguntar: "Se eu deletasse esta mudança inteiramente, o que quebraria?" — se a resposta for "nada," a mudança pode ser desnecessária.

Quando Usar Esta Skill

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

Referências Cruzadas

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