Install Anti-Slop: regras Oxlint rígidas sem apagar decisões locais

ANÁLISE EDITORIAL

Imagem editorial exclusiva do Bastidores da IA. Não é captura de tela, resultado real de lint, código do leitor, selo, certificação nem material oficial do projeto.

Linters costumam encontrar sintaxe inválida, imports problemáticos e padrões conhecidos. A Install Anti-Slop vai além e instala um conjunto opinativo de regras Oxlint que rejeita atalhos considerados fracos pelo mantenedor: afirmações de tipo sem justificativa, tipos amplos que apagam evidência, mocks de módulo, cópias custosas em reducers e outras escolhas que podem deixar TypeScript e JavaScript mais difíceis de provar.

O ponto mais importante está no nome do processo: a Skill não adiciona uma dependência pronta e imutável. Ela copia o plugin para dentro do repositório, ajusta configuração e dependências e orienta a equipe a assumir o código vendorizado. Isso permite adaptar políticas, mas também transfere manutenção, revisão e conflitos de atualização para o projeto.

O que esta Skill faz

A instrução distingue instalação nova de atualização existente. Em uma instalação nova, ela localiza o gerenciador de pacotes e a configuração Oxlint, copia o plugin para um caminho como tools/oxlint/anti-slop/, instala versões compatíveis de oxlint e @oxlint/plugins, registra o plugin, habilita as regras e executa lint e typecheck.

Em uma atualização, a referência separada manda preservar customizações locais. Ela recomenda recuperar a origem anterior, preparar o código novo fora do destino, comparar mudanças upstream e locais, decidir conflitos de política e só então promover a nova versão. O instalador recusa substituir um destino existente, o que reduz o risco de apagar ajustes silenciosamente.

Para quem serve

Serve para equipes TypeScript ou JavaScript que já tratam lint como política de engenharia e querem experimentar regras mais rígidas sobre evidência de tipos, estruturas de dados, testes e custo de operações em arrays. Também pode ajudar mantenedores que preferem revisar e possuir o código das regras em vez de depender de um pacote npm com ciclo de release externo.

Não é uma escolha neutra para qualquer projeto. O próprio README afirma que o conjunto reflete as preferências e o gosto do mantenedor, não um padrão universal. Repositórios legados, bibliotecas com APIs amplas, código que interage com dados não tipados ou equipes que usam mocks de módulo deliberadamente podem gerar muitos achados legítimos e exigir uma decisão de migração.

Origem, adoção e versão

A fonte auditada foi dmmulroy/anti-slop, com 4.550 estrelas e 103 forks consultados pela API pública do GitHub em 16/09/2026. O caminho fixado foi skills/install-anti-slop, no commit c44ef22ca116d0ba62a3ff663a0bd13a3f3fa40b.

O package.json do repositório marcava o projeto como privado, versão 0.1.0 e sem pacote npm oficial. A distribuição prevista é por código vendorizado. A Skill não declara versão semântica própria, portanto o commit é a referência reproduzível. O arquivo principal e a referência de atualização foram lidos integralmente.

Compatibilidade e pré-requisitos

O fluxo exige Node.js, o gerenciador de pacotes do projeto e uma configuração Oxlint compatível. A origem orienta usar a versão de Oxlint já resolvida no projeto e fixar @oxlint/plugins exatamente na mesma versão. Quando Oxlint ainda não existe, o agente consulta as versões atuais antes de instalar ambas.

A documentação oficial confirma que plugins JavaScript usam jsPlugins e que essa API estava em alpha na consulta. A página de JS Plugins do Oxlint também registra limites, como ausência de formatos e parsers personalizados e de regras de plugin que dependam de informação completa de tipos. Isso precisa entrar na avaliação de compatibilidade.

Instalação

A origem oferece npx skills add https://github.com/dmmulroy/anti-slop --skill install-anti-slop. O comando consulta a rede e grava a Skill. Depois, o usuário pede ao agente para instalar ou configurar Anti-Slop no repositório atual. A execução funcional pode copiar dezenas de arquivos TypeScript, instalar dependências e modificar a configuração do linter.

Não execute diretamente em uma branch importante. Crie uma branch ou cópia de teste, confirme que o diretório de destino está vazio, leia o script de instalação e revise a lista de arquivos. O download do Bastidores é somente documental e não inclui o instalador nem o plugin.

Configuração antes do primeiro uso

Defina primeiro a política que você realmente quer. A Skill habilita todas as regras genéricas como erro, inclusive a regra nativa oxc/no-accumulating-spread. Projetos que dependem diretamente de Effect podem receber um segundo grupo opt-in. Não habilite esse grupo apenas porque Effect aparece de forma transitiva no lockfile.

