/vibe-clean

Take a code surface — by default the current branch's diff against main — and clean it up. The methodology proceeds in this order: establish a comprehension baseline first (characterization tests on real inputs; run-and-observe rather than read-and-believe), then verify dependencies are real (no hallucinated imports; no slopsquatting), then trace every abstraction to its callers and inline what doesn't earn its keep. Default deletion-first. Grounded in .research/code-simplification.md §6 and §8.5.

The defining commitment of the skill is comprehension before structure. Plausible-looking code is the failure mode; reading it is not enough; running it on real inputs is the source of truth.

When to use

• User says "/vibe-clean", "vibe-clean this", "clean up this module", "audit and refactor", "deep cleaning".
• The user describes the code as: "Claude wrote this", "the agent generated this", "vibe-coded", "I haven't reviewed every line", "feels off but tests pass."
• A surface has signals like: imports for libraries you've never heard of, comments that restate code, tests that pass without obvious assertion strength, abstractions whose purpose is unclear from reading.
• You're inheriting a codebase from someone else and the original design decisions can't be reconstructed from the code alone.

When NOT to use

• You want to align the code with project conventions or industry standards (adding tests, types, fixing naming, replacing broad excepts) rather than the comprehension-first cleanup workflow. → /best-practice.
• The code is broken (tests red) and you need to root-cause. → /hunt first; /vibe-clean assumes you can establish current behavior.
• You don't have a way to actually run the code. The methodology is run-and-observe, not read-and-believe. Without execution, the skill becomes guessing.