/simplify

Take a code surface — by default the current branch's diff against main — and reduce its complexity. Survey smells without fixing first; triage by impact × cost; apply structural changes (tidyings, in Beck's terminology) one per commit with tests staying green throughout. Default to deletion when in doubt: an inlined function call is almost always simpler than the extracted one. The opinionated canon driving the skill is grounded in .research/code-simplification.md, which surveys Ousterhout, Fowler, Beck, Metz alongside the dissenting voices (Muratori, Acton, Blow).

When to use

• User says "/simplify", "tidy this", "refactor this", "this is overengineered", "make this simpler", "too much abstraction".
• A surface has obvious smells: factory with one product, interface with one implementation, config knob with one caller, deeply nested control flow, methods over ~30 lines, wide parameter lists.
• The user wants Clean Code rules applied — push back gently and use this skill instead, which balances Martin's canon with Ousterhout/Muratori dissent.

When NOT to use

• The user wants alignment with project conventions or industry standards (adding tests, types, fixing naming, replacing broad excepts) rather than complexity reduction. → /best-practice.
• The code is performant-but-ugly and the goal is performance, not maintainability. Performance is a different optimization target with different rules.
• The user wants to add features. Don't sneak refactors into feature work; they belong in their own commits.
• The surface has no tests and you can't establish behavior on demand. Add characterization tests first (Feathers) — without them, a "tidying" can silently change behavior.

Hard rules