# Agentes e skills para revisão de código

Rever diffs, apanhar bugs antes do merge e reduzir dívida técnica.

Revisão de código é o momento em que alguém, ou alguma coisa, olha para uma alteração antes de ela entrar no ramo principal. Num projeto pequeno resolve-se com uma leitura rápida do diff. O problema aparece quando o repositório cresce, quando várias pessoas mexem nos mesmos ficheiros e quando parte do código passa a ser escrita por assistentes: o volume de alterações sobe e a atenção humana não acompanha.

Os componentes desta página dão ao Claude Code um papel definido nesse momento. Um agente lê o diff e devolve problemas com ficheiro e linha, outro procura apenas falhas de segurança, outro verifica se os testes cobrem mesmo o caminho novo. Há skills que publicam comentários em linha no pull request e automações que correm o linter a cada edição de ficheiro, antes de existir sequer uma revisão.

Comece pelo revisor de uso geral e pela automação de linting, que cobrem a maior parte dos casos com pouca configuração. Só depois acrescente revisores especializados, e apenas os que correspondem a riscos reais do seu projeto: segurança, arquitetura, contratos de API, cobertura de testes. Para código antigo, os agentes de refatoração e de dívida técnica são um caminho diferente, mais lento e mais deliberado.


## Rever alterações antes de entrarem no ramo principal

Revisores que trabalham sobre um diff ou sobre um pull request. Cobrem o momento em que o código está pronto mas ainda não foi integrado.