Revise os caminhos ignorados. A origem sugere ignorar diretórios de agentes e o próprio plugin vendorizado, preservando ignores já existentes. Ignorar todas as pastas iniciadas por ponto seria amplo demais e poderia ocultar código ou verificações que pertencem ao projeto.

Primeiro uso seguro

1. Leia as instruções do repositório e confirme que o working tree está compreendido.
2. Identifique gerenciador, versão do Oxlint, arquivo de configuração e comandos de verificação.
3. Instale em uma branch ou cópia descartável.
4. Revise o diff de código, dependências, ignores e severidades.
5. Execute lint e typecheck sem corrigir automaticamente achados sem autorização.
6. Classifique cada falha como bug provável, política discutível ou limitação da regra.
7. Decida a adoção com a equipe e registre a origem do código vendorizado.

O que as regras tentam impedir

O conjunto genérico rejeita cadeias de type assertions, parâmetros e retornos unknown em condições definidas, aliases que apenas escondem unknown, dicionários amplos, chamadas a Reflect.get e Reflect.apply, mocks de módulo e construções que alargam um valor conhecido para depois estreitá-lo por assertion.

Há regras de custo e legibilidade. no-array-filter-map aponta duas passagens adjacentes em arrays reconhecidos; no-reduce-accumulator-copy procura cópias do acumulador dentro de reducers; require-readable-spacing adiciona espaçamento em pontos específicos; e require-safety-comment-for-type-assertion exige uma justificativa perto de assertions que não sejam as const.

Essas regras não provam correção. A origem reconhece fronteiras de análise lexical, tipos importados não inferidos, aliases entre arquivos não resolvidos e chamadas indiretas que podem escapar. Um código aprovado continua precisando de testes, revisão e observabilidade.

Como fazer uma adoção gradual

Comece medindo, sem alterar o código. Rode o conjunto em uma branch de teste, exporte a lista de achados e agrupe por regra, pasta e risco. Uma regra com centenas de ocorrências pode exigir um projeto de migração; outra pode encontrar poucos pontos perigosos e entregar valor imediato. Não use a quantidade total como medida de qualidade.

Escolha um lote pequeno, escreva critérios de aceite e compare comportamento antes e depois. Para assertions, peça a evidência que torna o cast seguro. Para mocks, verifique se existe uma seam real de dependência. Para reducers e cadeias de array, confira ordem, índices, alocação e suporte do runtime. Só depois decida se a regra entra como erro, se precisa de adaptação local ou se não combina com o projeto.

Uma implantação madura inclui baseline, responsáveis e prazo. Achados antigos podem ser tratados separadamente, enquanto código novo recebe o gate completo. A decisão deve ser explícita e temporária, não um arquivo de suppressions que cresce sem revisão.

Um roteiro de validação para a equipe

Antes de propor o gate no fluxo principal, registre o estado atual em uma execução repetível. Anote versão do runtime, gerenciador, pacote, comando, diretórios analisados e duração. Guarde a saída como artefato interno da branch, sem publicar código proprietário. Essa referência permite distinguir uma mudança causada pela Skill de um problema que já existia no projeto.

Separe a avaliação em três grupos. O primeiro reúne regras objetivas que apontam construções perigosas e têm correção bem compreendida. O segundo contém escolhas de arquitetura ou legibilidade que precisam do contexto da equipe. O terceiro inclui resultados inconclusivos, limitações do parser e possíveis falsos positivos. A classificação evita que uma lista grande pareça um veredito uniforme sobre a qualidade do sistema.

Para cada regra candidata ao bloqueio, escolha exemplos reais e escreva por que o padrão é inadequado naquele repositório. Verifique se a alternativa preserva retorno, exceções, ordem, tipos e compatibilidade com o ambiente suportado. Quando o benefício depender de uma API recente, confira a versão mínima do runtime e a estratégia de transpile antes de aceitar a correção.

Depois, execute testes relevantes e compare o diff sem misturar refatoração com formatação. Uma mudança segura deve ser pequena o bastante para revisão humana, reversível e acompanhada por evidência. Se a suíte não cobre o comportamento tocado, adicione o teste ou mantenha o achado como aviso até conseguir demonstrar a equivalência.

O piloto termina com uma decisão documentada para cada grupo: ativar, adaptar, adiar ou rejeitar. Registre também a pessoa responsável, a data de revisão e a revisão upstream usada. Assim, uma futura atualização não reabre silenciosamente escolhas já discutidas e não transforma a configuração em uma coleção de exceções sem dono.

Por que vender o código muda a manutenção

