AI Slop Cleaner

AI Slop Cleaner Skill

Reduce AI-generated slop with a regression-tests-first, smell-by-smell cleanup workflow that preserves behavior and raises signal quality.

When to Use

Use this skill when:

• A code path works but feels bloated, noisy, repetitive, or over-abstracted
• A user asks to “cleanup”, “refactor”, or “deslop” AI-generated output
• Follow-up implementation left duplicate code, dead code, weak boundaries, missing tests, fallback-like code, or unnecessary wrapper layers
• You need a disciplined cleanup workflow without broad rewrites

GPT-5.6 Guidance Alignment

• Keep outputs concise and evidence-dense unless risk or the user requests more detail.
• Treat newer user instructions as local workflow updates without discarding earlier non-conflicting constraints.
• Keep using inspection, tests, diagnostics, and verification until the cleanup is grounded.
• Proceed automatically through clear, reversible cleanup steps; ask only when a choice materially changes scope or behavior.

Scoped File Lists and Ralph Workflow

• This skill can accept a file list scope instead of a whole feature area.
• When the caller provides a changed-files list (for example, Ralph session-owned edits), keep the cleanup strictly bounded to those files.
• In the Ralph workflow, the mandatory deslop pass should run this skill on Ralph's changed files only, in standard mode unless the caller explicitly requests otherwise.

Procedure

1. Lock behavior with regression tests first

   • Identify the behavior that must not change
   • Add or run targeted regression tests before editing cleanup candidates
   • If behavior is currently untested, create the narrowest test coverage needed first
   • For fallback-like code, cover the primary path and any preserved compatibility/fail-safe fallback before cleanup

2. Create a cleanup plan before code

   • List the specific smells to remove
   • Bound the pass to the requested files/scope
   • If a file list scope is provided, keep the pass restricted to that changed-files list
   • Include fallback findings, classifications, and escalation status in the plan
   • Order fixes from safest/highest-signal to riskiest
   • Do not start coding until the cleanup plan is explicit

3. Inventory fallback-like code before editing

   • Search the requested scope for fallback-like detection signals: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths
   • Classify each finding before changing it:
     • Masking fallback slop — hides errors or evidence, bypasses the primary contract, suppresses tests or validation, swallows failures, silently defaults, or adds untested alternate paths
     • Grounded compatibility/fail-safe fallback — is scoped to an external/version/fail-safe boundary, documents the rationale, preserves failure evidence, and has regression tests for both the primary and fallback behavior
   • Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior before preserving fallback paths
   • For broad, ambiguous, cross-layer, or architectural fallback-like code, invoke $ralplan for consensus resolution before edits
   • Recursion guard: when already inside ralplan, ralph, team, or another OMX workflow, do not spawn a nested $ralplan; record the finding and attach it to the active ralplan, leader, or plan handoff instead

4. Categorize issues before editing

   • Fallback-like code — masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate execution paths
   • Duplication — repeated logic, copy-paste branches, redundant helpers
   • Dead code — unused code, unreachable branches, stale flags, debug leftovers
   • Needless abstraction — pass-through wrappers, speculative indirection, single-use helper layers
   • Boundary violations — hidden coupling, leaky responsibilities, wrong-layer imports or side effects
   • UI/design slop — review visual outputs as context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions when the rationale is clear
     • Korean body text that is too small: challenge 11-12px body copy; Korean body text generally needs 14px or larger unless a dense, accessible system explicitly supports smaller text
     • Gratuitous depth: avoid putting box shadows on every logo, surface, card, icon, background, and step block when hierarchy or affordance does not need it
     • Repetitive content scaffolding: trim repeated eyebrow + title + description + paragraph stacks, filler explanation text, and generic emoji badges that do not add meaning
     • Default AI palettes: question blue/purple defaults such as #3B82F6 when there is no brand, semantic, or system rationale
     • Over-perfect grids: avoid reflexive uniform 3-column or 4-column card grids when the product context would benefit from rhythm, asymmetry, carousel cuts, bento composition, or varied emphasis
     • Extreme gradients: tone down "AI demo" gradients unless the brand or campaign intentionally calls for that intensity
   • Missing tests — behavior not locked, weak regression coverage, gaps around edge cases

5. Execute passes one smell at a time

   • Fallback-like code resolution gate — remove masking fallback slop, repair root causes, or escalate ambiguous cases before continuing
   • Pass 1: Dead code deletion
   • Pass 2: Duplicate removal
   • Pass 3: Naming/error handling cleanup
   • Pass 4: Test reinforcement
   • Re-run targeted verification after each pass
   • Avoid bundling unrelated refactors into the same edit set

6. Run quality gates

   • Regression tests stay green
   • Lint passes
   • Typecheck passes
   • Relevant unit/integration tests pass
   • Static/security scan passes when available
   • Diff stays minimal and scoped
   • No new abstractions or dependencies unless explicitly required

7. Finish with an evidence-dense report

   • Changed files
   • Simplifications made
   • Fallback findings, classifications, and escalation status
   • Tests/diagnostics/build checks run
   • UI/design reviewer checklist findings when visual/UI files were in scope
   • Remaining risks
   • Residual follow-ups or consciously deferred cleanup