- **code-reviewer** (Agentes): Bom ponto de partida para quem ainda não tem nenhum revisor configurado: analisa as alterações submetidas num pull request e classifica problemas de qualidade, segurança e boas práticas. [ficha](https://doutorai.pt/componentes/agents__code-reviewer)
- **review-local-changes** (Skills): Para trabalho que ainda não saiu da sua máquina: lê o git diff e os ficheiros por seguir, devolvendo sugestões antes de existir sequer um commit. [ficha](https://doutorai.pt/componentes/skills__neolab-context-engineering-kit__review-local-changes)
- **review-pr** (Skills): Quando a alteração já está num pull request do GitHub, publica os comentários diretamente nas linhas do diff através do gh, em vez de os deixar no terminal. [ficha](https://doutorai.pt/componentes/skills__neolab-context-engineering-kit__review-pr)
- **bug-hunter** (Agentes): Concentra-se apenas em bugs e problemas críticos, com análise de causa raiz. Ajuda quando a revisão genérica devolve muitas notas de estilo e pouca substância. [ficha](https://doutorai.pt/componentes/agents__neolab-context-engineering-kit__agents-bug-hunter)
- **adversarial-reviewer** (Skills): Serve para quando desconfia que o modelo está a concordar demasiado com o código que acabou de escrever: usa personas de revisor hostis para expor pontos cegos partilhados com o autor. [ficha](https://doutorai.pt/componentes/skills__alirezarezvani-claude-skills__adversarial-reviewer)
- **reviewer** (Agentes): Segunda opinião gerada por um modelo de outra família, em modo apenas de leitura. Faz sentido em diffs contestados ou em alterações sensíveis, onde vale a pena ter dois pareceres. [ficha](https://doutorai.pt/componentes/agents__davepoon-subagents__agents-reviewer)

## Revisões por ângulo especializado

Cada um destes revisores olha só para uma dimensão do código. Use-os quando a revisão genérica não chega, ou em paralelo num projeto com riscos concretos.

- **architect-reviewer** (Agentes): Olha para a alteração do ponto de vista da estrutura: camadas, princípios SOLID e coerência com os padrões existentes. Indicado para pull requests que mexem na organização do código. [ficha](https://doutorai.pt/componentes/agents__architect-reviewer)
- **se-security-reviewer** (Agentes): Quando o diff toca em autenticação, entradas de utilizador ou dados sensíveis, aplica OWASP Top 10 e critérios de segurança empresarial em vez de comentários genéricos. [ficha](https://doutorai.pt/componentes/agents__se-security-reviewer)
- **test-coverage-reviewer** (Agentes): Verifica se os testes que acompanham a alteração cobrem mesmo a funcionalidade nova e os casos-limite, em vez de apenas fazerem subir a percentagem de cobertura. [ficha](https://doutorai.pt/componentes/agents__neolab-context-engineering-kit__agents-test-coverage-reviewer)
- **contracts-reviewer** (Agentes): Vocacionado para alterações a APIs públicas, modelos de dados, esquemas de base de dados e definições de tipos, onde um erro de desenho fica caro de reverter mais tarde. [ficha](https://doutorai.pt/componentes/agents__neolab-context-engineering-kit__agents-contracts-reviewer)
- **multi-reviewer-patterns** (Skills): Se puser vários revisores a correr em paralelo, trata da parte aborrecida: remove achados duplicados, calibra a severidade e junta tudo num relatório único. [ficha](https://doutorai.pt/componentes/skills__wshobson-agents__multi-reviewer-patterns)

## Refatorar e reduzir dívida técnica

Aqui o objetivo não é aprovar ou rejeitar uma alteração, é melhorar código que já existe sem mudar aquilo que ele faz.

- **refactoring-specialist** (Agentes): Pensado para código que ninguém quer tocar: métodos enormes, lógica duplicada, estrutura confusa. Reescreve preservando o comportamento existente. [ficha](https://doutorai.pt/componentes/agents__refactoring-specialist)
- **code-simplifier** (Agentes): Trabalha sobre o código alterado recentemente e reduz complexidade sem mudar funcionalidade. Encaixa bem como passo seguinte a uma revisão que apontou muita coisa pouco clara. [ficha](https://doutorai.pt/componentes/agents__code-simplifier)
- **technical-debt-manager** (Agentes): Para quem tem de decidir o que entra no próximo sprint: avalia a saúde do código e propõe uma ordem de refatoração, em vez de tratar a dívida como uma lista infinita. [ficha](https://doutorai.pt/componentes/agents__technical-debt-manager)
- **unused-code-cleaner** (Agentes): Depois de remover uma funcionalidade fica sempre resto: imports, funções e classes que já ninguém chama. Deteta-os em várias linguagens e remove-os com verificações de segurança. [ficha](https://doutorai.pt/componentes/agents__unused-code-cleaner)
- **deslop** (Skills): Feito para ramos escritos com ajuda de IA: compara com o ramo principal e retira comentários a mais, verificações defensivas desnecessárias e conversões de tipo para any. [ficha](https://doutorai.pt/componentes/skills__deslop)

## Tornar a revisão parte da rotina

Automações, comandos e conetores que fazem o trabalho repetitivo acontecer sem ninguém se lembrar dele.

- **lint-on-save** (Automações): Corre ESLint, Pylint ou RuboCop logo a seguir a cada edição de ficheiro, por isso os erros de formatação e de estilo nunca chegam à revisão propriamente dita. [ficha](https://doutorai.pt/componentes/hooks__lint-on-save)
- **setup-linting** (Comandos): Trata da configuração inicial das ferramentas de análise estática num projeto que ainda não tem nenhuma, com deteção de linguagem e aplicação automática das regras. [ficha](https://doutorai.pt/componentes/commands__setup-linting)
- **code-review-checklist** (Skills): Uma lista de verificação para equipas que querem o mesmo critério em todas as revisões, com secções para funcionalidade, segurança, desempenho e manutenção. [ficha](https://doutorai.pt/componentes/skills__code-review-checklist)
- **receiving-code-review** (Skills): O outro lado da mesa: como avaliar comentários de revisão que parecem discutíveis, verificando antes de implementar em vez de aceitar tudo por deferência. [ficha](https://doutorai.pt/componentes/skills__receiving-code-review)
- **codacy** (Conetores): Conetor para a API do Codacy, que dá ao Claude Code acesso aos relatórios de qualidade, cobertura e segurança que a plataforma já recolheu sobre o repositório. [ficha](https://doutorai.pt/componentes/mcps__codacy)

## Como instalar cada tipo de componente

Os agentes são ficheiros markdown que coloca em .claude/agents/ dentro do projeto, ou em ~/.claude/agents/ se os quiser em todos os repositórios. As skills seguem a mesma lógica em .claude/skills/ e são ativadas pela intenção do pedido, sem precisar de um comando. Os comandos ficam em .claude/commands/ e passam a estar disponíveis com barra. As automações vivem no ficheiro settings.json, na secção hooks, e correm sozinhas depois de cada edição. Os conetores MCP acrescentam-se à configuração de servidores MCP e pedem normalmente um token da plataforma. Depois de copiar qualquer um destes ficheiros, reinicie a sessão para que o Claude Code o reconheça.

## Combinar vários revisores sem gerar ruído

O erro mais comum é instalar seis revisores e passar a receber relatórios de cem linhas que ninguém lê. Uma sequência que funciona: linting automático a cada gravação, revisor de uso geral sobre as alterações locais antes do commit, e só depois um ou dois revisores especializados escolhidos pelo que a alteração toca. Se o diff mexe em autenticação, chame o revisor de segurança. Se altera esquemas ou tipos públicos, chame o revisor de contratos. Quando correr mais do que dois em paralelo, use uma skill de consolidação para juntar achados repetidos e uniformizar a severidade, senão o mesmo problema aparece descrito de três maneiras diferentes.

## O que estas revisões não resolvem

Um revisor automático lê o que está no diff. Não sabe o que o cliente pediu, nem porque é que aquela função defensiva foi escrita há dois anos, nem se a funcionalidade faz sentido para o negócio. Tende também a produzir achados de baixo valor quando não lhe dá contexto suficiente do projeto, e a concordar com código que o próprio modelo escreveu, que é precisamente o motivo pelo qual existem revisores adversariais e de segunda opinião. Trate os relatórios como uma primeira passagem que apanha o óbvio e liberta atenção humana para as decisões que exigem contexto: desenho, prioridades e risco real.

## Perguntas frequentes

### Qual é a diferença entre um agente e uma skill de revisão?

Um agente corre numa sessão própria, com o seu contexto separado, e devolve um relatório no fim. É útil para revisões longas que não devem poluir a conversa principal. Uma skill carrega instruções na sessão atual quando o pedido corresponde à sua descrição, e é mais indicada para procedimentos curtos, como aplicar uma lista de verificação ou publicar comentários num pull request.

### Preciso de instalar todos estes componentes no mesmo projeto?

Não, e provavelmente não deve. Dois ou três chegam para a maioria dos repositórios: um revisor de uso geral, uma automação de linting e, se o projeto tiver risco concreto nessa área, um revisor de segurança. Os restantes fazem sentido à medida que o código cresce ou quando surgir um problema que os justifique.

### Isto substitui a revisão feita por colegas de equipa?

Não substitui. Serve para chegar à revisão humana com o óbvio já tratado: formatação, imports por usar, erros de tipo, verificações em falta. O que sobra para as pessoas são as decisões que exigem contexto do produto e do histórico do projeto, que é onde a revisão humana continua a valer mais.

### Faz sentido rever código que o próprio Claude Code escreveu?

Faz, e é aí que a escolha do revisor importa. Um modelo tende a aceitar o seu próprio raciocínio, por isso vale a pena usar um revisor antagónico, ou um que corra sobre outro modelo, para uma segunda opinião. Há ainda skills dedicadas a limpar padrões típicos de código gerado, como comentários a mais e verificações defensivas desnecessárias.

### E se o repositório não estiver alojado no GitHub?

A maior parte destes componentes trabalha sobre o git diff local, por isso funciona em qualquer alojamento, incluindo servidores próprios. As exceções são as skills e conetores que publicam comentários em linha, que dependem da API do GitHub. Nesse caso pode continuar a rever localmente e colar o relatório na plataforma que utiliza.


Fonte: https://doutorai.pt/para/revisao-de-codigo - Doutor AI, selecao feita a mao da biblioteca tecnica.