Revisão de Código Aberta

Esta habilidade do plugin Codex espelha intencionalmente a habilidade canônica em skills/open-code-review/SKILL.md. Mantenha ambos os arquivos sincronizados ao atualizar as instruções do agente OCR; um link simbólico é evitado porque as instalações de plugins podem materializar apenas a subárvore do plugin.

Uma habilidade para invocar open-code-review (ocr) — uma CLI de revisão de código AI de código aberto que lê diffs do Git e gera comentários de revisão estruturados, linha por linha.

Fluxo de Trabalho

Etapa 1: Coletar Contexto de Negócios

Analise o alvo da revisão (commits, branch ou alterações) para extrair um contexto de negócios conciso. Passe este contexto via --background para melhorar a qualidade da revisão.

Etapa 2: Executar Revisão de Código

Não verifique previamente se ocr está instalado — pule sondagens como command -v ocr ou ocr --version. Assuma que a CLI está disponível e execute a revisão diretamente; isso economiza uma chamada de ferramenta no caminho comum. Somente se a revisão falhar com command not found você deverá instalá-la conforme Solução de Problemas.

Execute o comando OCR com os sinalizadores apropriados. Sempre passe o contexto de negócios via --background quando disponível:

ocr review --audience agent --background "business context here" [user-args]

Manipulação de argumentos:

• Contexto de fundo (RECOMENDADO): use --background "context" ou -b "context" para fornecer contexto de negócios para melhor qualidade de revisão
• Padrão (sem argumentos do usuário): revisa alterações preparadas, não preparadas e não rastreadas (modo de espaço de trabalho)
• Commit específico: use --commit ou -c para revisar um único commit em relação ao seu pai
• Comparação de branches: use --from <ref> e --to <ref> para revisar o diff entre dois refs
• Tempo limite: tempo limite efetivo por grupo de revisão = --timeout × rodadas de revisão. O padrão --timeout 15 com esforço padrão medium (2 rodadas) resulta em 30 minutos; low/high resultam em 15/45 minutos.
• Concorrência: a concorrência padrão é de 8 workers de arquivo; reduza com --concurrency <n> se os limites de taxa forem atingidos
• Modo de visualização: use --preview ou -p para visualizar quais arquivos serão revisados sem executar o LLM
• Arquivo de saída: use --output <path> para gravar o resultado completo em um arquivo em vez de stdout. Se o comando falhar com unknown flag: --output, não continue a revisão com stdout simples. Pergunte ao usuário se deseja atualizar (npm i -g @alibaba-group/open-code-review@latest) e aguarde a resposta antes de prosseguir. Após a confirmação do usuário e o sucesso da atualização, execute novamente com --output.
• Instalação: se o comando ocr não for encontrado, instale-o executando npm i -g @alibaba-group/open-code-review

Padrões comuns de invocação:

Modo de saída:

• Sempre use --audience agent para suprimir a interface do usuário de progresso e emitir apenas o resumo final
• Evitar truncamento de saída: Para revisões grandes ou ambientes de ferramentas restritos, passe --output /tmp/ocr_out.txt e inspecione o arquivo na íntegra por meio de uma ferramenta de leitura de arquivos em vez de canalizar stdout através de tail ou head, que descartam comentários de revisão anteriores.

Em caso de falha: Se ocr review sair com um código diferente de zero (por exemplo, um erro de conexão LLM), não tente novamente cegamente — consulte a seção Solução de Problemas abaixo para a correção correspondente antes de executar novamente.

Etapa 3: Relatar

A saída do OCR inclui severity estruturados (crítico / alto / médio / baixo) e category (bug / segurança / desempenho / manutenibilidade / teste / estilo / documentação / outro) em cada comentário. Apresente os resultados agrupados por gravidade, descartando itens de gravidade low que provavelmente são falsos positivos ou detalhes triviais.

Etapa 4: Corrigir

Antes de aplicar correções, verifique se o usuário solicitou correções automáticas:

• Se o usuário solicitou explicitamente "revisar e corrigir" ou similar, prossiga com as correções automáticas
• Se o usuário apenas solicitou "revisar" sem intenção de correção, peça permissão antes de aplicar quaisquer alterações

Ao corrigir problemas e sugestões:

• Concentre-se em itens de gravidade crítica, alta e média
• Aplique correções diretamente no código quando for seguro e bem definido
• Para correções complexas que exigem intervenção manual, descreva claramente o que precisa ser feito

…