ai-slop-cleaner · diff
git:20260308.87a8a7e to git:20260312.bfe939c
81 added, 99 removed. Audit A to A.
---
name: ai-slop-cleaner
- description: Clean AI-generated code slop with a test-first, deletion-first deslop workflow and optional reviewer-only mode
+ description: Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode
---
- <Purpose>
- Use this skill to systematically clean AI-generated code slop without changing intended behavior. It focuses on simplifying existing code by deleting dead code, collapsing duplicates, removing needless abstractions, tightening boundaries, and reinforcing tests before and after cleanup.
- </Purpose>
+ # AI Slop Cleaner
- <Use_When>
- - The user explicitly says "deslop", "anti-slop", or "AI slop"
- - The request is to clean up or refactor code that feels bloated, repetitive, or overly abstract
- - The user wants a reviewer-only anti-slop pass via `--review` after cleanup work is drafted
- - The user calls out duplicate code, dead code, wrapper layers, boundary violations, or weak regression coverage
- - The goal is simplification, deletion, and cleanup rather than adding new features
- </Use_When>
+ 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.
- <Do_Not_Use_When>
- - The task is primarily a new feature build -- use `autopilot` or direct implementation instead
- - The user wants a broad architecture redesign rather than an incremental cleanup pass
- - The request is a generic refactor with no cleanup/simplification intent
- - Behavior is unclear and there are no tests or concrete anchors -- clarify scope first
- </Do_Not_Use_When>
+ ## When to Use
- <Why_This_Exists>
- AI-generated code often works while still adding avoidable complexity: duplicate helpers, dead branches, wrapper layers, inconsistent naming, boundary leaks, and missing tests. This skill enforces a disciplined cleanup workflow so simplification happens deliberately instead of as vague "refactoring" that might expand scope.
- </Why_This_Exists>
+ 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
- <Review_Mode>
- ### Review Mode (`--review`)
- `--review` activates an explicit reviewer pass after the cleanup writer pass.
+ ## 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.
+
+ ## 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 (`--review`)**: inspect the result for duplication, dead code, boundary violations, missing tests, and unnecessary abstractions.
- - The same pass must not both write and self-approve without a separate review step.
+ - **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** make edits first.
- 2. Inspect the cleanup plan, changed files, and regression coverage.
+ 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 was not consolidated
+ - duplicate logic that should have been consolidated
- needless wrappers or abstractions that still blur boundaries
- missing tests or weak verification for preserved behavior
- - risky cleanup that changed behavior without explicit intent
+ - cleanup that appears to have changed behavior without intent
4. Produce a reviewer verdict with required follow-ups.
- 5. If changes are needed, hand them back to a separate writer/executor pass instead of fixing and approving in one pass.
+ 5. Hand needed changes back to a separate writer pass instead of fixing and approving in one step.
- This mode exists to preserve writer/reviewer separation: the authoring pass changes code, the reviewer pass evaluates whether the cleanup actually reduced slop safely.
- </Review_Mode>
+ ## Workflow
- <Execution_Policy>
- - Preserve behavior unless the user explicitly asks for behavior changes
- - Lock behavior with regression tests first whenever practical
- - Write a cleanup plan before editing code
- - Prefer deletion over addition
- - Reuse existing utilities and patterns before introducing anything new
- - Avoid new dependencies unless the user explicitly requests them
- - Keep diffs small, reversible, and smell-focused
- - Keep writer/reviewer separation: author in one pass, review in another
- - Verify with lint/typecheck/tests/static analysis relevant to the touched area
- </Execution_Policy>
+ 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.
- <Steps>
- 1. **Lock behavior first**
- - Identify the current behavior and add or strengthen regression tests before cleanup when practical
- - If tests cannot be added first, record the verification plan explicitly before editing
+ 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.
- 2. **Create a cleanup plan**
- - Do not start coding immediately
- - List the targeted smells and the files likely involved
- - Sequence cleanup passes from lowest-risk deletion to higher-risk 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
- 3. **Categorize the slop**
- - Duplicate code
- - Dead or unused code
- - Needless abstraction / wrapper layers
- - Boundary violations / misplaced responsibilities
- - Missing or weak tests
+ 4. **Run one smell-focused pass at a time**
+ - **Pass 1: Dead code deletion**
+ - **Pass 2: Duplicate removal**
+ - **Pass 3: Naming and error-handling cleanup**
+ - **Pass 4: Test reinforcement**
+ - Re-run targeted verification after each pass.
+ - Do not bundle unrelated refactors into the same edit set.
- 4. **Execute one smell-focused pass at a time**
- - **Pass 1: Dead code deletion** -- remove unused branches, helpers, exports, and stale comments
- - **Pass 2: Duplicate removal** -- consolidate repeated logic into existing patterns where possible
- - **Pass 3: Naming and error-handling cleanup** -- tighten naming, trim noisy plumbing, normalize obvious inconsistencies
- - **Pass 4: Test reinforcement** -- fill any regression gaps revealed by the cleanup
+ 5. **Run the quality gates**
+ - Keep regression tests green.
+ - Run the relevant lint, typecheck, and unit/integration tests for the touched area.
+ - Run existing static or security checks when available.
+ - If a gate fails, fix the issue or back out the risky cleanup instead of forcing it through.
- 5. **Run quality gates**
- - Run the relevant lint, typecheck, unit/integration tests, and any static or security checks already present for the touched area
- - If a gate fails, fix the underlying issue or revert the risky cleanup instead of forcing it through
+ 6. **Close with an evidence-dense report**
+ Always report:
+ - **Changed files**
+ - **Simplifications**
+ - **Behavior lock / verification run**
+ - **Remaining risks**
- 6. **Optional `--review` pass**
- - Run a distinct reviewer pass that checks duplication, dead code, boundary violations, test coverage, and needless abstractions
- - If the reviewer finds issues, address them in a follow-up cleanup pass before closing the task
+ ## Usage
- 7. **Report outcome**
- - Changed files
- - Simplifications made
- - Behavior locked by tests
- - Remaining risks or slop intentionally left for a later pass
- </Steps>
+ - `/oh-my-claudecode:ai-slop-cleaner <target>`
+ - `/oh-my-claudecode:ai-slop-cleaner <target> --review`
- <Examples>
- <Good>
- User: "deslop this module -- too many wrappers, duplicate helpers, and dead code"
- Why good: Explicit anti-slop intent with concrete cleanup smells.
- </Good>
+ ## Good Fits
- <Good>
- User: "cleanup the AI slop in src/auth: remove dead code and tighten boundaries"
- Why good: Cleanup/refactor request is clearly about simplification, not feature work.
- </Good>
+ **Good:** `deslop this module: too many wrappers, duplicate helpers, and dead code`
- <Bad>
- User: "refactor auth to support SSO"
- Why bad: This is feature work disguised as refactoring, not anti-slop cleanup.
- </Bad>
+ **Good:** `cleanup the AI slop in src/auth and tighten boundaries without changing behavior`
- <Bad>
- User: "clean up formatting"
- Why bad: Formatting-only work does not need the full anti-slop workflow.
- </Bad>
- </Examples>
+ **Bad:** `refactor auth to support SSO`
- <Final_Report>
- Always end with:
- - **Changed files**
- - **Simplifications**
- - **Verification run**
- - **Remaining risks**
- </Final_Report>
+ **Bad:** `clean up formatting`