Revisar e Simplificar Alterações

Quando Usar

Use esta habilidade quando precisar revisar um git diff ou um escopo de arquivo explícito para questões de reutilização, qualidade de código, eficiência, clareza e padrões, e, opcionalmente, aplicar correções seguras baseadas em Codex. Use quando o usuário pedir para "simplificar código", "revisar código alterado", "verificar reutilização de código", "revisar qualidade de código", "revisar...

Revise o código alterado em busca de questões de reutilização, qualidade, eficiência e clareza. Use sub-agentes Codex para revisar em paralelo, mas mantenha esses sub-agentes como somente leitura: eles devem apenas inspecionar o código e enviar os achados de volta para o agente principal. Somente o agente principal pode aplicar correções de alta confiança que preservem o comportamento.

Modos

Escolha o modo a partir da solicitação do usuário:

• review-only: o usuário pede para revisar, auditar ou verificar as alterações
• safe-fixes: o usuário pede para simplificar, limpar ou refatorar as alterações
• fix-and-validate: o mesmo que safe-fixes, mas também executa a menor validação relevante após as edições

Se o usuário não especificar, use como padrão:

• review-only para "revisar", "auditar" ou "verificar"
• safe-fixes para "simplificar", "limpar" ou "refatorar"

Etapa 1: Determinar o Escopo e o Comando Diff

Prefira esta ordem de escopo:

1. Arquivos ou caminhos explicitamente nomeados pelo usuário
2. Alterações atuais do git
3. Arquivos editados anteriormente na vez atual do Codex
4. Arquivos rastreados modificados mais recentemente, somente se o usuário pediu uma revisão, mas não há diff

Se não houver um escopo claro, pare e diga isso brevemente.

Ao usar alterações do git, determine o menor comando diff correto com base no estado do repositório:

• trabalho não estagiado: git diff
• trabalho estagiado: git diff --cached
• comparação de branch ou commit explicitamente solicitada pelo usuário: use esse alvo de diff exato
• trabalho misto estagiado e não estagiado: revise ambos

Não assuma que git diff HEAD é o padrão correto quando um diff menor está disponível.

Antes de revisar padrões ou aplicar correções, leia os arquivos de instrução locais do repositório e a documentação relevante do projeto para a área tocada. Prefira a orientação aplicável mais próxima, como:

• AGENTS.md
• documentação do fluxo de trabalho do repositório
• documentação de arquitetura ou estilo para o módulo tocado

Use essas instruções para distinguir problemas reais de padrões locais intencionais.

Etapa 2: Lançar Quatro Sub-Agentes de Revisão Somente Leitura em Paralelo

Use sub-agentes Codex quando o escopo for grande o suficiente para que a revisão paralela ajude. Para um diff pequeno ou um arquivo muito pequeno, é aceitável revisar localmente.

Ao gerar sub-agentes:

• dê a cada sub-agente o mesmo escopo
• diga a cada sub-agente para inspecionar apenas sua função de revisão atribuída
• diga a cada sub-agente que ele está operando em uma passagem de revisão somente leitura
• não permita que sub-agentes editem arquivos, executem apply_patch, estagiem alterações, façam commit ou realizem outras ações que modifiquem o estado
• peça apenas achados concisos e estruturados
• peça a cada sub-agente para relatar arquivo, linha ou símbolo, problema, correção recomendada e confiança
• peça a cada sub-agente para retornar os achados apenas para o agente principal; eles não devem implementar correções por si mesmos

Use quatro funções de revisão.

Sub-Agente 1: Revisão de Reutilização de Código

Revise as alterações em busca de oportunidades de reutilização:

1. Procure por helpers, utilitários ou abstrações compartilhadas existentes que já resolvam o mesmo problema.
2. Sinalize funções duplicadas ou lógica quase duplicada introduzida na alteração.
3. Sinalize lógica inline que deveria chamar um helper existente em vez de reimplementá-la.

Este sub-agente é somente leitura. Ele não deve editar arquivos, aplicar patches ou fazer quaisquer outras alterações no espaço de trabalho.

Função de sub-agente recomendada: explorer para consulta ampla do codebase, ou reviewer se uma passagem de revisão mais forte for mais útil do que uma busca ampla.

Sub-Agente 2: Revisão de Qualidade de Código

Revise as mesmas alterações em busca de problemas de qualidade de código:

1. Estado redundante, valores em cache ou valores derivados armazenados desnecessariamente
2. Propagação de parâmetros causada pelo encaminhamento de novos argumentos através de cadeias de chamadas existentes
3. Copiar e colar com pequenas variações que deveriam se tornar uma abstração compartilhada
4. Abstrações vazadas ou violações de propriedade entre limites de módulos
5. Valores "stringly-typed" onde contratos tipados, enums ou constantes existentes já existem

Este sub-agente é somente leitura. Ele não deve editar arquivos, aplicar patches ou fazer quaisquer outras alterações no espaço de trabalho.

Função de sub-agente recomendada: reviewer

Sub-Agente 3: Revisão de Eficiência

Revise as mesmas alterações em busca de problemas de eficiência:

1. Trabalho repetido, leituras duplicadas, chamadas de API duplicadas ou recálculo desnecessário
2. Trabalho sequencial que poderia ser executado concorrentemente com segurança

…