ai-slop-cleaner

name	ai-slop-cleaner
description	[OMAGY] Run an anti-slop cleanup/refactor/deslop workflow

/omagy:ai-slop-cleaner

Use this skill when the user asks for cleanup, refactor, deslop, anti-slop, duplicate removal, dead-code removal, boundary tightening, or when a Ralph run reaches its mandatory cleanup pass.

This is a behavior-preserving cleanup workflow. It is not a rewrite command and it is not a substitute for product requirements, architect verification, or security review.

Scope Contract

• Accept the user-provided scope first: explicit files, directories, diff, branch, PR, or current project.

• If invoked from /omagy:ralph, discover runtime context with:

  omagy ralph status --json
  

• When Ralph state provides deslop_changed_files_path, read that file and keep cleanup strictly bounded to those Ralph-owned changed files unless the user explicitly expands scope.

• If the scoped file list is empty, treat cleanup as noop, explain why, and record status":"noop" when Ralph runtime state is active.

• Do not scan sibling repositories to silently expand scope.

• Do not introduce new dependencies, broad formatting churn, compatibility shims, or unrelated rewrites.

Ralph Integration

Ralph's mandatory deslop pass uses /omagy:ai-slop-cleaner after architect approval and before final re-verification.

If Ralph state is active:

1. Use deslop_changed_files_path as the default cleanup scope.

2. Respect deslop_enabled === false or an explicit --no-deslop instruction.

3. Run cleanup only after current regression evidence and architect approval exist.

4. After cleanup, rerun the relevant tests, build, lint, typecheck, or focused checks.

5. Record the cleanup result:

   omagy ralph record --input '{"kind":"deslop","status":"pass","summary":"ai-slop-cleaner completed","evidence":["<cleanup evidence>"],"phase":"verifying"}' --json
   

Use quality-reviewer only as an optional review lane for the cleanup result. It can find remaining maintainability issues, but it does not replace this skill's regression-tests-first cleanup workflow.

Procedure

1. Lock behavior first

   • Identify existing regression coverage for the scoped behavior.
   • Add or strengthen focused regression tests before refactoring when coverage is weak and the project test stack is available.
   • If tests are unavailable, state the blocker and use the strongest local static/build checks available.

2. Write a cleanup plan before editing

   • List the concrete smells found in scope.
   • Map each smell to the files and the intended behavior-preserving change.
   • Keep the plan small enough to verify after each pass.

3. Classify smells

   • Duplication or repeated control flow.
   • Dead code, stale branches, unused wrappers, or unused exports.
   • Needless abstraction, compatibility layers, or defensive indirection.
   • Boundary violations between runtime, skill, plugin, docs, and tests.
   • Missing or weak tests around changed behavior.

4. Execute in small passes

   • Delete dead code first.
   • Collapse duplication only when the resulting abstraction is simpler than the duplicated code.
   • Tighten naming, errors, and boundaries without changing public behavior.
   • Reinforce tests for any behavior touched.
   • Run targeted verification after each risky pass.

5. Gate completion

   • Required: targeted regression verification for touched behavior.
   • Required when available: typecheck, build, lint, and relevant unit tests.
   • Optional but recommended: quality-reviewer review for broad cleanup.
   • Stop and report blockers instead of guessing when behavior cannot be verified.

Output

Return an evidence-dense report:

AI SLOP CLEANUP REPORT
Scope: <files/directories/diff>
Behavior lock: <tests/checks before cleanup>
Smells removed:
- <smell> -> <change>
Verification:
- <command/check> -> <result>
Ralph record:
- <pass/noop/not applicable>
Residual risks:
- <remaining risk or none>