The interesting claim in SkillZip isn’t the 3.46x compression number. It’s the diagnosis: agent skills get retrieved as whole packages, compressed as flat text, and only turned into execution graphs after retrieval — three different representations for one thing, and none of them is the unit you actually need to reuse reliably.
That mismatch is why naive skill-library compression tends to break once it hits a real workflow. Squeeze a routine as text and you can silently drop a dependency or a precondition, and the failure surfaces three tool-calls later when the macro won’t execute. SkillZip compresses over section-level graphs instead, rewriting recurring valid motifs into reversible ported macros that keep boundary signatures, dependency closure, and — the phrase worth stealing — verifier reachability. At inference time it hydrates a compact, dependency-closed context and expands a macro only when the task actually reaches it.
The numbers I’d carry into a design review aren’t the headline accuracy gain. They’re 99.2% dependency preservation and 98.7% verifier reachability at that compression ratio, holding across libraries from 200 to 100K skills. If you run long-horizon agents, the context budget spent on skills is real latency and real spend, and the usual reflex is to trim the skill text with an embedding-ranked cut. This argues the better lever is picking a compression unit that carries its own contract, so what you drop is provably expandable rather than hopefully redundant.
The HF paper page frames this as scaling skill libraries, but the operational takeaway is narrower and more useful: put a reachability check inside your compression loop before you trust any token savings. How many teams are measuring compression ratio and never measuring whether the reused skill still runs?