Simplificar Código

Revise o código alterado em busca de problemas de reutilização, qualidade, eficiência e clareza. Use sub-agentes do Codex para revisar em paralelo e, opcionalmente, aplique apenas correções de alta confiança que preservem o comportamento.

Quando Usar

• Quando o usuário pede para simplificar, limpar, refatorar ou revisar código alterado.
• Quando você deseja melhorias de alta confiança e que preservem o comportamento em um diff com escopo definido.

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, apenas 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 preparado (unstaged): git diff
• trabalho preparado (staged): git diff --cached
• comparação de branch ou commit solicitada explicitamente pelo usuário: use esse alvo de diff exato
• trabalho misto preparado e não preparado: revise ambos

Não presuma 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 afetada. 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 afetado

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

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

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

Ao iniciar 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
• peça apenas resultados concisos e estruturados
• peça a cada sub-agente para relatar arquivo, linha ou símbolo, problema, correção recomendada e confiança

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.

Função de sub-agente recomendada: explorer para consulta ampla da base de código, 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. Expansã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

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
3. Novo trabalho adicionado à inicialização, renderização, solicitação ou outros caminhos críticos sem necessidade clara
4. Pré-verificações de existência quando a própria operação pode ser tentada diretamente e os erros tratados
5. Crescimento de memória, limpeza ausente ou vazamentos de listener/assinatura
6. Leituras ou varreduras excessivamente amplas quando o código precisa apenas de um subconjunto

Função de sub-agente recomendada: reviewer

Sub-Agente 4: Revisão de Clareza e Padrões

Revise as mesmas alterações em busca de clareza, padrões locais e equilíbrio:

1. Violações de convenções de projeto locais ou padrões de módulo
2. Complexidade desnecessária, aninhamento profundo, nomes fracos ou comentários redundantes
3. Código excessivamente compacto ou inteligente que reduz a legibilidade
4. Simplificação excessiva que colapsa preocupações separadas em uma unidade pouco clara
5. Código morto, abstrações mortas ou indireção sem valor

…