/ai-slop-cleaner

name: ai-slop-cleaner
description: Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode
level: 3

AI Slop Cleaner

Use this skill to clean AI-generated code slop without drifting scope or changing intended behavior. In OMC, this is the bounded cleanup workflow for code that works but feels bloated, repetitive, weakly tested, or over-abstracted.

When to Use

Use this skill when:

• the user explicitly says `deslop`, `anti-slop`, or `AI slop`
• the request is to clean up or refactor code that feels noisy, repetitive, or overly abstract
• follow-up implementation left duplicate logic, dead code, wrapper layers, boundary leaks, or weak regression coverage
• the user wants a reviewer-only anti-slop pass via `--review`
• the goal is simplification and cleanup, not new feature delivery

When Not to Use

Do not use this skill when:

• the task is mainly a new feature build or product change
• the user wants a broad redesign instead of an incremental cleanup pass
• the request is a generic refactor with no simplification or anti-slop intent
• behavior is too unclear to protect with tests or a concrete verification plan

OMC Execution Posture

• Preserve behavior unless the user explicitly asks for behavior changes.
• Lock behavior with focused regression tests first whenever practical.
• Write a cleanup plan before editing code.
• Prefer deletion over addition.
• Reuse existing utilities and patterns before introducing new ones.
• Avoid new dependencies unless the user explicitly requests them.
• Keep diffs small, reversible, and smell-focused.
• Stay concise and evidence-dense: inspect, edit, verify, and report.
• Treat new user instructions as local scope updates without dropping earlier non-conflicting constraints.

Scoped File-List Usage

This skill can be bounded to an explicit file list or changed-file scope when the caller already knows the safe cleanup surface.

• Good fit: `oh-my-claudecode:ai-slop-cleaner skills/ralph/SKILL.md skills/ai-slop-cleaner/SKILL.md`
• Good fit: a Ralph session handing off only the files changed in that session
• Preserve the same regression-safe workflow even when the scope is a short file list
• Do not silently expand a changed-file scope into broader cleanup work unless the user explicitly asks for it

Branch-Delta Focus

When invoked on a branch (the usual case for review-driven cleanup), the default surface is the slop **this branch introduced**, not the whole repo:

• Diff the branch against its base: the PR's base branch, else the branch

this one was cut from, else the repository's default branch.

• Include uncommitted changes in the surface.
• Clean only what the diff touches unless the user explicitly widens the

scope — pre-existing slop outside the delta is reported, not edited.

This bounds the pass to work whose review context is already open, and keeps unrelated legacy cleanup from riding in under an anti-slop flag.

Ralph Integration

Ralph can invoke this skill as a bounded post-review cleanup pass.

• In that workflow, the cleaner runs in standard mode (not `--review`)
• The cleanup scope is the Ralph session's changed files only
• After the cleanup pass, Ralph re-runs regression verification before completion
• `--review` remains the reviewer-only follow-up mode, not the default Ralph integration path

Review Mode (`--review`)

`--review` is a reviewer-only pass after cleanup work is drafted. It exists to preserve explicit writer/reviewer separation for anti-slop work.

• **Writer pass**: make the cleanup changes with behavior locked by tests.
• **Reviewer pass**: inspect the cleanup plan, changed files, and verification evidence.
• The same pass must not both write and self-approve high-impact cleanup without a separate review step.

In review mode: 1. Do **not** start by editing files. 2. Review the cleanup plan, changed files, and regression coverage. 3. Check specifically for:

• leftover dead code or unused exports
• duplicate logic that should have been consolidated
• needless wrappers or abstractions that still blur boundaries
• missing tests or weak verification for preserved behavior
• cleanup that appears to have changed behavior without intent

4. Produce a reviewer verdict with required follow-ups. 5. Hand needed changes back to a separate writer pass instead of fixing and approving in one step.

Workflow

1. **Protect current behavior first**

• Identify what must stay the same.
• Add or run the narrowest regression tests needed before editing.
• If tests cannot come first, record the verification plan explicitly before touching code.

2. **Write a cleanup plan before code**

• Bound the pass to the requested files or feature area.
• List the concrete smells to remove.
• Order the work from safest deletion to riskier consolidation.

3. **Classify the slop before editing**

• **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, misplaced responsibilities, wrong-layer imports or side effects
• **Missing tests** — behavior not locked, weak regression coverage, edge-case gaps
• **UI/design defaults** — generic visual patterns that make an AI-built interface feel unreviewed

UI/Design Reviewer Checklist

Use these as review prompts, not absolute bans. Keep intentional brand, accessibility, product-density, or design-system choices when they have a clear rationale.

• **Korean readability:** flag body text set around 11-12px; Korean body copy generally needs at least 14px unless a validated dense-data exception applies.
• **Shadow restraint:** question box shadows on every surface, logo, background, card, or icon; keep shadows only where they clarify el