complexity-cutslisted

# complexity-cuts — Lower Big-O on Existing Code lemmaly prevents bad complexity before code is written. complexity-cuts fixes it after the fact: code already exists, it works, but its time or space complexity is worse than necessary. **Violating the letter of these rules is violating the spirit of the skill.** Adapting "just a little" is how a faster-but-wrong rewrite ships. ## The Iron Law ```text NO TRANSFORMATION WITHOUT EXISTING TESTS GREEN BEFORE AND AFTER ``` If the code has no tests, you write a characterization test first (golden input → current output). Then transform. Then verify the test still passes. If you skip this, the optimization can silently break callers — and faster-but-wrong is worse than slow-and-right. ## Non-negotiable rules 1. **State current and target Big-O before touching code.** In one line: - Current: `time = O(?)`, `space = O(?)` - Target: `time = O(?)`, `space = O(?)` - Dominant input dimension (n = what, how large in practice) If you cannot state current Big-O, you do not yet understand the code. Read more. 2. **Identify the bottleneck, do not guess.** Point to the exact line(s) responsible for the dominant term. Nested loop? Repeated linear scan? Recomputation? Allocation inside a hot loop? The fix lives there, not elsewhere. 3. **One transformation at a time, with a verify-revert-stop loop.** The loop is: 1. Apply exactly one transformation from the playbook. 2. Run the existing test suite (or the characterizati