Vendoring oferece controle: a equipe pode ler, modificar e fixar a revisão usada. Em troca, ela se torna responsável por acompanhar correções, compatibilidade, divergências locais e licenças de componentes incorporados. A Skill manda preservar o arquivo de licença e a procedência do trecho vendorizado de eslint-stylistic.

A atualização não deveria substituir o diretório inteiro. A referência orienta comparar o snapshot anterior, o upstream novo e a versão local, usar merge em três vias quando a base for recuperável e portar mudanças com cuidado quando não for. Regras novas não devem ser ativadas silenciosamente durante uma atualização.

Resultado esperado

O resultado correto é um diff compreensível: plugin copiado em caminho explícito, dependências compatíveis e fixadas, configuração mesclada sem apagar valores existentes, procedência registrada e verificações executadas. Falhas no código do projeto devem ser relatadas com diagnóstico, sem enfraquecer regras ou inserir casts apenas para fazer o CI passar.

Se a equipe autorizou migração, corrija achados em lotes pequenos e separados. Mudanças de espaçamento devem ficar distintas de alterações semânticas. Rode formatter, lint e typecheck novamente e confirme que uma segunda passagem não muda os arquivos.

Permissões e riscos

A instalação funcional lê o repositório, copia código, modifica configuração e dependências e executa comandos. O npx consulta a rede. O gerenciador pode rodar scripts de pacotes conforme a política do projeto. Faça isso apenas em ambiente autorizado, com revisão de lockfile e possibilidade clara de reversão.

O linter pode examinar código proprietário e exibir trechos ou caminhos em diagnósticos. Não cole saídas com segredos, tokens, credenciais, dados de cliente ou detalhes internos em serviços externos. O conjunto também pode impor preferências incompatíveis com decisões válidas da equipe; trate divergência como discussão de política, não como prova automática de defeito.

Erros comuns e como corrigir

Executar o instalador sobre uma cópia existente

Use o procedimento de atualização. Descubra a origem anterior e preserve customizações. O instalador novo deve recusar substituição em vez de usar força.

Fixar versões lembradas

Leia o lockfile ou a resolução atual do projeto. oxlint e @oxlint/plugins devem permanecer compatíveis e exatos.

Corrigir tudo mecanicamente

Algumas regras envolvem ordem de callbacks, arrays esparsos, semântica de filtro, invariantes e limites de runtime. Revise comportamento antes de trocar uma cadeia por iterator helpers ou reducer.

Tratar alpha como contrato estável

A documentação do Oxlint informa que JS Plugins permanece em alpha e ativo desenvolvimento. Fixe versões, execute testes e verifique mudanças antes de atualizar.

Desabilitar a regra para obter verde

Primeiro confirme se o achado é verdadeiro, falso positivo ou conflito de política. Registre a decisão. Desabilitar globalmente sem análise transforma o CI em decoração.

Versão, licença e pacote auditado

O repositório usa licença MIT. O pacote local contém quatro arquivos textuais: SKILL.md, references/update.md, LICENSE e ORIGEM.md. O ZIP tem 8.657 bytes e SHA-256 de0e1765d665f7bd44458ede91f4d9c28088d0d9b930e883b6d5f1492751e4c4.

Limites do pacote local

O ZIP não inclui scripts/install.mjs, plugin TypeScript, regras, cópias vendorizadas, Node.js, Oxlint, npm, pnpm, dependências, lockfiles, configuração, hooks, código do leitor, chaves, tokens ou credenciais. Ele serve para auditoria das instruções. Para uso funcional, abra o repositório oficial, confira o commit e revise todos os arquivos excluídos antes de executar qualquer comando.

Checklist antes de usar

• Confirme que a política opinativa combina com o projeto.
• Use branch ou cópia de teste e leia o working tree.
• Revise instalador, plugin, licenças e procedência.
• Fixe versões compatíveis de Oxlint e do pacote de plugins.
• Mescle configuração e ignores sem apagar valores existentes.
• Não habilite regras Effect sem dependência direta ou pedido explícito.
• Execute lint e typecheck, mas não corrija achados sem revisar semântica.
• Separe falso positivo, conflito de política e defeito real.
• Registre commit upstream e desvios locais para futuras atualizações.
• Revise o diff completo antes do merge.

Para validar dependências antes de executar código gerado por IA, consulte o guia Antes de executar código gerado por IA. Para outra abordagem de auditoria técnica, veja a Skill Audit Library Health.

Fontes oficiais consultadas

• SKILL.md oficial no commit auditado
• Procedimento oficial de atualização
• README do projeto
• Commit auditado
• Página da Skill no skills.sh
• Documentação oficial do Oxlint
• Configuração do Oxlint
• JS Plugins no Oxlint
• Criação de plugins JavaScript
• Licença MIT