complexity-cuts — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited complexity-cuts (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
Use complexity-cuts when refactoring existing code that has poor Big-O:
O(n²) or worse scans, repeated work, redundant allocations, blown memory.await inside for over independent items causing serial latency.For preventing bad complexity before code is written, use `lemmaly`. For math-level optimizations (Bloom, HLL, FFT, JL projection), escalate to `mathguard`.
NO TRANSFORMATION WITHOUT EXISTING TESTS GREEN BEFORE AND AFTERIf 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.
time = O(?), space = O(?)time = O(?), space = O(?)If you cannot state current Big-O, you do not yet understand the code. Read more.
invariant-guard and write the missing contract — do not try a fourth transformation.Stacked changes hide regressions. Patched tests hide regressions louder.
<measured: TBD> and move on, or actually measure with a representative input.before → after plus the ratio as N× faster (or N× less memory). One line, attached to the diff: p50: 186 ms → 1.1 ms (169× faster, n=20,000, 200 samples)If you cannot measure (e.g. the win is purely asymptotic on inputs you don't have), say so explicitly: asymptotic only, no measurement — O(n²) → O(n). Never silently skip this step.
The vast majority of real-world Big-O wins come from a small set of moves. Try them in this order:
| Smell | Fix | Typical win |
|---|---|---|
for x in A: if x in B where B is list/array | Convert B to Set/Map once | O(n·m) → O(n+m) |
| Nested loop computing pairs/joins | Hash-join on the key; index by lookup field | O(n·m) → O(n+m) |
Repeated .find / .indexOf / .includes inside a loop | Precompute index Map<key, item> outside loop | O(n^2) → O(n) |
| Repeated recomputation of same value | Memoize / cache by input key | O(n·f(n)) → O(n + f(n)) |
| Sort inside a loop | Sort once outside | O(n^2 log n) → O(n log n) |
| Linear scan for min/max/median repeatedly | Heap / sorted structure | O(n·k) → O(n log k) |
| Recursive recomputation (naive Fibonacci shape) | Memoize, or convert to iterative DP | exponential → O(n) |
| String concatenation in a loop (some langs) | Use builder / join / array.push then join | O(n^2) → O(n) |
| Repeated regex compile in loop | Compile once outside | constant-factor, large |
| Counting / grouping via nested loop | Single pass with Counter / Map<k, count> | O(n^2) → O(n) |
| Sliding-window written as nested loop | Two-pointer |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.