Receber por email
← Voltar para o catálogo

ai-slop-cleaner

Limpeza pós-implementação que remove o excesso gerado por IA, preservando a funcionalidade. Executa passo a passo com verificação de testes após cada etapa, sendo ideal após kraken/spark concluírem um recurso ou quando uma base de código precisar de higiene.

507estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add vibeeval/vibecosystem

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/ai-slop-cleaner/svg)](https://www.skillteca.com.br/skills/ai-slop-cleaner)

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

AI Slop Cleaner

AI code generation produces working code. It also produces unnecessary code alongside it. This skill removes the unnecessary parts while keeping everything that matters.

What Is "AI Slop"?

AI slop is code that:

  • Works, but shouldn't exist
  • Adds complexity without adding value
  • Was clearly generated to pad a response rather than solve a problem
  • Suggests the author wasn't thinking, just generating

Common slop categories and their signals:

| Category | Signal | |----------|--------| | Dead imports | Imported but never referenced in the file | | Unused variables | Declared, never read | | Commented-out code | Blocks of // old code or / removed / | | Debug remnants | console.log, print(), debugger, fmt.Println | | Obvious comments | // increment counter above count++ | | Redundant JSDoc | @param name - the name above name: string | | Premature abstractions | A factory that creates exactly one thing | | One-use helpers | Private function called exactly once, trivially inlinable | | Overly generic types | <T extends object> when T is always User | | Over-parameterized | fn(a, b, c, d, e) where 4 params never vary | | Unreachable branches | if (false) or if (isLoggedIn && !isLoggedIn) | | Speculative features | Code paths for requirements that don't exist | | Copy-paste duplication | Two blocks identical except one variable name | | Placeholder remnants | TODO: implement, lorem ipsum, example data in prod |

The Prime Directive

Tests are sacred. Never clean test files.

Tests exist to protect behavior. Any cleanup that breaks a test reveals that the "slop" was actually load-bearing. That is good information. The test wins.

Regression-Safe Workflow (Non-Negotiable)

BEFORE ANYTHING: Run full test suite → all tests must pass (baseline)

FOR EACH PASS:
  1. Identify targets for this pass category
  2. Apply cleanup
  3. Run tests
  4. If tests pass: keep cleanup, continue
  5. If tests fail: git checkout -- . (revert), skip this pass category
  6. Log what was reverted and why

AFTER ALL PASSES: Run full test suite → confirm all tests still pass
Report: lines removed, files touched, passes skipped, reason for each skip

Never batch multiple pass categories together. If combined changes break a test, you cannot know which change caused it.

The 7 Cleaning Passes

Pass 1: Dead Imports and Unused Variables

Risk: Very Low

What to remove:

  • Import statements where the imported name never appears in the file body
  • Variables declared with let/const/var that are never read after assignment
  • Function parameters that are never referenced inside the function body (TypeScript: prefix with _)

Before:

import { useState, useEffect, useCallback, useMemo } from 'react'
import { formatDate } from '@/lib/utils'
import { ApiClient } from '@/lib/api'

export function UserCard({ user }) {
  const [count, setCount] = useState(0)
  const formatted = formatDate(user.createdAt)

  return <div>{user.name}</div>
}

After:

import { useState } from 'react'
import { formatDate } from '@/lib/utils'

export function UserCard({ user }) {
  const [count, setCount] = useState(0)
  const formatted = formatDate(user.createdAt)

  return <div>{user.name}</div>
}

Note: count, setCount, and formatted are still present because they may be used elsewhere in a larger component. Pass 1 only removes imports.

Pass 2: Commented-Out Code and Debug Statements

Risk: Very Low

What to remove:

  • Any block of commented-out code that is not an active TODO or architectural note
  • console.log, console.debug, console.warn (unless it is a legitimate error logger)
  • debugger statements
  • print() in Python when not serving as actual program output
  • fmt.Println in Go debug instrumentation

Before:

async function processOrder(orderId: string) {
  console.log('processing order', orderId)
  const order = await db.orders.findById(orderId)
  // const cached = await cache.get(orderId)
  // if (cached) return cached
  console.log('order fetched:', order)

  const result = await payments.charge(order)
  // TODO: add retry logic here
  // console.log('charge result', result)

  return result
}

After:

async function processOrder(orderId: string) {
  const order = await db.orders.findById(orderId)

  const result = await payments.charge(order)
  // TODO: add retry logic here

  return result
}

Rule: // TODO: comments are preserved. They are documentation of known gaps, not slop.

Pass 3: Obvious Comments and Redundant Documentation

Risk: Low

What to remove:

  • Comments that restate the code in plain English without adding context
  • JSDoc @param blocks that just repeat the parameter name and type (TypeScript already says this)
  • Section dividers that add no structure (// ===== COMPONENT =====)
  • End-of-block comments (} // end if, } // end for)

Before:

/**
 * Gets a user by ID.
 * @param id - the user ID
 * @param db - the database instance
 * @returns the user object
 */
async function getUserById(id: string, db: Database): Promise<User> {
  // Query the database for the user
  const user = await db.users.findById(id)

  // Return the user
  return user
} // end getUserById

After:

async function getUserById(id: string, db: Database): Promise<User> {
  return db.users.findById(id)
}

Keep comments that explain WHY (business rules, performance choices, known gotchas). Remove comments that explain WHAT (the code already says what).

Pass 4: Dead Code (Unreachable Branches)

Risk: Medium — Run tests immediately after

What to remove:

  • Conditions that are always true or always false
  • Code after unconditional return, throw, or break
  • Else branches of conditions that always throw in the if block

Before:

function getStatus(user: User): string {
  if (user.role === 'admin' || user.role === 'admin') {
    return 'ADMIN'
  }

  if (user.isActive) {
    return 'ACTIVE'
  } else {
    return 'INACTIVE'
  }

  // This never runs
  return 'UNKNOWN'
}

After:

function getStatus(user: User): string {
  if (user.role === 'admin') {
    return 'ADMIN'
  }

  return user.isActive ? 'ACTIVE' : 'INACTIVE'
}

Do not remove branches that look unreachable but depend on runtime data you cannot verify statically. When uncertain, leave it.

Pass 5: Premature Abstractions (Inline One-Use Helpers)

Risk: Medium — Run tests immediately after

What to inline:

  • Private/internal functions called exactly once
  • Wrapper functions that add no logic (just forward all arguments)
  • Intermediate variables assigned once and used once on the next line

Before:

function formatUserDisplayName(user: User): string {
  return `${user.firstName} ${user.lastName}`.trim()
}

function renderUserCard(user: User) {
  const displayName = formatUserDisplayName(user)
  return `<div class="card">${displayName}</div>`
}

After (if formatUserDisplayName is only called from renderUserCard):

function renderUserCard(user: User) {
  const displayName = `${user.firstName} ${user.lastName}`.trim()
  return `<div class="card">${displayName}</div>`
}

Do NOT inline if:

  • The function is exported (public API)
  • The function is called from more than one place
  • The function name serves as meaningful documentation of intent
  • The function contains error handling that would add visual noise when inlined

Pass 6: Duplication Consolidation

Risk: Medium-High — Run tests immediately after each consolidation

What to consolidate:

  • Two or more blocks with identical structure and only one variable difference
  • Repeated conditional checks that could be extracted to a guard function
  • Multiple switch/if-else blocks with the same cases in different files

Before:

// In UserService
async function getActiveUsers() {
  con
Compartilhar X LinkedIn