Review Duplication: investigue código repetido antes de comentar um PR

ANÁLISE EDITORIAL

Uma revisão de pull request pode apontar um trecho parecido com outro sem provar que os dois fazem a mesma coisa. A Skill Review Duplication, incluída no repositório oficial do Gemini CLI, transforma essa suspeita em uma investigação: identificar a lógica nova, procurar funções e componentes equivalentes no projeto e só então propor reaproveitamento com caminho e símbolo verificáveis. Ela não executa uma análise pronta do código e não substitui o julgamento de quem conhece a arquitetura.

O que a Skill faz

O documento oferece um roteiro de revisão de código focado em duplicação funcional. Primeiro, o agente extrai do diff os algoritmos, utilitários, estruturas de dados ou componentes de interface introduzidos. Depois, formula hipóteses sobre onde já existiria algo semelhante: diretórios de utilitários, serviços, componentes, configuração e dependências. O alvo não é a aparência textual. Dois arquivos podem ter nomes diferentes e compartilhar a mesma mecânica; outros podem parecer parecidos e cumprir contratos distintos. A Skill pede que o revisor investigue essa diferença antes de comentar o pull request.

Há duas checagens práticas no texto original. Uma é rastrear dependências já usadas no projeto, inclusive wrappers internos de bibliotecas externas. A outra é consultar o arquivo de pacotes antes de recomendar uma nova implementação de algoritmo que a aplicação talvez já tenha contratado. A etapa final só deve gerar feedback se houver uma alternativa concreta: caminho, símbolo reutilizável, indicação de integração e explicação do benefício. “Há duplicação” sem evidência localizada não atende ao padrão proposto.

Para quem serve, e para quem não serve

A Skill é útil para mantenedores e revisores de bases de código que recebem pull requests com novos helpers, componentes ou pequenas bibliotecas. Também ajuda autores que querem examinar a consistência de sua mudança antes de pedir revisão. O repositório de origem é o Gemini CLI, um monorepositório TypeScript com áreas como packages/core e packages/cli. Os caminhos citados pela Skill são hipóteses para essa estrutura. Em outro projeto, o revisor precisa substituí-los pelos diretórios reais, não presumir que uma pasta packages/core/src/utils exista.

Não é uma Skill de segurança, análise estática determinística ou correção automática. Ela tampouco estabelece que reutilizar sempre é melhor. Um utilitário antigo pode ter contrato inadequado, dependências extras, efeitos colaterais ou cobertura insuficiente. Às vezes duas implementações separadas preservam limites de domínio legítimos. A revisão deve comparar comportamento, tipos, testes, estabilidade da API e custo de acoplamento. O leitor continua responsável por aceitar ou rejeitar a sugestão, e nenhuma conclusão do agente equivale a um teste executado.

Compatibilidade e pré-requisitos

O pacote local traz um SKILL.md no formato que o Gemini CLI descobre em .gemini/skills/. A documentação oficial de gerenciamento de Skills descreve o escopo de workspace, a listagem e a ativação. Para o procedimento completo da fonte, o ambiente também precisa disponibilizar os subagentes codebase_investigator e generalist. A documentação de subagentes do Gemini CLI explica o primeiro e o isolamento de tarefas; o arquivo de referência no repositório inclui o generalist.

Também são necessários acesso ao diff que será revisado, ao código do projeto e às convenções de contribuição. Se o pull request ou o repositório forem privados, conceda só as permissões indispensáveis. Em clientes que leem SKILL.md mas não oferecem os subagentes citados, é possível estudar a lista de verificações, porém não afirmar que o fluxo original foi executado integralmente. Fixamos a cópia no commit ed96faedfd5571f055c44f2c9509d62321d1138d; confira o checkout atual antes de aplicar caminhos e comandos.

Instalação e configuração segura

Baixe o ZIP local, confirme seu SHA-256 e examine .gemini/skills/review-duplication/SKILL.md, LICENSE e ORIGEM.md. O pacote não contém o Gemini CLI nem código executável. Se você trabalha no repositório oficial que já inclui essa pasta, não instale uma segunda cópia com o mesmo nome. Use a versão do checkout e compare o arquivo do pacote apenas para auditoria. Em outro workspace com Gemini CLI, coloque a pasta da Skill no diretório de Skills do projeto reconhecido pelo cliente e use /skills list para verificar a descoberta, conforme o guia oficial.

Antes de ativar, revise quais ferramentas o agente e os subagentes podem usar. Para a primeira experiência, permita leitura do diff e dos diretórios necessários, sem edição de arquivos, execução de scripts ou postagem em pull request. Não copie tokens para o prompt. O botão do repositório oficial nesta página abre a fonte do mantenedor; o botão de download entrega uma cópia documental hospedada pelo Bastidores. Copiar a Skill não instala subagentes nem cria uma conexão com GitHub. Se o cliente pedir consentimento de ativação, confira a origem e o escopo antes de aceitar.

