Skill para Remover "Slop" de IA

Entradas

• Escopo Padrão: diff de branch vs merge-base main (sem argumentos necessários)
• Escopo Opcional: lista explícita de arquivos passada pelo chamador (ex: conjunto de arquivos alterados de um workflow Ralph)

O que esta skill faz

Limpa "slop" (conteúdo desnecessário ou de baixa qualidade) gerado por IA de um conjunto delimitado de arquivos alterados, preservando estritamente o comportamento. Bloqueia o comportamento com testes de regressão primeiro, depois executa uma limpeza categorizada em várias passagens, e então verifica com "quality gates" (portões de qualidade) e uma revisão crítica. Reverte e edita diretamente quando a verificação falha.

O invariante de segurança principal: o comportamento é bloqueado por testes verdes antes que uma única linha seja removida. Um checklist por si só não é segurança; um teste de regressão que passa é.

Categorias (o que conta como "slop")

O agente procura por estas nove categorias. As três primeiras são estilísticas, as três seguintes são estruturais, as duas seguintes tratam de custo oculto, e a última é sobre cobertura de comportamento.

Estilísticas

1. Comentários óbvios — comentários que repetem o código, docstrings triviais, divisores de seção, código comentado, TODOs/Notas vagas.

   • MANTER: comentários explicando o PORQUÊ (lógica de negócio, casos extremos, soluções alternativas), links de tickets, explicações de regex/algoritmos.
   • MANTER: marcadores BDD (# given, # when, # then, # when/then).

2. Código excessivamente defensivo — verificações de nulo para valores garantidos, try/except em torno de código que não pode gerar exceção, verificações isinstance para parâmetros tipados estaticamente, valores padrão para parâmetros obrigatórios, "shims" de compatibilidade retroativa, validação redundante duplicada em várias camadas, captura ampla de exceções (except Exception/except BaseException em Python, catch {} vazio ou catch (e) { console.error(e) } sem estreitamento em TypeScript/JavaScript).

   • MANTER: validação nas fronteiras do sistema (entrada do usuário, APIs externas), tratamento de erros de I/O, campos de banco de dados anuláveis. Um "catch-all" de nível superior na fronteira (CLI main(), manipulador HTTP) com log explícito + re-raise é aceitável.
   • REFAZER: except Exception → capturar a exceção específica que você espera. catch {} vazio → adicionar estreitamento instanceof ou re-lançar. catch (e) { log(e) } → estreitar com instanceof, tratar casos conhecidos, re-lançar desconhecidos.
   • PROVA REQUERIDA: antes de excluir qualquer validação ou tratamento de erro em um limite de confiança, a Fase 2 deve incluir uma regressão adversária (entrada malformada ou hostil) que falhe se a proteção for removida. Sem teste adversário → a proteção permanece. Defesa redundante a ser removida é uma duplicata de uma verificação que já roda dentro do limite; uma proteção sem prova de redundância está carregando peso.

3. Complexidade excessiva — aninhamento profundo (>3 níveis), ternários aninhados, expressões booleanas complexas (combinar 4+ predicados), listas longas de parâmetros (>5 argumentos sem uma struct/dataclass/objeto), funções "god" (>50 linhas fazendo muitas coisas), "one-liners" excessivamente inteligentes que sacrificam a legibilidade, cadeias if/elif/else para discriminação de tipo/enum/literal (deve ser match/case + assert_never), object usado como anotação de tipo (deve ser Protocol, TypeVar, ou união explícita).

   • MANTER: padrões de complexidade estabelecidos neste codebase, caminhos de hot performance que intencionalmente usam um idioma complexo. if/else para condições booleanas e verificações de intervalo (não discriminação de variantes).
   • REFAZER: cadeias if aninhadas → "guard clauses" / retornos antecipados. Ternários complexos → if/else explícito. Cadeias if/elif isinstance/enum → match/case com assert_never no "wildcard". Anotações object → Protocol (estrutural), TypeVar (genérico), ou união (variantes conhecidas).

Estruturais

4. Abstração desnecessária — wrappers "pass-through", helpers de uso único, indireção especulativa ("podemos precisar disso mais tarde"), interfaces com um único implementador onde a interface não adiciona ganho de testabilidade, funções de fábrica que apenas chamam um construtor.

   • MANTER: abstrações que fornecem uma "costura" real (testabilidade, múltiplos implementadores, limites exigidos pelo framework).

5. Violações de limites — importações de camada errada (UI importando driver de banco de dados), responsabilidades "vazadas" (manipulador fazendo lógica de negócio que pertence a um serviço), acoplamento oculto (módulo A lendo estado privado do módulo B), efeitos colaterais em funções com nomes "puros".

   • MANTER: atalhos pragmáticos já estabelecidos como padrão neste codebase. Sinalizar para julgamento humano se incerto.

6. Código morto — imports não utilizados, funções/métodos privados não utilizados, branches inalcançáveis, flags de funcionalidade desatualizadas, sobras de depuração (console.log, print(...), dbg!), código removido mas ainda referenciado.

…