Primeiro uso e resultado esperado

Escolha um pull request pequeno que introduza uma função utilitária. Peça ao agente: “Leia Review Duplication, examine somente o diff e o código de suporte necessário, investigue se há função ou wrapper equivalente, cite caminhos e símbolos e separe semelhança superficial de comportamento comprovado. Não edite, execute testes nem comente o PR.” No Gemini CLI, confirme que a Skill foi descoberta e que os subagentes exigidos estão disponíveis. O agente deve formular perguntas específicas para a investigação, por exemplo, se já existe uso da mesma API, nomes parecidos ou documentação descrevendo a mesma operação.

O resultado esperado é um relatório curto que diga qual lógica nova foi analisada, onde se procurou equivalência, qual símbolo existente foi encontrado ou que a busca não achou correspondência, e que limitações ainda restam. Se houver alternativa, a sugestão deve mostrar como ela poderia ser integrada e por que isso melhora manutenção ou consistência. Uma hipótese de refatoração não é autorização para alterar o código. O revisor deve abrir os dois trechos, conferir os contratos e decidir se a reutilização é de fato apropriada. A Skill admite uma busca direta para verificações simples, mas recomenda investigação delegada para perguntas abertas e comparações de maior alcance.

Permissões, dados e riscos

A cópia hospedada é apenas documentação. A utilização real pode dar ao agente acesso a código privado, histórico de commits, mensagens de revisão e arquivos de configuração. Limite os caminhos e a duração da análise. Um subagente com mais ferramentas do que o necessário aumenta o escopo efetivo da tarefa; confira as políticas do cliente, sobretudo antes de permitir edição ou comandos de terminal. A documentação oficial de subagentes descreve controles de ferramentas e políticas, mas a configuração do seu ambiente deve ser verificada, não presumida.

O risco editorial é transformar semelhança em acusação. Uma função duplicada pode ser uma extração planejada, um contrato estável separado por domínio ou uma implementação temporária autorizada. Da mesma forma, um wrapper existente pode não cobrir tratamento de erros, acessibilidade ou performance exigidos pela mudança. Antes de pedir que alguém remova código, compare testes e usos reais. Não apresente um exemplo ilustrativo do SKILL.md como achado do repositório que está sendo revisado. Não poste comentários no GitHub sem autorização específica do responsável pelo PR.

Se algo der errado

Se a Skill não aparece na listagem, confira o nome da pasta, o frontmatter name: review-duplication, o diretório de workspace e a precedência entre Skills do usuário e do projeto. A documentação oficial indica os caminhos .gemini/skills/ e .agents/skills/ como opções de descoberta; recarregar as Skills pode ser necessário numa sessão já aberta. Se codebase_investigator ou generalist não estiverem disponíveis, informe essa limitação. A pesquisa manual dos passos simples ainda pode ajudar, mas não chame o resultado de execução completa da Skill original.

Se o agente encontra “duplicação” em toda mudança, reduza o escopo para um algoritmo ou componente do diff e peça evidência de comportamento, não apenas trechos parecidos. Se ele recomendar uma biblioteca externa, confirme no arquivo de pacotes se ela já existe e se há wrapper interno. Se o caminho citado não abre no checkout, peça o arquivo e o símbolo reais. Se a alternativa reutilizável aumentar acoplamento ou mudar comportamento, registre o contraponto. Por fim, se o projeto for sensível, faça a revisão em ambiente local autorizado e minimize o contexto enviado a serviços externos.

Revisão, licença e download local

O repositório oficial google-gemini/gemini-cli tinha 107.424 estrelas na consulta à API do GitHub em 17/10/2026. Esse número é temporal e não comprova a eficácia da Skill. O arquivo auditado é .gemini/skills/review-duplication/SKILL.md no commit ed96faedfd5571f055c44f2c9509d62321d1138d. A licença Apache-2.0 do mesmo commit permite redistribuição com os avisos preservados. Não foi encontrado arquivo NOTICE na raiz nesta revisão. Não testamos um PR real nem ativamos subagentes para esta publicação.

O ZIP local inclui somente SKILL.md original, LICENSE e ORIGEM.md com links de origem e hashes. Seu SHA-256 é 9e03129c65696b587594625c5870705d34d789b34fcdfa4c30b0963efb7b2efc. Compare esse valor depois de baixar. O pacote não inclui scripts, executáveis, binários, dependências, código do projeto, diffs, subagentes ou credenciais. A fonte pode receber mudanças depois do commit fixado, por isso uma equipe que adote a Skill deve confrontar a versão mais recente com o checkout e as regras do próprio projeto.

Fontes primárias

• SKILL.md oficial Review Duplication, commit auditado.
• Licença Apache-2.0 no commit fixado.
• Gerenciamento oficial de Agent Skills no Gemini CLI.
• Documentação oficial de subagentes.
• Contexto oficial do monorepositório Gemini CLI.