If you build agent skills in production, check out this great paper from Alibaba.

You can think of a production agent skill as a directory.

The root loads on activation, and references, schemas, scripts, assets and nested subskills load only when an execution path reaches them.

Compressing the root alone misses most of the deployment cost, and it can push branch-specific detail into context that is always loaded.

SkillZip Pro compresses the whole bundle, removing content from a reference or subskill when the root or a declared environment contract already provides it, while preserving routing so every required file and directly callable entry stays reachable after the rewrite.

On a production content-moderation skill it removes 38% of bundle tokens and 10.4% of end-to-end per-run tokens with no quality loss.

Four modes cover the deployment cases:

• One-Shot rebuilds the bundle
• Continual applies Zip-on-Write after each evolution patch
• Persistent rewrites the shipped bundle to cut storage and runtime context, and
• Transient keeps the shipped bundle byte-identical while building a task-specific view

Paper: https://arxiv.org/abs/2608.30785

Chat with Paper: https://academy.dair.ai/papers/skillzip-pro-execution-aware-dynamic-compression-of-progressively-loaded-skills-2608.30785…

Execution-Aware Dynamic Compression of Progressively Loaded Skills for Self-Evolving Agents

Source: https://arxiv.org/html/2608.30785 Abstract—Production agent skills are directory bundles, not isolated prompts. The root is loaded at activation; references, schemas, scripts, assets, and nested subskills are loaded only when an execution path needs them. Compressing only the root misses most deployment cost and may move branch-specific details into the always-loaded context. Flattening instead destroys progressive-loading boundaries. We introduceSkillZip Pro, an evaluation-free compressor for complete, progressively loaded skill bundles. It leaves the agent harness unchanged and emits an ordinary directory. The method combines two safeguards. First, it compressesacross files, removing content from a reference or subskill when the root or a declared environment contract already provides it. Second, it preserves routing, so every required file and directly callable entry remains reachable after rewriting. Users can configureSkillZip Proalong two independent axes.One-Shotmode rebuilds the full bundle;Continualmode reuses state and applies Zip-on-Write after each evolution patch.Persistentcompression rewrites the shipped bundle to reduce storage and runtime context.Transientcompression keeps that bundle byte-identical and builds a task-specific view, reducing only per-run context after build cost. Entry contracts mark private, public, and conditional resources; a multi-entry audit preserves standalone public subskills. On a production content-moderation skill evaluated by our industrial multi-round harness,SkillZip Proremoves38%of skill bundle tokens and10.4%of end-to-end per-run tokens with no quality loss, while an unprotected 71% configuration loses up to 26 accuracy points to one-sided false positives. On a multi-entry bundle,SkillZip Proeffeciently reduces token cost while near-perfectly preserving every route and public entry.Available at:https://github.com/yutou520131/SkillZip-Pro

Xiaofan Bai, Chao Liu, Hongqiang Lin, Di Wu, Mingli Song, Xuan Jin, Xipeng Cao, Yuhong LiEmail:[email protected]†Project leaderAffiliation:Alibaba Group Zhejiang University

IIntroduction

Agent skills package reusable instructions, procedures, and tools for use across tasks. A prototype may represent a skill as one prompt, but a production skill is usually a directory. A short root declares when the skill applies; references and subskills hold branch-specific knowledge; scripts implement deterministic operations; and schemas constrain inputs and outputs. Agents load this bundle progressively: catalog metadata is visible before selection, the root appears after activation, and auxiliary files are opened only when the current path requires them[1,2].

This execution mode changes the compression objective. A root-only method can report an attractive ratio while leaving most deployed text untouched; it can even move rare branch details into the root and increase every invocation’s context. Concatenation fixes the accounting gap but destroys progressive disclosure. Neither reflects the agent’s actual cost.

Fig. 1:The dynamic compression and progressive loading of agent skills.Self-evolving agents make the problem larger. Systems such as Voyager, Reflexion, and later evolution frameworks accumulate successful routines, counterexamples, and repair rules over time[3,4,5,6]. Repetition grows both within files and across branches. Sharing that logic saves space, but placement matters: moving content used by two rare branches into the root charges every task. Compression must therefore optimize aprogressively loaded resource graph, not a flat string.

Existing methods are not suitable for this setting. Prompt compressors optimize token salience or reconstruction in a flat context[7,8,9]. SkillReducer shortens skills with evaluation feedback, which requires rollouts and ties compression to sampled tasks[10]. Our earlierSkillZipformulation instead found a shortest faithful representation without evaluations[11]. It preserved typed behavioral contracts and supported Zip-on-Write, but treated one document at a time and could not model references, subskills, or progressive-loading costs.

We presentSkillZip Pro, a bundle-aware extension ofSkillZipthat preserves a harness-agnostic constraint:the agent harness is unchanged. Its output is an ordinary skill directory that uses existing file readers, paths, and loading behavior; no resolver, interception hook, or runtime protocol is required.

SkillZip Proadds two capabilities that a single-document compressor lacks.Pillar 1, activation-aware cross-file compression,removes content already supplied by the root or a declared environment contract, factors repeated branch content within its loading scope, and moves long guarded branches into on-demand capsules. These transformations reduce cross-file redundancy without enlarging the always-loaded layer.Pillar 2, cross-file routing preservation,locks routing instructions and audits the materialized directory before publication. Every required file must remain reachable, and interface contracts such as schemas, label lists, and worked formats remain contiguous and verbatim. The compiler supports two compression modes.One-Shot Compressionscans and optimizes the full directory for migration, release, or periodic repacking.Continual Compressionapplies each evolution patch verbatim, reuses unchanged contracts, and repairs only the affected graph closure, where a global repack is used to bound the accumulated drift.

To accommodate whether referenced files and subskills must remain independently usable outside the root skill, SkillZip Pro introduces a separate output-lifecycle choice.Persistent Bundle Compressionrewrites the canonical directory and is best suited to private resources used only through the root, reducing both storage and future runtime context. If it modifies a public entry, a multi-entry audit must verify that the entry remains independently usable.Transient Execution-View Compressioninstead leaves the canonical directory unchanged and constructs a task-specific view for each run, preserving the independent usability of all shipped entries by construction while reducing runtime context but not disk usage. Either lifecycle can use either compression mode. SectionV-Cdefines the resulting four combinations and their costs.

Both schedules resolve explicit local references into a conservative resource graph, extract typed contracts from text, and lock executable or binary artifacts. The objective separates catalog, activation, deployment, and path-weighted costs. After transformation, an independent audit rereads the emitted directory and checks graph closure, scope, contract coverage, and byte identity before atomic publication.

Our contributions are:

• •Bundle-aware compression for progressively loaded skills.We extend skill compression from a single document to a resource graph and jointly optimize content placement across the root, reference files, and subskills. This design removes cross-file redundancy without moving rarely used content into the always-loaded root.
• •Safe routing and independent entry preservation.We treat routing instructions and entry contracts as explicit constraints and audit the materialized bundle before deployment. This ensures that required branches remain reachable and that public subskills and references remain independently usable.
• •Flexible compression for different update and deployment requirements.We separate when compression is performed from where its output is stored. One-Shot and Continual modes support static and self-evolving skills, while Persistent and Transient lifecycles accommodate different requirements for storage reduction and independent resource usability.
• •Comprehensive compression results with production evidence.Every removal is supported by a containment, coverage, or logged-entailment witness, while interface contracts remain intact. On a production skill,SkillZip Proreduces deployed content by38%and end-to-end per-run tokens by10.4%while preserving decision quality.

IIRelated Work

Self-evolving agents and skill memories.Agents increasingly retain reusable procedures instead of solving every task from scratch. Voyager stores executable skills, Reflexion records verbal feedback, and ACE organizes evolving context as structured playbooks[3,4,5]. Other systems revise, optimize, or formalize skill artifacts[12,13,14,15]. As these libraries grow, equivalent rules accumulate at different scopes and branch updates can conflict.SkillZip Procompresses the resulting representation regardless of how it was created.

Prompt and context compression.LLMLingua, LongLLMLingua, and LLMLingua-2 remove or rewrite low-utility tokens[7,8,9]; selective-context, gisting, and recompression methods also target flat inference contexts[16,17,18]. Skill bundles differ in two ways: rare content may still be mandatory, and each execution loads only part of the directory.SkillZip Protherefore compresses typed behavioral units while preserving loading boundaries.

Skill compression and runtime representations.SkillReducer uses evaluation feedback to compress skill text[10]; parameterized skills and execution-time mechanisms instead change the representation or runtime[19,20]. Our transient lifecycle also builds content per run, but it remains evaluation-free and harness-neutral: the agent receives an ordinary directory and no resolver observes execution. The closest precursor isSkillZip, which introduced typed coverage and shortest-cover compression for one document.SkillZip Proextends its optimization object, cost model, rewrites, and audit to progressively loaded bundles.

Grammar-based compression and MDL.Minimum description length (MDL) selects the shortest faithful representation[21,22]. Grammar compressors such as Sequitur and Re-Pair factor sequences when references amortize definition cost[23,24]. We add semantic types, activation scope, path weights, locked artifacts, and deployment constraints. Sharing is allowed only when it lowers loaded-path cost.

IIIProblem Formulation

III-AA Skill Is a Progressively Loaded Bundle

We model a skill as a rooted directoryB=(V,E,r)B=(V,E,r). Each resourcev∈Vv\in Vhas a canonical pathpvp_{v}, bytesbvb_{v}, media typemvm_{v}, and loading classℓv\ell_{v}. The rootrris normallySKILL.md. An edgee=(u,v,g,s)e=(u,v,g,s)records a reference fromuutovv, its guardgg, and source spanss; a guard may be unconditional or author-written, such as “for CSV export.”

We distinguish four loading layers:

1. 1.Catalog:the name, description, and entry metadata visible before activation;
2. 2.Activation:the root instructions loaded whenever the skill is selected;
3. 3.Path:the transitive resources loaded for a particular execution branch;
4. 4.Deployment:all bytes distributed with the skill, including resources rarely or never read.

An edit can improve one layer while harming another. Moving a rare 500-token branch into the root may reducedeploymentlength after deduplication yet add 500 tokens to every activation. We therefore measure each layer separately.

Definition III.1(Safe resource graph).

A graph issafeif every resolved target is a regular file inside the canonical bundle root, every recorded internal reference has an existing target, and every edge retains its source span and guard. External URLs are recorded as external edges but are never fetched. Symbolic-link escape, path traversal, missing targets, and ambiguous dynamic paths are rejected in strict mode.

The resolver is intentionally conservative. Markdown links, explicit path literals, and declared subskill entries are recognized; an unrecognized file remains in the deployment bundle but contributes no inferred dependency. This prevents the compressor from inventing loading semantics.

III-BEntry Contracts: Which Resources Must Stand Alone

Agents usually reach resources from the root, but they may also select a nested subskill or reference directly. The compressor must know this before deleting content: text covered by the root may still be essential to a direct call. Anentry contractηv\eta_{v}therefore assigns each node one of three roles:

• •Private (internal):reached only through the root, with no standalone-use requirement.
• •Public (standalone):directly selectable and therefore fully usable without the root.
• •Conditional:directly usable only with a declared host context or dependency closure.

The author or catalog declares the contract; the compressor never infers it. For a public or conditional entryee, define independence as

Ind⁡(e,B′)=Cov⁡(e,B↓e′)​𝕀​[e​discoverable],\operatorname{Ind}(e,B^{\prime})=\operatorname{Cov}(e,B^{\prime}_{\downarrow e})\,\mathbb{I}[e\text{ discoverable}],(1)whereCov\operatorname{Cov}is the fraction of source contract units covered by the closureB↓e′B^{\prime}_{\downarrow e}reachable fromee, including any declared host context. Discoverability requires an executable entry at the advertised path. ThusInd=1\operatorname{Ind}=1means that the entry remains independently usable; missing content lowers coverage, while a renamed or hidden entry has independence zero.

III-CTyped Resource Contracts

For each textual nodevv,SkillZip Proextracts a contract

𝒞v=⟨Iv,Wv,Tv,Rv,Ov,Ev,Pv,Lv⟩,\mathcal{C}_{v}=\langle I_{v},W_{v},T_{v},R_{v},O_{v},E_{v},P_{v},L_{v}\rangle,(2)whereIIcontains applicability and interface conditions;WWworkflow states and ordering edges;TTtool or resource requirements;RRrules and prohibitions;OOoutput fields and formats;EEevidence or verification obligations;PPprovenance to source spans; andLLlocked residuals that must remain verbatim. Each unita∈𝒞va\in\mathcal{C}_{v}has a semantic type, normalized payload, scope, guard, and provenance.

Executable code, structured data, images, and other non-instructional artifacts arelocked nodes. Phase A may rename neither their path nor their bytes. Their inbound references can be rewritten only when the referring Markdown is rewritten and the canonical target remains identical.

For a candidate bundleB′B^{\prime}, letcover⁡(a,B′)\operatorname{cover}(a,B^{\prime})mean that a compatible statement, reference, or locked artifact inB′B^{\prime}entails unitaaon every path where it originally applied. Coverage is type constrained: an example cannot cover a prohibition, generic advice cannot cover a required output field, and an unrelated branch cannot cover a guarded rule.

Definition III.2(Bundle faithfulness).

B′B^{\prime}is faithful toBBunder environment contractHHif (i) every source unit is covered at a compatible scope, (ii) every locked node is byte-identical, (iii) all internal references inB′B^{\prime}resolve safely, and (iv) any unit removed by host entailment has an exact typed witness inHHbound to the audited environment digest.

This structural guarantee does not assert behavioral equivalence for every language model. It protects the bundle’s explicit contract, not every latent reading.

III-DFour Costs, One Constrained Objective

Letτ⁡(x)\tau(x)be the deployment tokenizer or another declared length function. For a bundleB′B^{\prime}, define

Ccat​(B′)\displaystyle C_{\mathrm{cat}}(B^{\prime})=τ⁡(name, description, entry),\displaystyle=\tau(\text{name, description, entry}),(3)Cact​(B′)\displaystyle C_{\mathrm{act}}(B^{\prime})=τ⁡(br′),\displaystyle=\tau(b^{\prime}_{r}),(4)Cdep​(B′)\displaystyle C_{\mathrm{dep}}(B^{\prime})=∑v∈V′τ⁡(bv′),\displaystyle=\sum_{v\in V^{\prime}}\tau(b^{\prime}_{v}),(5)Cpath​(B′,π)\displaystyle C_{\mathrm{path}}(B^{\prime};\pi)=∑v∈load⁡(B′,π)τ⁡(bv′).\displaystyle=\sum_{v\in\operatorname{load}(B^{\prime},\pi)}\tau(b^{\prime}_{v}).(6)Hereπ\pidenotes an execution path or task class andload\operatorname{load}follows the unchanged agent’s progressive-loading behavior. Given an empirical path distributionq⁡(π)q(\pi), our primary optimization target is

J⁡(B′)=Ccat​(B′)+Cact​(B′)+𝔼π∼q​Cpath​(B′,π)+λ​Cdep​(B′),J(B^{\prime})=C_{\mathrm{cat}}(B^{\prime})+C_{\mathrm{act}}(B^{\prime})+\mathbb{E}_{\pi\sim q}C_{\mathrm{path}}(B^{\prime};\pi)+\lambda C_{\mathrm{dep}}(B^{\prime}),(7)subject to bundle faithfulness. We useλ=0.05\lambda=0.05as a transparent default so that storage matters without dominating runtime exposure. If no trace distribution is available, explicit branch guards induce a uniform distribution over reachable leaf paths; every reported result must identify which estimator was used.

We report all four costs even when optimizing Eq. (7). A single “compression ratio” is insufficient: it can conceal a regression in the always-loaded root or in the tail ofpathcost. For metricxx, the reduction is1−Cx​(B′)/Cx​(B)1-C_{x}(B^{\prime})/C_{x}(B); negative values are preserved rather than clipped.

III-ETwo Deployment Lifecycles and Their Costs

The four costs above describe one artifact, but deployment has two distinct lifecycles.Persistentcompression rewrites the canonical bundle; its one-time work reduces storage and future runs.Transientcompression leaves the canonical bundle unchanged and builds a task-specific execution viewB^e,π\widehat{B}_{e,\pi}before a run through entryee. Its benefit applies only to that run and must be reported after build and cache cost.

Because the two change different things, we separate seven quantities and never average across them:

1. 1.Canonical storageCdisk​(B′)C_{\mathrm{disk}}(B^{\prime}): bytes of the on-disk bundle. Persistent shrinks it; transient keeps it equal to the source.
2. 2.Shipped/deploymentCdep​(B′)C_{\mathrm{dep}}(B^{\prime})(Eq. (7)): distributed bytes.
3. 3.Per-entrypoint activationCact​(B′,e)C_{\mathrm{act}}(B^{\prime};e): entry tokens loaded when entryeeis selected.
4. 4.Per-run execution-view tokensCview​(B^e,π)C_{\mathrm{view}}(\widehat{B}_{e,\pi}): context loaded for one run througheeon taskπ\pi.
5. 5.Transient build latencyΛbuild​(e,π)\Lambda_{\mathrm{build}}(e,\pi): wall-clock time and any model calls to constructB^e,π\widehat{B}_{e,\pi}.
6. 6.Cache and invalidationCcacheC_{\mathrm{cache}}: storing views keyed by (bundle digest, entry, environment version) and rebuilding them when any key changes.
7. 7.Public-entrypoint independenceInd⁡(e,B′)=1\operatorname{Ind}(e,B^{\prime})=1for every publicee: a mandatory deployment constraint.

Persistent results report quantities 1–3 and per-run load. Transient results report quantities 4–6, including build overhead, but never a disk ratio because disk is unchanged. Both lifecycles must satisfy constraint 7 for every public entry. They use the same kernel but differ in deletion scope, publication, auditing, and fallback (SectionV-C).

IVExecution-Aware Compression Theory

IV-AFrom Repetition to Scoped Reuse

Within one document,SkillZipselects a shortest cover of typed contract units using primitive statements, shared rules, parameterized procedures, and explicit exceptions. For candidate representationzz, letd⁡(z)d(z)be its token cost andΓ⁡(z)\Gamma(z)the units it covers. The file-level problem is a weighted set cover with hard coverage:

min⁡∑z∈ZZ⊆𝒵⁡d⁡(z)s.t.⋃z∈ZΓ⁡(z)⊇𝒞v.\min_{Z\subseteq\mathcal{Z}}\sum_{z\in Z}d(z)\quad\text{s.t.}\quad\bigcup_{z\in Z}\Gamma(z)\supseteq\mathcal{C}_{v}.(8)SkillZip Proretains this optimizer but changes candidate cost according to where the representation is placed in the bundle.

Suppose exact fragmentxxof lengthdxd_{x}occurs in filesSx⊆VS_{x}\subseteq V. Keeping all copies incurs∑v∈Sxwv​dx\sum_{v\in S_{x}}w_{v}d_{x}, wherewvw_{v}is the effective load weight induced by Eq. (7). Factoringxxintoshared modulehhwith reference costdrefd_{\mathrm{ref}}costs

wh​dx+∑v∈Sxwv​dref+daudit,w_{h}d_{x}+\sum_{v\in S_{x}}w_{v}d_{\mathrm{ref}}+d_{\mathrm{audit}},(9)wherewhw_{h}is the probability-weighted scope ofhh, anddauditd_{\mathrm{audit}}covers import instructions and provenance. Factoring is allowed only if Eq. (9) is smaller.

Proposition IV.1(No sparse-root promotion).

Letxxoccur only in branches with total access probabilityp<1p<1. Placingxxin the always-loaded root adds(1−p)​dx(1-p)d_{x}expected tokens relative to keeping one copy within the affectedactivation scope, before reference overhead. Therefore root promotion is suboptimal whenever the deployment saving is smaller than(1−p)​dx/λ(1-p)d_{x}/\lambdaplus reference cost.

Proof.

In Eq. (7), root placement gives load weight one, whereas branch-scoped placement gives weightpp. Their path-cost difference is(1−p)​dx(1-p)d_{x}; deployment can offset it only through theλ​Cdep\lambda C_{\mathrm{dep}}term. Adding nonnegative reference overhead yields the stated condition. ∎

The proposition captures a common failure: global deduplication can reduce storage while making common requests more expensive.SkillZip Proinstead places a shared module within the activation scope of the branches that need it. The root imports it only when every reachable path requires it.

IV-BConditional Capsules

A guarded section with an explicit trigger can be moved from an always-loaded file into an on-demandcapsule. Let the section body costdbd_{b}, dispatcher costdgd_{g}, and trigger probabilitypgp_{g}. Keeping the body inline costsdbd_{b}per load; a capsule costsdg+pg​dbd_{g}+p_{g}d_{b}in path expectation, plusλ​dg\lambda d_{g}deployment overhead.

Proposition IV.2(Capsule threshold).

Moving a guarded section to a capsule decreases Eq. (7) if

(1−pg)​db>(1+λ)​dg.(1-p_{g})d_{b}>(1+\lambda)d_{g}.(10)

The condition favors long, infrequent branches with short and unambiguous dispatchers.SkillZip Pronever infers a new guard: a capsule candidate must originate from an explicit heading or conditional clause, and the dispatcher must preserve the original trigger and relative path.

Capsules and sharing address different costs. A capsule delays an infrequent branch; a shared module removes exact repetition across branches. When both apply, the shared module remains within the union of those branches rather than moving to the root.

IV-CHost Entailment Under a Closed Contract

Some skill text restates guarantees already enforced by the deployment environment: an available tool, an immutable output schema, or a mandatory safety policy. Removing such text can yield a high activation reduction, but only if the guarantee is explicit and stable. We represent the environment as a signed typed contract

H={(t,k,v,σ,δ)},H=\{(t,k,v,\sigma,\delta)\},(11)wherettis unit type,kka canonical key,vvthe exact value,σ\sigmaits scope, andδ\deltathe environment digest. Removal requires an exact type/key/value/scope match; semantic similarity only flags manual review.

Assumption IV.3(Environment stability).

The audited environment digest remains unchanged between compression and deployment. If it changes, the bundle is re-audited or the entailment transformation is disabled.

Absent a supplied contract, host entailment is a no-op. This default avoids treating model knowledge, tool documentation, or informal conventions as guarantees.

IV-DInterface Contracts and the Witness Hierarchy

Typed coverage and host entailment do not fully protect two structures that matter in deployment: interface contracts and evidence for deletion.

Definition IV.4(Interface contract).

Aninterface contractis a maximal source section that specifies the skill’s inputs or outputs as a machine-checked format: an output schema with worked examples, a whitelist of legal labels, or a field-level validation rule. Interface contracts areatomic: the specification is read as one unit by the consuming model, so its coverage obligation is discharged only when the whole section is emitted contiguously and verbatim. A rewriting that preserves every line but scatters the section across several synthetic headings doesnotcover the unit.

The second gap concernshowa removal is justified. Coverage by itself is a claim; a witness is the evidence attached to it. Every removalSkillZip Procommits carries exactly one, recorded in the audit state:

W1≻W2≻W3,W_{1}\;\succ\;W_{2}\;\succ\;W_{3},(12)whereW1W_{1}isliteral containment: the removed text survives byte-for-byte at another reachable location, so the removal is reversible by construction;W2W_{2}is acover witness: a merged or shared representation passes the deterministic content-word coverage gate while retaining every protected literal and every negation polarity; andW3W_{3}is anentailment witness: a frozen checker model (temperature00, fixed prompt) certifies that the decision-relevant content of the removed span—conditions, verdicts, thresholds, whitelists, exemptions—is already fully expressed elsewhere.W3W_{3}verdicts are accepted only for evidence-class units that carry no prohibition, output, or exemption marker, and each accepted verdict is logged with the checker’s stated basis, so everyW3W_{3}removal is individually auditable after publication. Any deletion that cannot attach a witness is refused, whatever the predicted saving. Two further rules keepW3W_{3}honest when it is applied inside a single document: the entailment base excludes the candidate segment itself, and two candidates may not justify each other’s removal—a deletion whose only witness is another deletion is vetoed, because each verdict may have relied on text that is itself about to disappear. Where placement costs differ by layer,W3W_{3}should additionally be spent where the executor charges most: a removal from the always-loaded root saves its weight once per reasoning round, while a removal from an on-demand reference saves it about once.

The hierarchy makes the safety boundary testable:witness strength, not deletion count, sets the safe compression ceiling. SectionVI-Vcompares the same bundle underW1,W2W_{1},W_{2}alone and with restrictedW3W_{3}witnesses.

IV-EBundle Faithfulness Invariant

LetΦ\Phibe the ordered transformation sequence: resolve, extract, drop entailed units, factor exact structure, form capsules, apply file-level shortest cover, materialize, and audit.

Proposition IV.5(Phase-A preservation).

Under a safe source graph, exact extraction provenance, Assumption 1, interface-contract atomicity, and a sound final auditor, a committed outputB′=Φ⁡(B)B^{\prime}=\Phi(B)is faithful according to Definition 2 and can be executed by any harness that already supports the original bundle’s ordinary relative-file loading semantics.

Proof sketch.

Host deletion retains a digest-bound witness. Scoped sharing replaces covered units with a reachable reference in the same activation scope. Capsule extraction preserves the explicit guard in a dispatcher, and file-level compression obeys Eq. (8). Interface contracts remain contiguous, while locked nodes are copied byte-for-byte. The disk audit rejects uncovered units, unsafe or dangling paths, scope expansion, scattered contracts, and changed locked bytes. Every committed candidate thus meets Definition 2 and runs through the source model’s ordinary files and relative paths, with no added runtime mechanism. ∎

As with any static natural-language verifier, the guarantee depends on the extractor and auditor. We reduce this trusted surface by retaining source spans, preferring exact transformations, auditing emitted files rather than an in-memory plan, and falling back to a byte-identical copy on uncertainty.

IV-FContinual Compression

For an incoming evolution patchΔt\Delta_{t}, Continual Bundle Compression identifies an affected closureAtA_{t}: changed nodes, reference ancestors, newly or formerly referenced descendants, shared modules whose support set intersects the patch, capsules whose guards changed, and host witnesses invalidated by a new environment digest. Only this closure is re-extracted and locally re-optimized; unchanged contracts are reused by source digest. The graph-update cost is

O⁡(|At|+|E⁡(At)|)+LM⁡(Tt),O(|A_{t}|+|E(A_{t})|)+\operatorname{LM}(T_{t}),(13)whereTt⊆AtT_{t}\subseteq A_{t}are changed textual nodes requiring extraction. A global audit remainsO⁡(|Vt|+|Et|)O(|V_{t}|+|E_{t}|)in the conservative implementation, but uses hashing and cached contracts rather than new language-model calls.

Local decisions may drift from the one-shot optimum as support sets and path frequencies evolve. Define continual regret at checkpointttas

Rt=J⁡(Btcont)−J⁡(Btone)max⁡(1,J⁡(Btone)),R_{t}=\frac{J(B_{t}^{\mathrm{cont}})-J(B_{t}^{\mathrm{one}})}{\max(1,J(B_{t}^{\mathrm{one}}))},(14)whereBtoneB_{t}^{\mathrm{one}}is a full one-shot recompression of the same verbatim authored state. A triggered global repack resets placement debt. The trigger is conservative: recoverable saving aboveθrepack\theta_{\mathrm{repack}}, relative bundle growth aboveρ\rho, workload drift aboveδW\delta_{W}, an environment-digest change, or a maximum ofKKpatches. This gives a tunable continuum between full recompression after every write and cheap local updates.

Faithfulness does not depend on the schedule: both modes materialize and audit a complete directory. If continual optimization fails, the system publishes the verbatim patched bundle, not the previous compressed version. Compression may lose savings, but it cannot discard the patch.

VSkillZip Pro

Figure2summarizesSkillZip Pro. LikeSkillZip, it is evaluation-free and seeks the shortest faithful representation. The difference is scope:SkillZipcompiles oneSKILL.md, whereasSkillZip Procompiles a progressively loaded directory as a typed resource graph. It supports both full One-Shot optimization and state-reusing Continual updates.

The compiler removes linked-file content already supplied by the root or environment, then verifies every route. One-Shot or Continual determines when optimization runs; Persistent or Transient determines whether output replaces the canonical bundle or forms a per-run view.

Fig. 2:Overview of SkillZip Pro.(a) Compression modes.The bundle-aware kernel compresses a typed resource graph of skills, tools, prompts, policies, metadata, and inter-skill relationships while preserving routing, dependency, entry, and execution contracts. It supports global One-Shot compression, which builds a compact bundle in one pass, and state-reusing Continual compression, which incrementally updates an existing state as resources, tasks, or feedback change.(b) Bundle forms.Each mode produces either a Persistent Bundle for storage and repeated reuse, or a Transient Execution View for lightweight, task-specific execution. This separation balances compression, efficiency, adaptability, and contract fidelity.### V-AFrom SkillZip to SkillZip Pro

Compared toSkillZip,SkillZip Proadds graph-wide placement, accounting, and audits.

V-BThe Two Pillars

The extension has two goals.Pillar 1 (compress across files)chooses what to remove and where to place what remains.Pillar 2 (preserve routing)ensures that these rewrites do not sever the links used for progressive loading. The first creates savings; the second makes them safe to deploy.

Pillar 1 — activation-aware cross-file compression.Three graph-level transformations, none available to a single-document compressor, act on top of the per-file optimizer. (i)Host-entailment pruning: a unit whose obligation is exactly implied by the root or by a declared environment contract is removed, with a digest witness recorded, because the agent already receives it. (ii)Activation-scoped sharing: text repeated across branches is factored into oneshared module, but placedonly within the activation scope that loads it—never promoted into the always-loaded root, which would raise per-run cost. (iii)Conditional capsules: a long guarded branch moves into an on-demand file, leaving a one-line dispatcher. Together, these transformations remove redundancy between the root and dynamically loaded files.

Pillar 2 — cross-file routing preservation.The same rewriting is dangerous precisely because a routing line—“when the task matchesXX, read[X](refs/x.md)”—looks like ordinary prose but is the skill’snavigation table.SkillZip Proprotects it with three layers of defense. (i) The routing table islockedas a first-class unit, so the optimizer may neither reword nor merge it. (ii) Every reference-bearing source line is preserved through rendering, so a link cannot be dropped as a side effect of compressing the text around it. (iii) Before publishing, an independent pass re-reads the materialized directory and verifies thateveryfile—including shared modules and capsules the compressor itself created—is stillreachablefrom the root by following resolved links; if any branch became unreachable, the candidate is rejected and the verbatim bundle is shipped instead. SectionVI-Hmeasures the result:SkillZip Prokeeps1.0001.000routing fidelity while root-only and flat compressors drop to0.0000.000.

V-CTwo Deployment Lifecycles for the Kernel Output

Together, the pillars form a compression kernel that rewrites files while preserving their routes. A separate lifecycle choice determines where the result lives. This choice is independent of the One-Shot/Continual schedule in SectionsV-F–V-G: the schedule controls when the kernel runs, while the lifecycle controls whether its output replaces the shipped bundle.

Persistent Bundle Compressionruns the kernel on the canonical bundle and ships the smaller bundle in its place. It suits private references and subskills that are only ever reached from the root: their repeated text is covered elsewhere, so it can be removed once and for all, cutting both the shipped size and every future run that would have loaded it. Because the shipped files change, the kernel may touch a public entry only after amulti-entry auditre-reads the published directory fromeverydeclared public entry and confirms that each still routes correctly and keepsInd=1\operatorname{Ind}=1on its own; if any check fails, the verbatim bundle is shipped. This is the lifecycle of every earlier section, and we label it as such from here on.

Transient Execution-View Compressionleaves the canonical bundle byte-for-byte unchanged and builds a throwawayexecution viewB^e,π\widehat{B}_{e,\pi}before a run. For selected entryee, the view combines the closures of the root,ee, and their shared dependencies, compresses them with the same kernel, and re-roots the result atee. The original root remains linked as_host_context.md, so host obligations survive. The view is discarded or cached by(bundle digest,e,environment digest)(\text{bundle digest},\,e,\,\text{environment digest})until a key changes. It lowers run context, not disk use. Algorithm1summarizes the transient compression. If compression does not improve the view or its single-entry audit fails, the system loads the uncompressed closure.

Algorithm 1Transient Execution-View Construction1:canonical bundle

BBwith root

rr, chosen entry

ee, optional environment

HH, cache flag

2:execution view rooted at

ee; canonical

BBunchanged

3:

k←ViewKey​(digest⁡(B),e,digest⁡(H))k\leftarrow\textsc{ViewKey}(\operatorname{digest}(B),e,\operatorname{digest}(H)) 4:ifcacheand

Hit​(k)\textsc{Hit}(k)then

5:return

LoadCached​(k)\textsc{LoadCached}(k)⊳\trianglerightno kernel call

6:

Ω←Reach​(B,e)∪Reach​(B,r)\Omega\leftarrow\textsc{Reach}(B,e)\cup\textsc{Reach}(B,r)⊳\trianglerightentry and root closures

7:

R←MaterializeClosure​(B,Ω,e)R\leftarrow\textsc{MaterializeClosure}(B,\Omega,e)⊳\trianglerightpromoteeeto root; linkrras host context

8:

B^←Kernel​(R)\widehat{B}\leftarrow\textsc{Kernel}(R)⊳\trianglerightPillars 1–2, cross-file promotion on

9:if

B^\widehat{B}unusableor

τ⁡(B^)≥τ⁡(R)\tau(\widehat{B})\geq\tau(R)orsingle-entry audit failsthen

10:

B^←R\widehat{B}\leftarrow R⊳\trianglerightsafe fallback: uncompressed closure

11:return

Cache​(k,B^)\textsc{Cache}(k,\widehat{B})⊳\trianglerightverifydigest⁡(B)\operatorname{digest}(B)unchanged

Becausewhento compress andwhether to keep the resultare independent, they combine into the four production modes of TableI. One-shot persistent is the initial migration of an evolved library into a shipped bundle; continual persistent keeps that bundle small as it is edited and re-shipped; one-shot transient serves a stable bundle whose entries are called directly and rarely; and continual transient serves high-frequency direct calls against a bundle that keeps changing, where digest-keyed caching amortizes the build over many runs.

TABLE I:The two axes are orthogonal.Update frequency (One-Shot vs. Continual) decideswhenthe kernel runs; lifecycle (Persistent vs. Transient) decideswhether its output replaces the shipped bundle. The four combinations target different deployments.

V-DShared Inputs and Persistent Compiler State

The required input is a bundle root and its entry file. Optional inputs are a deployment tokenizer or cost callback, a workload ledger of task-class frequencies and observed resource loads, and a typed, digest-bound environment contract. Without traces, explicit branch structure estimates path weights. Without an environment contract, no host-entailment deletion is attempted. Both modes share a persistent compressor state

Mt=⟨Gt,𝒞t,Wt,Ht,ℐt,𝒫t,𝒜t⟩,M_{t}=\langle G_{t},\mathcal{C}_{t},W_{t},H_{t},\mathcal{I}_{t},\mathcal{P}_{t},\mathcal{A}_{t}\rangle,(15)whereGtG_{t}is the safe resource graph;𝒞t\mathcal{C}_{t}the per-node contract store;WtW_{t}the path-weight ledger;HtH_{t}the environment digest and witnesses;ℐt\mathcal{I}_{t}candidate, support, and reverse-reference indices;𝒫t\mathcal{P}_{t}provenance; and𝒜t\mathcal{A}_{t}prior audit results. The sidecar accelerates future compression but is never required at execution. If it is absent or its digest is stale, the tool safely falls back to one-shot reconstruction.

V-EShared Bundle Compiler

Safe graph resolution.The scanner walks the directory without following escaping symbolic links and classifies each node as instructional Markdown, subskill entry, code, structured data, or opaque asset. It recognizes local Markdown links, explicit path literals with known extensions, and declarative subskill references. Every internal edge records its exact source span and nearest explicit guard. External URLs are preserved but never fetched; missing, ambiguous, or escaping local targets fail strict mode. Unreferenced files remain in deployment cost and are never silently discarded.

Typed contract extraction.Each instructional node is segmented by headings and source spans. One structured extraction recovers Eq. (2), while every unit retains provenance. Relations such assame_rule,same_workflow, andexception_ofare accepted only after deterministic type, polarity, guard, and payload checks. Low-confidence units are locked and preserved verbatim. The originalSkillZipfile-level scanner, type-compatible reuse, minimum-cost cover, fixed-template render, and span-restoration audit operate here unchanged for each eligible file.

Bundle-level candidate generation.Three transformations expose savings unavailable inside a single file. (1) Exact contract units entailed byHtH_{t}may be removed only with a scope-compatible, digest-bound witness. (2) Repeated exact rules or workflow fragments may move to.skillzip_shared/<digest>.mdat their lowest safe activation scope; affected branches receive a mandatory relative loading instruction. (3) A long section with an explicit guard may move tocapsules/<slug>.md; a dispatcher retaining the trigger remains at the original site. Each transformation is evaluated together with per-file covers under Eq. (7).

Global selection and materialization.Because a capsule changes path weights and a shared module may serve several capsules, marginal selection is followed by local add/drop/swap improvement. Every move preserves modeled coverage. Materialization writes an ordinary relative-path directory; code, data, schemas, and assets remain byte-identical. Interface contracts (Definition 3) are restored as one contiguous verbatim span: surrounding prose may shrink, but the optimizer cannot split, reorder, or paraphrase the contract. A post-pass removes scattered render fragments and restores the source span. Every removal records its witness class from Eq. (12);W3W_{3}removals also store the verdict and rationale.

V-FMode I:One-ShotBundle Compression

One-shot mode is intended for initial migration, release packaging, a missing or invalid state sidecar, or a periodic global re-optimization after workload drift. It reconstructsMtM_{t}from the complete source bundle and searches globally. Algorithm2never publishes a candidate whose materialized objective is worse than the source.

Algorithm 2SkillZip Pro: One-Shot Bundle Compression1:source bundle

BB, entry

rr, optional

H,QH,Q 2:audited bundle

B⋆B^{\star}and state

MM, or verbatim

BB 3:

G←ResolveSafeGraph​(B,r)G\leftarrow\textsc{ResolveSafeGraph}(B,r) 4:

𝒞←ExtractTypedContracts​(G)\mathcal{C}\leftarrow\textsc{ExtractTypedContracts}(G) 5:

W←EstimateLoadWeights​(G,Q)W\leftarrow\textsc{EstimateLoadWeights}(G,Q) 6:

Z←FileCoverCandidates​(𝒞)Z\leftarrow\textsc{FileCoverCandidates}(\mathcal{C}) 7:

Z←Z∪HostEntailments​(𝒞,H)Z\leftarrow Z\cup\textsc{HostEntailments}(\mathcal{C},H) 8:

Z←Z∪ScopedSharing​(G,𝒞,W)Z\leftarrow Z\cup\textsc{ScopedSharing}(G,\mathcal{C},W) 9:

Z←Z∪GuardedCapsules​(G,𝒞,W)Z\leftarrow Z\cup\textsc{GuardedCapsules}(G,\mathcal{C},W) 10:

P←ConstrainedSelect​(Z,J,cover)P\leftarrow\textsc{ConstrainedSelect}(Z,J,\operatorname{cover}) 11:

D←MaterializeTemporary​(B,P)D\leftarrow\textsc{MaterializeTemporary}(B,P) 12:if

J⁡(D)≤J⁡(B)J(D)\leq J(B)and

AuditFromDisk​(B,D,H)\textsc{AuditFromDisk}(B,D,H)then

13:return

AtomicCommit​(D),SaveState​(D)\textsc{AtomicCommit}(D),\textsc{SaveState}(D) 14:else

15:return

VerbatimCopy​(B),FailureState​(B)\textsc{VerbatimCopy}(B),\textsc{FailureState}(B)

V-GMode II:ContinualBundle Compression

Continual mode targets self-evolving skills that receive frequent small patches. LetΔt\Delta_{t}contain added, modified, moved, and deleted paths. The tool first appliesΔt\Delta_{t}without paraphrase to the current authored source, producing the semantic fallbackBtrawB_{t}^{\mathrm{raw}}. It then updates reference edges and constructs an invalidation closureAtA_{t}containing changed nodes, their reference ancestors, newly or formerly referenced descendants, shared modules whose support changed, capsules whose guard changed, and any host witness invalidated by an environment digest change.

Only changed textual nodes are re-extracted; digest-identical contracts are reused. Patch units retain the four operations ofSkillZip:Absorbremoves an exact duplicate already covered;Refineupdates an existing rule, guard, argument, or exception;Extendadds genuinely new behavior or a new resource; andRefactorchanges a representation when several edits make another cover shorter. Pro extendsRefactorto placement: affected shared modules, capsules, and host witnesses are re-priced whenever their support set or path weight changes.

Local repair cannot accumulate unbounded debt. A one-shot global repack is triggered when recoverable objective saving exceedsθrepack\theta_{\mathrm{repack}}, bundle growth exceedsρ\rho, the workload distribution drifts beyondδW\delta_{W}, the environment digest changes, orKKpatches have elapsed. Repacking reads the current bundle and compact state, never the full patch history.

Algorithm 3SkillZip Pro: Continual Bundle Compression1:authored source

St−1S_{t-1}, audited state

Mt−1M_{t-1}, patch

Δt\Delta_{t} 2:current faithful bundle

BtB_{t}and state

MtM_{t} 3:

St,Btraw←ApplyPatchVerbatim​(St−1,Δt)S_{t},B_{t}^{\mathrm{raw}}\leftarrow\textsc{ApplyPatchVerbatim}(S_{t-1},\Delta_{t}) 4:

Gt,At←UpdateGraphAndClosure(Mt−1.G,St,Δt)G_{t},A_{t}\leftarrow\textsc{UpdateGraphAndClosure}(M_{t-1}.G,S_{t},\Delta_{t}) 5:

𝒞t←ReuseAndReextract(Mt−1.𝒞,At)\mathcal{C}_{t}\leftarrow\textsc{ReuseAndReextract}(M_{t-1}.\mathcal{C},A_{t}) 6:

Ut←Classify​(Absorb,Refine,Extend,Refactor)U_{t}\leftarrow\textsc{Classify}(\textsc{Absorb},\textsc{Refine},\textsc{Extend},\textsc{Refactor}) 7:

Zt←RefreshAffectedCandidates​(At,Ut,Mt−1)Z_{t}\leftarrow\textsc{RefreshAffectedCandidates}(A_{t},U_{t},M_{t-1}) 8:if

RepackTriggered​(Mt−1,St,Zt)\textsc{RepackTriggered}(M_{t-1},S_{t},Z_{t})then

9:return

OneShot​(St)\textsc{OneShot}(S_{t}) 10:

Pt←RepairLocalCoverAndPlacement​(Zt,J)P_{t}\leftarrow\textsc{RepairLocalCoverAndPlacement}(Z_{t},J) 11:

Dt←MaterializeTemporary​(Btraw,Pt)D_{t}\leftarrow\textsc{MaterializeTemporary}(B_{t}^{\mathrm{raw}},P_{t}) 12:if

J⁡(Dt)≤J⁡(Btraw)J(D_{t})\leq J(B_{t}^{\mathrm{raw}})and

AuditFromDisk​(St,Dt,Ht)\textsc{AuditFromDisk}(S_{t},D_{t},H_{t})then

13:return

AtomicCommit​(Dt),SaveState​(Dt)\textsc{AtomicCommit}(D_{t}),\textsc{SaveState}(D_{t}) 14:else

15:return

AtomicCommit​(Btraw),RebuildState​(St)\textsc{AtomicCommit}(B_{t}^{\mathrm{raw}}),\textsc{RebuildState}(S_{t})

The fallback distinction is essential. A failed one-shot run may return its input. A failed continual run cannot reactivateBt−1B_{t-1}after a valid patch, which would discard learned behavior; it publishesBtrawB_{t}^{\mathrm{raw}}and records the failure for retry.

V-HCross-File Audit and Mode Selection

The auditor ignores in-memory coverage claims and rereads the emitted directory. It checks (i) graph closure and path confinement; (ii) typed coverage at a compatible scope or by an exact host witness; (iii) mandatory reachability and guard preservation for every capsule and shared module; (iv) path and SHA-256 identity for locked artifacts; (v) that every interface contract appears as one contiguous span whose normalized lines equal the source section, with no scattered fragments elsewhere; and (vi) all four materialized costs. Atomic publication occurs only after audit succeeds.

V-IHarness-Agnostic Deployability

Both modes remain agent harness-agnostic. The compressor may persist state, observe offline traces, and run on every write, but the published bundle does not depend on it. The agent selects the same skill, loads the same root entry, follows ordinary relative links, and executes byte-identical artifacts.

VIExperiments

We design our experiments around three goals: determining whetherSkillZip Proreduces both deployment and progressively loaded runtime costs, verifying that these savings preserve task quality, routing, and the independent usability of public entries, and assessing whether its four operating modes remain practical as skills evolve. We evaluate these questions on three agent benchmarks, real self-evolving skill libraries, a controlled multi-entry bundle, and a production content-moderation skill. Comparisons with root-only, flattened, evaluation-guided, and expert-designed baselines are complemented by ablations and workload sweeps that isolate the contribution and cost of each design component.

VI-AWhat We Ask

• •Q1: Is one ratio enough?When does a root-only ratio misrepresent the four cost layers?
• •Q2: Does it help?DoesSkillZip Procut all four costs while keeping task success?
• •Q3: Does it still load correctly?Does the bundle open required files and skip irrelevant ones?
• •Q4: Is the saving real?How much source knowledge remains reachable rather than deleted?
• •Q5: Does it port across models?Does one compressed bundle stay useful when a different model family runs it?
• •Q6: What resources does compression consume?
• •Q7: Which part does the work?How much comes from the resource graph, host entailment, scoped sharing, capsules, and the audit?
• •Q8: One-shot or continual?How much update work does continual mode save, how far does it drift from a full rebuild, and when should it repack?
• •Q9: Does it hold in production?On a deployed skill, does witnessed compression preserve quality, and do modeled savings match runtime measurements?

VI-BBenchmarks and Skill Bundles Construction

We evaluateSkillZip Proon three task families:BFCL-v4for tool use[25,26],LiveMathematicianBenchfor mathematical problem solving[27,28], andSpreadsheetBenchfor spreadsheet editing[29]. These benchmarks require different kinds of instructions: BFCL-v4 depends on correct tool names and call order, LiveMathematicianBench requires detailed reasoning and verification, and SpreadsheetBench requires precise cell values and formatting.

The skill bundles are generated through self-evolution in our experiments. For each benchmark, we run the skill evolution optimizerSkillOpt[14]separately on every task class. The optimizer proposes one edit at a time and retains it only when it improves performance on that class. Each task therefore develops a specialised skill containing its own procedures, checks, and failure experience. These skills are not interchangeable, making routing important: the agent must identify and load the file associated with the current task class. From the resulting skills, we replay evolution patches into separate named branches. A deterministic builder records the source of every moved section and preserves its text verbatim. This process reproduces the structure that develops during continued self-evolution: common output rules, verification checklists, and records of previous errors are copied into multiple branches, while one branch accumulates a longer set of guarded edge cases.

We divide tasks into non-overlapping evolution, validation, and held-out test sets. Skill construction and compression use only the data assigned to evolution; the held-out test set is used exclusively for final evaluation. Every compression method receives thesame input bundleand thesame environment.

VI-CModels and Setup

We use the same three model families as the earlier manuscript: Qwen3.7-Max, Qwen3.6-Plus, and Kimi K2.6[30,31,32]. Qwen3.6-Plus runs the main tables, and all three serve as executors in the portability study. Sampling settings, tools, system prompt, and timeouts are fixed per benchmark. Deterministic compression needs one run per bundle; repeats are byte-identical.

The executor is the unmodified benchmark agent. It sees catalog metadata first, then the root once the skill is selected. Other files appear only after an ordinary file read, and a file can be opened only if something already loaded links to it. A wrapper records which paths were opened and how many tokens were read; it never injects, hides, or reorders content.

VI-DCompared Conditions and Baselines

We compareSkillZip Proagainst two reference conditions and four compression baselines. Unless stated otherwise, all compression methods receive the same evolved bundle, and all reported savings are computed relative to the uncompressed.

Reference conditions.

No Skillruns the agent without reusable instructions and provides a lower reference for task performance.Human Skilluses the original hand-written skill before self-evolution.Evolved Bundleis the complete, uncompressed output of the evolution process and serves as the primary reference for both fidelity and cost.

Compression baselines.

Root-only SkillZipappliesSkillZiponly to the rootSKILL.mdand leaves all referenced resources unchanged, representing single-document compression in a multi-file setting.Flat-concat SkillZipconcatenates all textual resources with path delimiters, compresses the resulting document, and then maps the output back to files; it tests the effect of ignoring progressive-loading boundaries.SkillReduceris the evaluation-guided skill compressor. To match our no-rollout compression budget, we disable its evaluation-based candidate selection and retain only its compression stage.Expert Progressiveis a deterministic, structure-aware baseline that factors paragraphs repeated across two or more files into a shared resource referenced from the root.

VI-EReading the Baselines: One Warning First

One baseline needs a warning before any number is read, because it otherwise looks like the strongest method in the paper.Flat-concatSkillZipposts the largest savings of any method and also throws away almost the entire skill.On the real evolved libraries of SectionVI-Mit keeps0.2%of the skill’s instruction lines: pasting every file together and compressing the result deletes the text and destroys the links that made the files reachable. Its savings are thereforenot comparablewith the other rows, and we mark it with†\daggerwherever it appears. We keep it in the tables on purpose: it is the clearest demonstration thata compression ratio means nothing until fidelity is measured next to it.

Root-onlySkillZipneeds a smaller warning. It only rewritesSKILL.md, so it looks harmless, but that one file holds the routing list. Rewriting it keeps every file on disk while making the branches unreachable in practice, which is why its routing score is0.0000.000everywhere.

VI-FMetrics

Task success.Each benchmark’s own automatic checker: boxed answer plus symbolic equality for math, normalized match against accepted answers for BFCL with its offline search tool available, and cell-by-cell workbook comparison for SpreadsheetBench, where a task passes only if every one of its test cases matches. For each method we also test whether it stays as good as the uncompressed bundle: we pool the held-out tasks of all three benchmarks, pair every method against the uncompressed bundle task by task, and bootstrap the difference in success rate (10,000 resamples). A methodkeeps qualitywhen the lower end of the 95% interval stays above a five-point margin fixed before we looked at the numbers.

Cost.We measure the four layers of SectionIII—catalog, activation, deployment, and loaded path—plus objectiveJJfrom Eq. (7). Negative savings remain visible.

Loading.Whether the agent opened the file that specialises in the task (required recall), what share of opened files were not that file (irrelevant load), how many links are broken or point outside the bundle, and how many files became unreachable from the root.

Knowledge kept.We count the source instruction lines still present, possibly lightly reworded, in reachable files. Environment-guaranteed removals are recorded separately rather than counted as loss; each has a signed audit witness.

Run cost.Compression time, model calls, tokens, peak memory, and rollouts, measured end to end.

VI-GMain Result: Task Success and the Four Costs

TablesIIandIIImust be read together, so that no method looks good on quality alone or on compression alone.

TABLE II:Task success on held-out tasks, using the unmodified agent (Qwen3.6-Plus, grown version). Higher is better.TABLE III:Four cost layers on three benchmarks. Cells report tokens and reduction from the Evolved Bundle; the agent is unchanged.Three things stand out. First, a single ratio really can mislead: Root-onlySkillZiptakes almost nothing off the shipped size yet shortens the always-loaded root a lot, while Human Skill looks like the best “compressor” by shipped size and at the same time makes the always-loaded rootlonger. Second, Flat-concatSkillZipposts by far the biggest numbers in both shipped size and per-run cost – and SectionsVI-Ishow those numbers are paid for by throwing away the skill. Third,SkillZip Prois the only method that cuts all four layers at once while matching the uncompressed bundle on task success. Figure3shows the per-layer picture.

On BFCL every method scores high because the offline search tool does much of the work; the skill still helps (no skill0.8090.809, uncompressed0.9050.905), andSkillZip Proreaches the top score of any method here (0.9520.952), but the gaps are a few questions wide on twenty-one held-out questions, so we lean on the pooled test below rather than this single column. On SpreadsheetBench, where a task passes only ifeveryone of its test cases reproduces the gold range,SkillZip Proscores0.3330.333against0.3120.312for the hand-built expert baseline and sits one task in forty-eight below the uncompressed bundle – we sample that benchmark at twice the density of the others precisely because its strict verdict makes single-task flips dominate at smallnn. TableIVruns the pooled test.

TABLE IV:Does the compressed bundle stay as good as the uncompressed one? Pooled over all102held-out tasks (33 math, 21 BFCL, 48 spreadsheet), paired task by task against the Evolved Bundle, 10,000 bootstrap resamples. A method keeps quality (✓) when the 95% interval stays above the−0.05-0.05margin fixed before the numbers were seen.The test is decisive and answers Q2 directly. Across102pooled held-out tasks,SkillZip Prohas the highest pooled success of any compression method, and it is theonlycompressor that keeps quality: its interval against the uncompressed bundle stays above the margin, while root-only, flat-concat, SkillReducer, and even the hand-built expert baseline all fall below it. In other words, every other way of making the bundle smaller also made the agent measurably worse, andSkillZip Prodid not.

Fig. 3:Saving in each cost layer (grown version, averaged over benchmarks). Bars below zero mean that layer gotworse: a method can shrink the shipped package while making every single run longer, which one ratio would hide.TakeawayA single ratio is insufficient. OnlySkillZip Proreduces all four costs while matching the uncompressed skill; every other compressor regresses elsewhere.

VI-HDoes Compression Preserve Progressive Loading?

A smaller bundle is useful only if the agent can still identify and load the resources required by each task. We therefore execute the grown bundles with the unmodified agent and measure both routing correctness and loading behavior. Required recall is the fraction of task-relevant resources that are loaded, irrelevant load is the fraction of loaded resources that the task does not need, and dispatch measures whether the agent selects the intended branch. We also record link errors, fallback activations, and the average number of reachable files.

TABLE V:Loading behavior on grown bundles. Required recall is maximized; broken links, unreachable files, and irrelevant loads are minimized.Among the compression methods,SkillZip Promost closely matches the loading behavior of the uncompressed bundle. It achieves a required-resource recall of0.7550.755, compared with0.7950.795for the Evolved Bundle, while reducing irrelevant loading to0.1930.193. The corresponding rates for the other compressors range from0.2590.259to0.2900.290. The larger number of reachable files underSkillZip Proreflects the shared modules and conditional capsules introduced during compression; these additional nodes remain connected to the appropriate execution paths rather than being loaded indiscriminately.

The absence of link errors alone does not establish routing fidelity. Root-only and Flat-concatSkillZipremove routing instructions instead of leaving dangling links, so their branches remain on disk but can no longer be selected. The routing audit confirms this distinction: both baselines preserve0.0000.000of the original routing pairs, whereasSkillZip Propreserves1.0001.000. Its savings therefore come from shortening and sharing the resources that the agent loads, rather than making required branches unreachable.

TakeawaySkillZip Propreserves every declared route and retains loading behavior closest to the uncompressed bundle. Its runtime savings come from reducing the content loaded along valid execution paths, not from suppressing required branches.

Insight 1★For the compression of progressively loaded skills, the danger is not lost text but lostreachability: rewriting only the root leaves every branch on disk yet unreachable in practice, so it looks safe and scores like deletion. Routing fidelity has to be measured separately from how many files still exist.

VI-IIs the Saving Real, or Just Deleted Text?

A compressor can post a very large ratio simply by removing text, and a cost table cannot tell that apart from genuine compression. TableVItherefore reports, for every method, how much of the original skill still reaches the agent, next to how much of therepeatedtext it managed to remove. Repeated text is the part a bundle-level method is entitled to reclaim; it is the same sentence appearing in several files.

TABLE VI:Knowledge retained versus text saved on grown bundles. “Kept” counts original instruction lines that remain reachable; “Lost” counts unwitnessed deletions.†\daggerdenotes an incomplete bundle.The result reframes the whole comparison. Flat-concatSkillZipappeared to be the strongest compressor by a wide margin, but it keeps under a quarter of the skill’s instruction lines: its ratio is mostly deletion, not compression. Root-onlySkillZipalso drops lines, because rewriting the root alone rewrites text that carried real conditions.SkillZip Proremoves the largest share of repeated text of any method while keeping essentially the whole skill, and its only removals that are not recoverable from the output are the ones the environment contract guarantees, each stored with a signed witness. Figure4plots the two quantities together.

Fig. 4:(a) Saving versus knowledge retained; shaded points lost content. (b) Repetition reclaimed.SkillZip Proachieves the largest faithful saving.TakeawayA large ratio may reflect deletion.SkillZip Proremoves the most repeated text while preserving the complete skill.

VI-JCase Study: What Does Compression Remove?

Aggregate compression ratios do not reveal whether a method removes redundancy or discards task-relevant content. We therefore examine one strategy file,round_02, from the evolvedqwen3.6-pluslibrary and compare its treatment under Flat-concatSkillZipandSkillZip Pro. This library contains substantial cross-file repetition: the same mathematical-output rules occur at 16 locations across the bundle, including all 15 strategy branches, while each branch retains its own workflow, verification steps, and conditional instructions. This example shows whether a compressor can eliminate the repeated content without changing the availability or behavior of the individual branch.

Original Branch## Purpose Solve competition-style math ## Approach 3. Notation for all unknowns… 4. Solve step by step… ## Rules×16\times 16bundle locations - Never round intermediate… - Reduce fractions… ## Output×16\times 16bundle locations - \boxed{...} final answer - multi-answer: comma list×15\times 15 - single: output only that×7\times 7 ## Verification - Substitute back - Sanity-check units

Flat-concatSkillZip✗ (branch removed)13 of 15 strategy branches removed. Onlyround_00andround_10remain. Root reduced to a flat routing list: - ---name: … - read [round_05](…) - read [specialist](sub/…) Branch content retained:0.2%; routing path:unavailable.

SkillZip Pro✓ (70% fewer tokens)## Workflow 1. Read[rounding rule]×16\times 16locations [multi-answer]×15\times 15[single]×7\times 7 2. Notation for unknowns… 3. Ordered vs. unordered… 4.If ambiguous, state assumptions 5. \boxed{...} ## Verification - Substitute back (branch-specific)

Legend.Yellowindicates content repeated across the bundle.Greenindicates content stored once in a linked shared module.Blueindicates a guarded instruction preserved verbatim.Greyindicates content removed by Flat-concatSkillZip.

Shared module## Notes - Never round intermediate results unless the problem explicitly asks for a decimal. - Reduce fractions to lowest terms and rationalize denominators where standard. - For counting: ordered vs. unordered, with vs. without replacement. - Give the answer in simplest exact form. This 315-token module is stored once and referenced from 16 locations across the bundle. Replacing the other 15 copies avoids15×315=4,72515\times 315=4{,}725repeated tokens.

Case summary

Fig. 5:One real strategy file (round_02,qwen3.6-pluslibrary) under three methods, plus the reuse it enables.Yellowmarks text duplicated across branches (with its repeat count);greenmarks the shared moduleSkillZip Profactors it into;bluemarks a guarded rule kept word for word.*Bottom left:*how many of the 15 strategy files reuse each shared moduleSkillZip Procreated.Bottom right:the token and reachability outcome for this file. Flat-concat’s big ratio comes fromdeleting the file;SkillZip Pro’s saving comes from writing each shared ruleonce.Figure5illustrates the source of the measured savings. Flat-concatSkillZipretains only two of the fifteen strategy branches, makinground_02unavailable to the agent. In contrast,SkillZip Proreduces this file from 527 to 160 tokens while keeping all fifteen branches reachable. Repeated rules are stored once and referenced from each relevant location, whereas the branch-specific workflow, verification steps, and guarded instructions remain unchanged. The reduction therefore comes from cross-file reuse rather than the removal of an execution path.

VI-KHow Do Savings Accumulate Across Repeated Use?

Because a skill is deployed once but may be invoked many times, deployment size alone does not determine its total cost. We therefore measure cumulative token cost as the sum of the one-time deployment cost and the runtime cost of executingNNtasks. TableVIIreports the percentage reduction relative to the Evolved Bundle. We separately identify methods that retain at least95%95\%of the original lines, since reductions obtained by removing substantial skill content are not directly comparable.

TABLE VII:Reduction in cumulative token cost relative to the Evolved Bundle, averaged across benchmarks. The cost includes one deployment andNNtask executions. The retention criterion requires a method to preserve at least95%95\%of the original lines;†\daggerdenotes methods that do not satisfy this criterion.Among the methods that satisfy the retention criterion,SkillZip Proachieves the largest cumulative saving at every workload size. Its reduction is17.9%17.9\%for a single task and remains12.1%12.1\%after 1,000 tasks, compared with11.1%11.1\%for Expert Progressive and5.5%5.5\%for SkillReducer. AsNNincreases, the effect of the one-time deployment cost diminishes and the results approach each method’s per-run saving. The ordering of the three eligible methods nevertheless remains unchanged. Root-only and Flat-concatSkillZipsometimes report larger reductions, but both fall below the retention threshold and are therefore excluded from this comparison. Figure6(a) presents the same results as cumulative-cost curves.

TakeawayRuntime cost matters more than a one-time shipping ratio. Among methods that preserve the skill,SkillZip Prois thecheapestat every workload size.

VI-LWhat Happens as the Library Keeps Growing

Self-evolving libraries do not stay small. We grow one step by step, adding branches that repeat the same shared text, and record both sides of the ledger at each size.

TABLE VIII:Behavior at the smallest and largest tested libraries, averaged over benchmarks. Retention and routing use the largest size.SkillZip Prois the only approach that preserves the complete skill and routing table at every size, and its per-run cost remains flat as the library grows. At the largest size, however, Expert Progressive removes more shipped bytes by moving all repeated text into one root-linked file. Every run then reads that growing file, so its runtime saving declines.SkillZip Prokeeps each shared block within the branches that use it, trading some storage saving for lower execution cost. Routing also has an unavoidable price: the root retains one condition per branch. An attempted on-demand grouping added a hop to every run and failed the never-inflate check. Figure6(b,c) shows this trade-off.

Fig. 6:(a) Cumulative token saving as tasks grow; faded methods lost skill content. (b) Shipped and (c) per-run saving as library size grows.SkillZip Prokeeps per-run saving stable.

VI-MReal Evolved Skill Libraries

The bundles used so far repeat about a third of their text. Libraries that a self-evolving agent actually leaves behind repeat far more, because every round appends its output rules, its checklist and its growing list of past mistakes into whichever skill it edits. We therefore take the evolution runs stored with this project, keepeveryround as its own file, and assemble each run into one progressively loaded library:17 files, 15 rounds, about 20,000 tokens, and 79–84% repeated text. This is the regime the method is built for, so it carries the headline numbers.

TABLE IX:Real evolved libraries, averaged over three runs.†\daggermarks incomplete bundles. ForSkillZip Pro, brackets count published compressions; otherwise the never-inflate check republishes the source.Three readings matter. First, where it publishes a result,SkillZip Proremoves34.7%of shipped tokens versus25.0%for the strongest faithful baseline, while preserving the skill and routing list. Second, that baseline moves all repeated text into one root-linked file, making the always-loaded layerlonger(−2.9%-2.9\%); onlySkillZip Proimproves every layer at full fidelity. Third, root-only and SkillReducer gain+69%+69\%and+63%+63\%in the root by rewriting away routing, reflected in routing scores of0.0000.000and0.1250.125.

On the third library,SkillZip Prodeclined to compressand republished the source byte for byte. The candidate passed the audit but did not improve the objective, so Algorithm2rejected it. This fallback is intentional: the method never ships an unproven regression. Continual mode later compresses the same library to+49.9%+49.9\%by repacking at a more favorable point in the stream (SectionVI-N).

Fig. 7:(a) Saving versus retained knowledge on evolved libraries. (b) Published cost over rounds; triangles mark repacks. (c) Update work versus final drift from One-Shot rebuilding.TakeawayOn real self-evolved libraries,SkillZip Proremovesabout one thirdof shipped tokens where it publishes—roughly ten points more than the strongest content-preserving baseline. It is also the only method that improves shipped, always-loaded, and per-run cost together; otherwise it keeps the original bundle.

VI-NContinual Compression Over a Long Evolution Stream

Continual compression is intended to incorporate new skill updates without rebuilding the entire library after every change. We evaluate whether it can reduce this update cost while still recovering redundancy that accumulates across multiple rounds. Specifically, we replay13 real evolution roundsfor each of three libraries and compare five compression schedules. All schedules begin from the same initial state and receive the same sequence of updates.

TABLE X:Continual compression over 13 real evolution rounds, averaged across three libraries. Savings are measured relative to publishing every update without compression. Drift measures the difference from rebuilding the complete library at the same round; a negative value indicates a smaller result than the rebuild. Compressor calls, processed bytes, and wall-clock time are reported per round.SkillZip ProContinual with repacking removes48.1%of shipped tokens and28.2%of per-run tokens while requiring only3.31compressor calls per round.Rebuilding the complete library after every update requires10calls per round, so Continual mode uses approximately one third as many calls. It also reduces the average processing time from0.2340.234to0.0680.068seconds per round. The result is slightly smaller than the corresponding rebuild, as indicated by the drift of−0.083-0.083. This difference occurs because the final rebuild rejects a non-improving candidate, whereas Continual mode retains the valid compressed state produced by an earlier repack.

Periodic repacking is necessary to recover redundancy introduced across different evolution rounds. Without repacking, the shipped-token saving falls to2.7%, the per-run saving falls to0.8%, and drift increases to+0.262+0.262. This result shows that processing each update locally is insufficient when related content is added in separate rounds. Root-only Zip-on-Write requires only one call and 389 processed bytes per round, but it reduces the shipped library by just*2.4%*because it cannot consolidate repeated content across files. Although it reduces the root-level per-run cost, it leaves most bundle-wide redundancy unchanged. Figure7(b,c) shows how these differences accumulate over the evolution stream.

TakeawayWith periodic repacking, Continual mode recovers cross-round redundancy while usingapproximately one thirdas many compressor calls as rebuilding after every update. Without repacking, shipped-token savings remain at only2.7%.

VI-OWhen Should Compression Be Switched On?

A self-evolving library is republished and reloaded after every round. Waiting therefore costs more than final size: the agent carries the uncompressed library through every earlier round. We switch compression on atk∈{1,4,7,10,13}k\in\{1,4,7,10,13\}, plus a never-compress baseline.

The metric that answers the question isthe total tokens the agent carries across the whole stream: for each round we add up the full size of the library published at that round. We also report the total compressor calls, so a schedule cannot look cheap merely by doing less work.

TABLE XI:When to switch compression on, averaged over the three libraries and the whole 15-round stream. Carried tokens is the sum, over rounds, of the size of the library the agent holds that round.The ordering is monotone and the effect is large.Switching on at the first round saves40.8%of everything the agent carries over the stream; waiting until round 13 recovers only18.5%, less than half as much, and starting at round 1 beats starting at round 7 by a clear9.7%. Every extra round of waiting leaves saving on the table.

The reason is worth stating precisely, because it is not simply “smaller is better”. Repetition in an evolved library iscumulative: roundttre-appends the same output rules and checklist that rounds1..t−11..t-1already contain, so the number of duplicate copies grows withtt. Compression removes copies, not rounds. Starting at roundkktherefore leaves the agent paying full price on rounds1..k−11..k-1, and those tokens can never be recovered afterwards – the final library can be compressed just as well later, but the intervening runs are already spent. Figure8(b) plots the running total the agent has paid: the three curves never cross, so an earlier start is cheaper ateveryround and the gap only widens. Early compression is strictly cheaper because delayed rounds cannot be recovered. Starting at round 1 requires 43 compressor calls over 15 rounds, versus 16 for a late start, and uses no task rollouts.

Fig. 8:(a) Total tokens saved over the stream against the round compression is switched on; bars show the spread across the three libraries. (b) Actual library size at each round: uncompressed grows linearly while Pro keeps it roughly50%smaller by removing repeated text as it appears. (c) The same total saving plotted against the number of compressor calls.Insight 2★For a self-evolving agent, compression should start early. Repetition accumulates each round, and later compression cannot recover context already paid for. The lowest cumulative cost therefore comes from enabling compression in the first evolution round.

VI-PWhy the Savings Compound: A Look Inside Self-Evolution

The results so far showthatSkillZip Prohelps; this subsection showswhy, and the reason is the surprising finding in the paper. We measured, at every evolution round, how much of the growing library is genuinely new and how much simply repeats text the agent has already written, by compressing each round-kkprefix and comparing its size against the raw prefix. Three facts fall out, all from the same real evolved libraries and all consistent across runs.

Fig. 9:Why the savings compound.(a) The share of shipped tokensSkillZip Proremoves climbs from29%at round 2 to53%at round 15 and is still rising – the method getsmorevaluable the longer the agent evolves. (b) The reason: the fraction of each new round that merely repeats earlier text is stable at55%±\pm3%– more than half of everything a self-evolving agent writes, it has written before. (c) That repetition is concentrated: a few “universal” rules absorb most of the reuse (top two of seven modules==47%), so a small shared library covers the bulk of the redundancy.Finding 1 — repetition accumulates during self-evolution.Across rounds,55%±3%55\%\pm 3\%of the content added in each round overlaps with existing text (Figure9b). This proportion remains relatively stable across rounds and models, as append-only updates often repeat output formats, verification checklists, and previously accumulated rules when extending a skill.

Finding 2 — so the savings compound with age.Because redundancy accumulates, the shareSkillZip Procan removegrowswith the library: from29%at round 2 to53%at round 15, still climbing (Figure9a).*The method does not have diminishing returns; it has increasing ones.*The longer an agent runs, the more of its library is repetition, and the moreSkillZip Prosaves – the opposite of how one-shot compressors of static prompts behave.

Finding 3 — the repetition is concentrated.The reuse is heavy-tailed: of the seven shared modulesSkillZip Profactors out on the worked library, the top two account for47%and the top three for64%of all reuse (Figure9c). A handful of “universal” rules – how to format the answer, when to keep exact values – are re-derived over and over, so a very small shared library covers most of the redundancy.

Remark.For references or subskills that are used only through the root skill, these universal rules are redundant and can be removed throughPersistent Compression. If a reference or subskill must also remain independently usable, however, a rule repeated from the root may still be required by its standalone entry contract and cannot be removed solely because of that overlap. In this case,Transient Compressioncan eliminate the duplication within a task-specific execution view while leaving the original resource unchanged. We will discuss this distinction in detail in SectionVI-U.

Insight 3★Self-evolution manufactures redundancy, andSkillZip Proturns that into a compounding advantage.More than half of every new round (55%) is text the agent has already written, so the shareSkillZip Proremovesriseswith age –29%→\to53%over fifteen rounds and still climbing. A compressor for evolving skills is therefore worthmorethe longer it runs, not less; and because the repetition concentrates in a few universal rules, a tiny shared library captures most of it. This is the reason to put compressioninsidethe evolution loop rather than treating it as occasional cleanup.

VI-QRuntime Overhead of Compression

TableXIImeasures the computational cost of producing a compressed bundle. We report wall-clock time, model calls, model tokens, agent rollouts, and peak memory. These measurements isolate compression overhead from the subsequent cost of executing tasks with the compressed skill.

TABLE XII:Mean cost of compressing one skill bundle. Structural extraction, cross-file transformation, and post-compression auditing are deterministic and require no model calls, model tokens, or agent rollouts.SkillZip Procompresses a bundle in0.21 seconds on average, compared with0.11 secondsfor Root-onlySkillZip. The additional0.100.10seconds are used to resolve the resource graph, identify content that can be shared across files, construct conditional capsules, and audit the resulting bundle from disk. Despite these additional checks,SkillZip Prorequiresno task feedbackandno agent rollouts. Its peak memory usage remains0.02 GB, identical to the other methods.

VI-RDoes a Compressed Bundle Transfer Across Models?

A compressed bundle should not depend on the model that later executes it. We therefore evaluate thesameSkillZip Prooutput with three executor models(qwen3.7-max as the evolving model), without recompiling or modifying any files. For each executor, we compare task success and progressive-loading behavior against the same uncompressed Evolved Bundle. The reported results are run on the structured track of two of our three benchmarks—LiveMathematicianBench (27 held-out tasks) and BFCL-v4 (17 held-out tasks), 44 tasks in total—with each cell macro-averaged over the two benchmarks.

TABLE XIII:Transfer of one compressed bundle across three executor models. Each executor runs the sameSkillZip Probundle and the corresponding uncompressed Evolved Bundle on identical tasks. Required-resource recall and irrelevant loading measure whether compression changes the resources selected during execution.The compressed bundle remains executable without modification under all three models, confirming that its files, relative links, and routing structure do not require an executor-specific integration. With qwen3.7-max and qwen3.6-plus,SkillZip Proimproves task success from0.5410.541to0.619and from0.6080.608to0.656, respectively, while required-resource recall and irrelevant loading remain close to those of the uncompressed bundle. The result is less consistent for kimi-k2.6: required recall improves from0.4350.435to0.490, but task success decreases from0.6110.611to0.574and irrelevant loading increases from0.0770.077to0.287. Thus, the bundle is structurally portable, although its loading efficiency still depends on how the executor interprets the shared routing instructions.

Insight 4★Compression changes not only bundle size, but also cross-model transferability.Moving repeated instructions from inline copies into shared files makes execution depend more strongly on routing. This restructuringimproves task success for both Qwen executors, but causesmore irrelevant loading and slightly lower success for kimi-k2.6.

VI-SWhich Part Does the Work?

TableXIVswitches off one piece at a time, grouped by the two pillars. The first four rows ablatePillar 1(what and where to compress); the last three probePillar 2(keeping the routing intact). “No resource graph” approximates compressing each file on its own; “global sharing” deliberately ignores which branches need a block and tests the failure predicted by PropositionIV.1.

TABLE XIV:Turning off one piece at a time (grown version). “Damage” counts files left unreachable plus broken links. Quality columns use held-out runs and are reported for the full method.The ablations separate the pillars.Pillar 1supplies the savings: removing scoped sharing loses most deployment reduction, while removing capsules trades lower storage for higher per-run cost, as Eq. (10) predicts.Pillar 2makes those savings deployable. Global sharing pushes content into the root, drivesJJbelow the source (−0.166-0.166), and makes one file unreachable. Disabling only the routing lock leaves routing intact because reference-line preservation and the final reachability audit remain. Routing safety therefore comes from layered checks, not one switch.

We sweepλ∈{0,0.01,0.05,0.1,0.25,1}\lambda\in\{0,0.01,0.05,0.1,0.25,1\}and rerun the optimizer. Figure10shows identical transformations and costs across the range. Each bundle-level move is accepted only when package saving exceeds added loading cost, so the decision remains stable fromλ=0\lambda=0to11. The defaultλ=0.05\lambda=0.05is not tuned to the results.

Fig. 10:Sensitivity to storage weightλ\lambda. Costs remain unchanged across two orders of magnitude; the dashed default is not result-tuned.TakeawayCross-file sharing produces most of the shipped saving, while capsules trade a small storage cost for cheaper runs. Ignoring branch scope breaks the bundle, and varyingλ\lambdaover two orders of magnitude does not change the result.

VI-TOne-Shot Versus Continual

Patches are replayed in order into a fixed source, so every checkpoint has one identical uncompressed bundle that all schedules start from. We compare: publish without compressing; rebuild fully after every patch (the reference); root-only Zip-on-Write; continual with local repair and no repack; and continual with the preset repack rule. Continual runs may only reuse state from before the current patch.

TABLE XV:After the last patch, averaged over benchmarks. Savings are against publishing without compressing. Drift is measured against a full rebuild of the same state. Update seconds, bytes touched, and calls are per patch.Continual mode with repacking reaches the full rebuild’s objective with zero drift, about one third of the model calls per patch, and far fewer rewritten bytes. Between repacks it reads only the changed file; without repacking, unfactored repetition accumulates. Root-only Zip-on-Write reports a smaller objective only by rewriting routing text thatSkillZip Prolocks; TableVshows the runtime loss.

Fig. 11:Continual mode over patches. (a) objective per patch, full rebuild (solid) versus continual with repack (dashed); (b) drift from the full rebuild, with repack events marked; (c) model calls added up over patches; (d) repack rules, calls against worst drift.TABLE XVI:Repack rules on one patch stream. Repack rate is the fraction of patches rebuilt globally; worst drift spans all checkpoints.TableXVIshows the schedule matters more than any single trigger here. Rebuilding after every patch removes all drift at nearly ten times the per-patch call cost, while never rebuilding still keeps worst drift near a tenth of a percent. The saving and growth triggers never fire on this stream because drift never crosses their thresholds, so the combined rule is driven by the patch counter and lands at a quarter of the rebuild rate with the same bounded drift.

TakeawayContinual mode matches a full rebuild with about one third of the model calls per patch. A patch-count trigger is sufficient at this scale; the other triggers protect faster-changing workloads.

VI-UThe Compression Lifecycle: Persistent vs. Transient

Every result above shipped a rewritten bundle on disk. In the vocabulary of SectionV-Cthat isPersistentcompression: TablesIII,V, andVIare all persistent results, and we relabel them as such rather than re-run them. What those tables did not test is the second lifecycle—building a throwaway view per run—or the case that makes the two lifecycles diverge: a bundle whose subskills and references are calleddirectly, not only from the root. This subsection adds exactly that—and it is whereSkillZip Pro’s advantage is easiest to see: among all methods we test, onlySkillZip Procompresses a multi-entry bundle while keepingallof its routing andeverydeclared entry independently callable, whereas the lossy baselines reach their smaller numbers only by breaking exactly those two properties.

Setup.We derive one controlled multi-entry bundle from the math skill: a rootSKILL.md, a catalogued public subskill atsub/SKILL.md, and four conditional references carrying full task contracts. We compare Uncompressed,SkillZip, the lossy Root-only and Flat-concat baselines, audited persistentSkillZip Pro, persistentSkillZip Prowithout the multi-entry audit, and transient execution-viewSkillZip Pro. Compression and view construction are deterministic and use no model calls; only the direct-call rollout in TableXIXuses the unmodified agent. Following SectionIII-E, persistent rows report disk and per-run cost. The transient row keeps disk at1.0001.000and reports runtime saving separately.

VI-U1Compressing without losing a single public entry

TableXVIIseparates methods that preserve a multi-entry bundle from those that do not. Standalone-preserving persistentSkillZip Proreduces the bundle to0.884of its bytes and per-run load from 404 to352tokens while keeping routing, mean public independence, and worst-case independence at1.000. The transient view keeps the same guarantees without changing disk. Root-only and flat-concat report smaller numbers only after breaking routing or removing public content. Disabling the multi-entry audit exposes the failure: persistentSkillZip Proreaches0.845on disk but renames the public subskill, reducing its effective independence to0.500. PropositionIV.1therefore applies at bundle scale: every declared entry, not the desired ratio, sets the safe persistent ceiling.

TABLE XVII:Persistent cost and multi-entry fidelity.Lower cost is better; higher routing and independence are better. Blue rows are valid; grey rows break routing or independence.

VI-U2Direct calls need the audit or a transient view

TableXVIIIisolates the failure. Without the audit, persistentSkillZip Proretains0.929of public-entry content but only0.500discoverability because it renames the public subskill. Audited persistent and transient modes remain at1.000on all four measures: one rejects hidden entries, and the other never edits them. Direct calls need one of these protections.

TABLE XVIII:Why a public entry loses independence(math bundle). “Discoverable” is whether a direct call still finds the entry (↑\uparrow); “Content” is how much of the found entry’s knowledge survives (↑\uparrow); “Effective” is their per-entry product, averaged—the number TableXVIIreports. “Cond.” is conditional-entry content. PersistentSkillZip Prowith the audit off loses capability byrenaminga public entry, not by deleting its text.The live rollout confirms this result. TableXIXcalls each entry through the unmodified agent. Without the audit, persistentSkillZip Procannot start the renamed public subskill (discoverability and standalone success are both0.0000.000), although unrenamed conditional references still run. Audited persistent and transient modes keep every entry discoverable; their standalone and root-mediated success matches uncompressed within this small rollout’s noise (n=3n{=}3for the public entry,n=8n{=}8per reference). Discoverability is deterministic: only the audit or a transient view prevents cross-file deduplication from hiding a public entry.

TABLE XIX:Direct-call rollout.Pub. disc. tests public-subskill startup; Pub., Cond., and Root report success by entry type. Discoverability is deterministic;n=3n{=}3public andn=8n{=}8per reference.

VI-U3Matching the four modes to update rate and call pattern

TableXXreports each workload boundary. Persistent load stays below transient load at every direct-call count because compression is paid once; stable, heavily used bundles favorone-shot persistent. A global repack costs 273 ms versus 183 ms for a local transient rebuild, so changing direct-call bundles favor cachedcontinual transientabove roughly one edit per ten runs. Figure12shows the crossover.

TABLE XX:Lifecycle sensitivity.Each row reports the measured boundary at which one lifecycle becomes cheaper or safer.Fig. 12:Which lifecycle is cheaper depends on the workload; both panels are drawn from the deterministic sweeps of TableXX.(a)As the edit rateUUrises, a persistent global repack (which re-audits the whole bundle) costs more rework per run than a transient local rebuild (which touches only the affected view); they tie for a stable bundle (U=0U{=}0), and transient is cheaper forU>0.1U>0.1.(b)For repeated direct calls to one stable public entry, a standalone-preserving persistent bundle pays its compression once and stays below a per-run transient view at every call countNN(log–log axes). Read together: a stable, heavily called bundle wants persistent; a frequently edited one wants transient.

VI-U4What a transient view costs to build and cache

Transient compression has overhead (TableXXI). The root-heavy entry saves24.8%; leaf references save under 2% because their closures share little content. Cold builds take 150–245 ms and warm reads under 2 ms, amortizing to 15–25 ms per call at a 0.9 hit rate. The non-improvinggeometry.mdentry uses its raw closure, and the canonical bundle remains byte-identical. A view helps only when its token saving exceeds build overhead.

TABLE XXI:Transient-view cost.Closure and View are tokens before and after compression. Cold, Warm, and Amort. report build latency; Built marks a smaller view, and Canon. confirms that the canonical bundle is unchanged.

VI-U5Which safeguards are load-bearing

TableXXIIremoves one safeguard at a time. Without entry labels, public independence falls to0.5000.500; without the multi-entry audit, a public entry becomes undiscoverable. Ignoring dependency closure drops 10 of 11 references, and missing host context reduces conditional independence to0.8870.887. Removing the view cache raises per-call build from 18.7 to 173.4 ms; removing global repacking moves the disk ratio from0.8450.845to0.9590.959. Under workload drift, persistent saving decays from 12.9% to 2.6%, while the transient view remains at 4.7%. Each safeguard therefore protects either a saving or a public call.

TABLE XXII:Lifecycle ablations.Each row removes one safeguard and reports the protected metric and resulting failure.TakeawaySkillZip Prois the only tested approach that compresses a multi-entry bundle without breaking routing or hiding a public entry. Audited persistent compression gives the smallest bundle and lowest steady-state run cost; transient compression preserves the canonical bundle and better tolerates drift, but pays per-run build cost. The lifecycles are complementary, and each safeguard protects either fidelity or efficiency.

VI-VAn Example in Industrial Compression Deployment

The preceding benchmarks use an instrumented wrapper to record which files the agent loads. We further evaluateSkillZip Proinside the production execution environment of a content-moderation service. Its skill bundle contains a root document of approximately20,000 tokens, three on-demand reference documents covering prior cases and moderation standards, and a locked risk map. The root is injected when the skill is activated, while reference files are loaded only when needed. Each audit involves approximately13 agent reasoning roundson average.

The official evaluation set contains100 real moderation tasks, evenly divided between violating and normal cases. Task content is retrieved at execution time and is not available locally, so both decision quality and runtime cost must be measured through the production harness. We report the binary moderation verdict using accuracy and false positives. The bundle is written in Chinese, which also exposes a practical limitation of language-specific protection rules: an English-only deterministic extractor identifies only7 of 264instruction units as required, leaving most Chinese obligations unprotected during compression.

Aggressive compression removes essential exemption knowledge.Without protection classes, deterministic and model-assisted compression reduce the deployed bundle by71.4%and75.8%, respectively. However, accuracy falls from88.00%for the paired uncompressed bundle to70.00%and62.00%. The errors are strongly asymmetric: false positives increase from 10 to 29–35, while false negatives remain between 1 and 3. An audit of the removed content shows that most losses occur inexemption rulesspecifying when content should not be flagged, including authorized-seller cases, whitelisted exceptions, and evidence thresholds. As fewer of these rules are retained, the false-positive rate increases.

Unprotected compression also damages the presentation of the output interface. Two worked JSON examples and the label whitelist are separated into synthetic sections approximately sixty lines apart, while renderer scaffolding remains in the root. Although the individual fragments still exist, neither the downstream parser nor the executing model receives the interface as one coherent contract.

Witnessed compression protects semantic and interface-critical content.We recompress the identical bundle while introducing the safeguards of SectionIV-Dincrementally. Exemption-bearing units are locked as class C1; obligation-bearing units are restored to the required class C2, so they can be modified only through witnessed transformations; and the output interface is re-emitted as one contiguous, verbatim C0 span. A removal is accepted only when supported by a logged witness:W1W_{1}for literal containment,W2W_{2}for coverage-preserving transformations, orW3W_{3}for entailment within evidence segments that contain no boundary marker.

Because the production harness may vary between sessions, each compressed configuration is evaluated against an uncompressed bundle in thesame session. The first uncompressed row in TableXXIIItherefore reports 88.00%, while the two sessions used by the final configuration have uncompressed baselines of 92.00% and 91.00%. For reference, the standalone official evaluation of the same uncompressed bundle reports 90.91%. TableXXIIIshows how compression changes as the protection mechanisms are introduced.

TABLE XXIII:Production evaluation under the service’s native execution harness. Deployment saving is measured over the shipped bundle. Per-run saving is task-paired within the same session over 100 tasks; the final row pools two sessions (n=200n{=}200). Accuracy and false positives are measured on the corresponding full evaluation set. The relevant uncompressed session baselines are 88.00%, 92.00%, and 91.00%.The incremental comparison supports four findings.

First, stronger witnesses expand the amount of content that can be removed safely.With C1/C2 protection and onlyW1W_{1}andW2W_{2},SkillZip Proreduces the deployed bundle by*13.8%*and achieves89.00%accuracy, one task above the paired uncompressed result, with one fewer false positive. Further candidates cannot pass these deterministic checks because their redundancy is semantic rather than literal. Adding the restrictedW3W_{3}entailment witness increases deployment saving to32.7%. The resulting accuracy and confusion matrix areidenticalto those of the paired uncompressed bundle. Each of the 106 removed reference segments has a logged entailment verdict, and none changes a decision on the 100-task evaluation. The increase in saving therefore comes from stronger evidence for removal, not from relaxing the acceptance criteria.

Second, interface integrity must be evaluated separately from task accuracy.The configuration usingW3W_{3}alone leaves the output contractfragmentedbecause the fixed-template renderer distributes its components across separate sections. The C0 restoration pass reconstructs a single contiguous span containing both worked examples and the label whitelist, while removing residual scaffolding. This repair reduces deployment saving only slightly, from 32.7% to 32.2%. Accuracy changes from 88.00% to 89.00%, which is insufficient to attribute an accuracy benefit to contiguity alone. The relevant result is instead that the published bundle once again exposes the complete contract in the form expected by its consumer, and that this property is now checked explicitly.

Third, compressing the repeatedly loaded root produces the largest runtime benefit.Because the root is processed throughout approximately 13 reasoning rounds, removing one root token saves roughly five to six times as many measured runtime tokens as removing one token from an on-demand reference. We therefore allow restrictedW3W_{3}witnesses inside the root, while continuing to protect frontmatter, interface contracts, and boundary-bearing segments. Two candidate deletions are also prohibited from serving as witnesses for each other. This configuration removes38.1%of the deployed bundle and reduces pooled, task-paired runtime tokens by10.4%overn=200n{=}200audits. Both compressed runs achieve89.00%accuracy, compared with same-session uncompressed baselines of 92.00% and 91.00%.

Fourth, static cost estimates do not fully capture changes in agent execution.The loading-weight model of SectionIIIpredicts approximately*3%*per-run saving, whereas paired production measurements range from6%to11%. A shorter root changes not only the number of loaded tokens but also the agent’s reading and repeated-reasoning behavior, neither of which is represented by the static model. A 30-task pilot varies from 6% to 14% across days, while two 100-task paired runs produce 9.5% and 11.3%, yielding the pooled result of10.4%. The static model is conservative in this deployment, but runtime claims should be based on paired measurements collected within the same execution session.

TakeawayOn the production moderation skill, witnessed compression removes38.1%of the deployed bundle and10.4%of pooled, task-paired runtime tokens while keeping accuracy within the observed variation of the uncompressed system. In contrast, the unprotected 71.4–75.8% configurations lose18–26 accuracy points, primarily through additional false positives.

Insight 5★The safe compression limit is determined by the evidence available for each removal.Literal and coverage witnesses provide only13.8%deployment saving, while restricted entailment witnesses raise it to32.7%; extending the same witnessed reasoning to the repeatedly loaded root raises the final saving to38.1%. The benefit is also amplified at execution time: although the static loading model predicts only3%per-run saving, the production engine measures6–11%because shorter root context reduces work across repeated reasoning rounds. Industrial compression should therefore be bothproof-boundandexecution-aware: remove content only when its redundancy is witnessed, and prioritize the context that the agent repeatedly processes.

VIIConclusion

SkillZip Procompresses the progressively loaded skill bundles used by production agents, including instructions, references, subskills, code, data, and assets. Host entailment, activation-scoped sharing, and conditional capsules remove cross-file redundancy without increasing activation or path cost. Before publication, a transactional disk audit verifies routing, typed contracts, scope, interface integrity, and locked content.

The compiler supports two independent choices.One-Shotcompression rebuilds the complete resource graph, whereasContinualcompression processes only the closure affected by each evolution patch.Persistentcompression rewrites the canonical bundle, whileTransientcompression preserves it and constructs a per-run execution view. These modes support different update frequencies and requirements for the independent usability of references and subskills, while remaining compatible with Phase-A deployment.

Across three benchmarks and a real industrial deployment,SkillZip Proreduces all four cost layers while preserving every routing pair and introducing no reference errors. Triggered Continual repacking achieves a result comparable to One-Shot rebuilding with approximatelyone thirdas many model calls per patch. In production, verification-gated compression removes38.1%of the deployed bundle and10.4%of measured per-run tokens without a measurable loss in decision quality. These results show that effective skill compression must preserve not only content, but also the loading structure through which agents access it.

References

• [1](2025)Claude Code: an agentic coding tool for the terminal.Note:https://docs.anthropic.com/en/docs/claude-code/overviewAccessed: 2026-07-25Cited by:§I.
• [2]OpenAI(2025)Codex: an agentic coding tool for the terminal.Note:https://github.com/openai/codexAccessed: 2026-07-25Cited by:§I.
• [3]G. Wang, Y. Xie, Y. Jiang, A. Mandlekar, C. Xiao, Y. Zhu, L. Fan, and A. Anandkumar(2023)Voyager: an open-ended embodied agent with large language models.Transactions on Machine Learning Research.Cited by:§I,§II.
• [4]N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao(2023)Reflexion: language agents with verbal reinforcement learning.InAdvances in Neural Information Processing Systems,Vol.36.Cited by:§I,§II.
• [5]Q. Zhang, C. Hu, S. Upasani, B. Ma, F. Hong, V. Kamanuru, J. Rainton, C. Wu, M. Ji, H. Li, U. Thakker, J. Zou, and K. Olukotun(2025)Agentic context engineering: evolving contexts for self-improving language models.arXiv preprint arXiv:2510.04618.Cited by:§I,§II.
• [6]H. Gao, J. Geng, W. Hua, M. Hu, X. Juan,et al.(2025)A survey of self-evolving agents: on path to artificial super intelligence.arXiv preprint arXiv:2507.21046.Cited by:§I.
• [7]H. Jiang, Q. Wu, C. Lin, Y. Yang, and L. Qiu(2023)LLMLingua: compressing prompts for accelerated inference of large language models.InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,pp. 13358–13376.Cited by:§I,§II.
• [8]H. Jiang, Q. Wu, X. Luo, D. Li, C. Lin, Y. Yang, and L. Qiu(2023)LongLLMLingua: accelerating and enhancing llms in long context scenarios via prompt compression.arXiv preprint arXiv:2310.06839.Cited by:§I,§II.
• [9]Z. Pan, Q. Wu, H. Jiang, M. Xia, X. Luo,et al.(2024)LLMLingua-2: data distillation for efficient and faithful task-agnostic prompt compression.InFindings of the Association for Computational Linguistics: ACL 2024,Cited by:§I,§II.
• [10]Y. Gao, Z. Li, Y. Yuan, Z. Ji, P. Ma, and S. Wang(2026)SkillReducer: optimizing llm agent skills for token efficiency.arXiv preprint arXiv:2603.29919.Cited by:§I,§II.
• [11]X. Bai, H. Lin, C. Liu, Y. Zhang, X. Jin, X. Cao, and Y. Li(2026)SkillZip: evaluation-free skill compression for self-evolving agents by discovering reusable structure.External Links:2608.11079,LinkCited by:§I.
• [12]Y. Liu, Z. Su, L. Xie, Y. Zhang, Q. Zong, J. Guo, Z. Xie, Y. Ji, Y. Yim, H. Luo, X. Ren, R. Chenyu, H. Li, and Y. Song(2026)SkillRevise: improving llm-authored agent skills via trace-conditioned skill revision.arXiv preprint arXiv:2606.01139.Cited by:§II.
• [13]H. Wang, Y. Lan, B. Cao, L. Lin, and J. Chen(2026)SkillGrad: optimizing agent skills like gradient descent.arXiv preprint arXiv:2605.27760.Cited by:§II.
• [14]Y. Yang, Z. Gong, W. Huang, Q. Yang, Z. Zhou, Z. Huang, Y. Li, X. Gao, Q. Dai, B. Liu, K. Qiu, Y. Yang, D. Chen, X. Yang, and C. Luo(2026)SkillOpt: executive strategy for self-evolving agent skills.arXiv preprint arXiv:2605.23904.Cited by:§II,§VI-B.
• [15]X. Zhang, M. Gao, Y. Zhao, X. Tan, Y. Yao, F. Wang, Y. Wang, Dingsiyi, and T. Yang(2026)Formal skill: programmable runtime skills for efficient and accurate llm agents.arXiv preprint arXiv:2605.19604.Cited by:§II.
• [16]Y. Li, B. Dong, F. Guerin, and C. Lin(2023)Compressing context to enhance inference efficiency of large language models.InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing,pp. 6342–6353.Cited by:§II.
• [17]J. Mu, X. L. Li, and N. Goodman(2023)Learning to compress prompts with gist tokens.InAdvances in Neural Information Processing Systems,Vol.36,pp. 19327–19352.Cited by:§II.
• [18]F. Xu, W. Shi, and E. Choi(2024)RECOMP: improving retrieval-augmented lms with compression and selective augmentation.InInternational Conference on Learning Representations,Cited by:§II.
• [19]T. Zhang and Z. Qi(2026)Skill-to-lora: from using skills to learning behaviors for token-efficient llm agents.arXiv preprint arXiv:2606.16769.Cited by:§II.
• [20]L. Chen, E. Feng, Y. Xia, and H. Chen(2026)SkillRT: compiling skills for efficient execution everywhere.arXiv preprint arXiv:2604.03088.Cited by:§II.
• [21]P. D. Gr“unwald(2007)The minimum description length principle.MIT Press.Cited by:§II.
• [22]E. Galbrun(2022)The minimum description length principle for pattern mining: a survey.Data Mining and Knowledge Discovery36(5),pp. 1679–1727.Cited by:§II.
• [23]C. G. Nevill-Manning and I. H. Witten(1997)Identifying hierarchical structure in sequences: a linear-time algorithm.Journal of Artificial Intelligence Research7,pp. 67–82.Cited by:§II.
• [24]N. J. Larsson and A. Moffat(2000)Off-line dictionary-based compression.Proceedings of the IEEE88(11),pp. 1722–1732.Cited by:§II.
• [25]S. G. Patil, H. Mao, F. Yan, C. C. Ji, V. Suresh, I. Stoica, and J. E. Gonzalez(2025)The berkeley function calling leaderboard (BFCL): from tool use to agentic evaluation of large language models.InProceedings of the 42nd International Conference on Machine Learning,Proceedings of Machine Learning Research, Vol.267,pp. 48371–48392.Cited by:§VI-B.
• [26]Gorilla Team(2026)Berkeley function calling leaderboard v4.Note:https://gorilla.cs.berkeley.edu/leaderboard.htmlAccessed 2026-07-20Cited by:§VI-B.
• [27]L. He, Q. Yu, H. Dong, B. Liao, X. Xu, M. Goldblum, J. Bian, and N. Mesgarani(2026)LiveMathematicianBench: a live benchmark for mathematician-level reasoning with proof sketches.arXiv preprint arXiv:2604.01754.Cited by:§VI-B.
• [28]L. He, Q. Yu, H. Dong, B. Liao, X. Xu, M. Goldblum, J. Bian, and N. Mesgarani(2026)LiveMathematicianBench: a live benchmark for mathematician-level reasoning with proof sketches.arXiv preprint arXiv:2604.01754.Cited by:§VI-B.
• [29]Z. Ma, B. Zhang, J. Zhang, J. Yu, X. Zhang, X. Zhang, S. Luo, X. Wang, and J. Tang(2024)SpreadsheetBench: towards challenging real world spreadsheet manipulation.InAdvances in Neural Information Processing Systems,Vol.37.Cited by:§VI-B.
• [30]Qwen Team(2026)Qwen3.7: the agent frontier.Note:Qwen Research BlogIntroduces the Qwen3.7 series, including Qwen3.7-Max. Accessed: 2026-07-23External Links:LinkCited by:§VI-C.
• [31]Qwen Team(2026)Qwen3.6-Plus: towards real world agents.Note:Qwen Research BlogAccessed: 2026-07-23External Links:LinkCited by:§VI-C.
• [32]Moonshot AI(2026)Kimi K2.6: advancing open-source coding.Note:Kimi Technical BlogAccessed: 2026-07-23External Links:LinkCited by:§VI-C.

Appendix AImplementation Details

Appendix roadmapThis appendix fixes the implementation contract needed to reproduce Phase A. It specifies bundle discovery, reference resolution, candidate layout, the cost ledger, auditing, atomic publication, and Zip-on-Write invalidation. AppendixBgives machine-readable schemas and prompt contracts; AppendixCgives the run matrix; AppendixDexpands theory, limitations, and failure analysis.

A-AReference Directory Layout

The implementation treats the authoritative source directory as immutable during a transaction and creates all intermediate and persistent compiler state outside the published runtime bundle. A successful publication uses the following split layout:

<published-bundle>/

SKILL.md#unchangedentrypath

references/...

subskills/.../SUBSKILL.md

capsules/<guard-slug>.md#generatedon-demandtext

.skillzip_shared/<hash>.md#generatedscopedmodules

scripts/...#byte-identical

data/...#byte-identical

assets/...#byte-identical

<compiler-cache>/<bundle-id>/

state.json#graph,indices,workloadledger

manifest.json#provenanceandauditresults

contracts/<digest>.json#reusabletypedcontracts

authored.snapshot#optionaltransactionalsourcesnapshot

Generated runtime directories are namespaced to avoid collisions. If either namespace already exists in the source, the tool selects a digest-suffixed namespace and records it in the external manifest. Nested sourceSKILL.mdfiles are treated as subskill entries internally; the published filename is changed only when the original harness acceptsSUBSKILL.md. The default is path preservation. Compiler state is not distributed to the agent and is therefore not charged to runtime deployment cost; a reproducibility package that includes it reports payload bytes and total archive bytes separately.

A-BDiscovery and Media Classification

Directory traversal is deterministic: paths are normalized to UTF-8 NFC, sorted bytewise, and visited without following directory symlinks. Content signatures and extensions classify regular files. Declared text types support contract extraction; code, notebooks, structured data, images, archives, and unknown binaries remain locked.

Every node stores:

• •canonical path relative to the bundle root;
• •SHA-256 of source bytes and media classification;
• •token and byte counts;
• •loading class and inbound/outbound edges;
• •whether rewrite, relocation, or only verbatim copy is permitted.

The default text-size guard is 1 MiB per file. Larger text remains locked unless the user explicitly raises the limit. Archive members are never expanded implicitly.

A-CReference Resolution

The Phase-A resolver recognizes only syntax that the host agent can already follow:

1. 1.Markdown links and images with relative local targets;
2. 2.explicit code-formatted paths ending in a known extension;
3. 3.front-matter fields declared by the selected skill format;
4. 4.imperative loading clauses such as “readreferences/csv.md.”

Fragments and query strings are separated before filesystem resolution and restored in the emitted link. Percent decoding is performed once; double decoding is forbidden. The canonical target must have the canonical root as a path-component prefix, not merely a string prefix.

The nearest enclosing heading and conditional clause define the initial guard. If guard extraction is ambiguous, the edge is markedunknown; it may be preserved but cannot justify capsule creation or path-specific sharing. Externalhttp,https, andmailtolinks are preserved as opaque strings and excluded from local closure checks.

A-DContract Extraction and Normalization

Files are chunked only at heading boundaries, with a 256-token overlap carrying the parent heading and active guard. Each chunk is extracted once. Units are merged by source span and normalized key; disagreements retain the stricter wording as a locked residual. The implementation never resolves a disagreement by majority vote.

Normalization is type specific. Tool calls normalize tool name, required arguments, and order. Output obligations normalize field name, type, and cardinality. Prohibitions preserve polarity. Workflow units form a directed graph whose edges encodebefore,after,retry, orfallback. Examples are tagged as non-normative unless the source explicitly declares them required.

A-EProtection Classes, Witnesses, and Non-Latin Bundles

The production configuration in SectionVI-Vadds three implementation requirements.

Script-aware lexical signals.Modality and requirement detection are lexical: obligation, prohibition, and recommendation markers drive which units are required. The reference implementation ships with English marker sets, which on a Chinese bundle demotes almost every obligation to optional (7 of 264 units required on the production skill). The fix is script-aware signal sets—obligation and prohibition markers per writing system—applied in the same deterministic extractor, so required-unit detection works before any witness is consulted. The English path is unchanged byte for byte.

Boundary classes and the exemption lock.Units whose payload carries an exemption or negative-verdict marker (authorized cases, whitelisted exceptions, “judge normal” clauses) are classified as boundary units. Boundary units are required and additionally locked against wording compression and againstW3W_{3}entailment removal: they may only be moved verbatim. Markers are a configurable lexicon per language; the audit counts them so a release reports boundary retention explicitly.

Interface-contract restoration.After materialization, a post-pass locates each source section matching the interface-contract pattern (output-format headings with fenced schema examples and whitelist constraints), strips any of its normalized lines that the fixed-template render scattered elsewhere in the emitted root, removes render-scaffolding sentences, and re-inserts the whole source span verbatim at one site. The audit then verifies contiguity: the section must appear once, whole, with no fragments outside it.

Entailment witness protocol (W3W_{3}).The checker prompt presents the emitted root documentSSand one candidate reference segmentPP, and asks whether the decision-relevant content ofPP—conditions, verdicts, thresholds, whitelists, exemptions—is fully expressed inSS, explicitly instructing that concrete case facts need not reappear but the rule they demonstrate must. The checker runs at temperature00with a fixed prompt; the first response line must be the verdict and the second a one-sentence basis. A verdict is accepted only for evidence-class segments containing no boundary marker, and the verdict, basis, segment coordinates, and prompt digest are written to the witness log, making everyW3W_{3}removal individually auditable after publication.

Intra-root witnesses and their safeguards.W3W_{3}may also be applied inside the root document, where each candidate is checked against the rootminus itself. Three safeguards apply. (i) The YAML frontmatter and every interface-contract span are exempt fromW3W_{3}regardless of verdict: they carry no decision knowledge a checker can weigh, yet they are the loading and output contract. (ii) Boundary segments remain exempt. (iii) A mutual-witness veto: after verdicts are collected, any two approved segments whose normalized bigram sets overlap above0.60.6are both retained, since each may have received its verdict only because the other was still present in the base. Because the root is injected into every reasoning round, intra-root removals carry the largest per-run multiplier, and the veto plus the exemptions are what keep that lever safe.

A-FCandidate Enumeration

File-level candidates are primitive statements, shared rules, named procedures, guarded exceptions, and locked residual spans. Bundle-level candidates are exact host witnesses, shared modules, and capsules.

Cross-file sharing uses a two-stage test. A hash over canonical typed units finds exact candidates; a deterministic structural comparator then verifies identical type, payload, guard parameters, and normative strength. Parameterized sharing is allowed only when differing values correspond to explicit source variables and the resulting call sites preserve them. Pure embedding similarity never creates an automatic shared module.

For each support set, the algorithm considers the lowest common activation scopes in the resource graph rather than only the directory ancestor. A scope candidate is discarded if it would be loaded by a path that previously loaded none of the occurrences, unless the added path cost is compensated under Eq. (7) and the rule is proven universally applicable. The production default disables this exception and requires no scope expansion.

Capsule candidates require all of the following: an explicit guard, a body above the minimum length, no unguarded inbound dependency from adjacent prose, and a dispatcher whose mandatory loading instruction fits within the configured budget. Headings such as “Background” or “Notes” do not constitute guards.

A-GSelection and Cost Ledger

Candidate deltas use tokenized emitted text, including links, dispatcher verbs, generated headings, and manifest-excluded runtime content. Selection starts with the best coverage-preserving improvement, then tests removals and one-for-one or one-for-two swaps untilJJcannot improve by one token.

The ledger stores both estimated and materialized values:

{

“tokenizer”:{“name”:“...”,“revision”:“...”},

“lambda_deployment”:0.05,

“path_weights”:{“source”:“trace|guards”,“digest”:“...”},

“source”:{“catalog”:0,“activation”:0,

“deployment”:0,“mean_path”:0,“p95_path”:0},

“candidate”:{“catalog”:0,“activation”:0,

“deployment”:0,“mean_path”:0,“p95_path”:0},

“objective_delta”:0

}

Estimated and materialized costs must agree exactly for bytes and within tokenizer determinism for tokens. A discrepancy rejects the candidate.

A-HDisk-Level Audit

The audit runs in a new process with only the source path, candidate path, and manifest as inputs. This prevents it from trusting optimizer objects accidentally. It rebuilds both graphs, rehashes every node, and verifies:

1. 1.source and candidate roots are distinct and canonical;
2. 2.all internal candidate targets exist, remain inside the root, and preserve fragments;
3. 3.every source contract unit maps to a compatible candidate unit or exact host witness;
4. 4.every generated shared module or capsule is reachable through a mandatory dispatcher under a compatible guard;
5. 5.locked-file path and SHA-256 pairs match, except for explicitly user-approved path migrations;
6. 6.no source file has been omitted merely because it was unreferenced;
7. 7.every interface contract appears as one contiguous span equal to its source section, with no scattered fragments;
8. 8.materialized costs do not exceed the source objective.

Strict mode treats any warning as failure. Diagnostic mode emits the candidate for inspection but never publishes it as a successful compression.

A-IAtomic Publication and Recovery

The tool creates a temporary sibling directory so that final rename remains on one filesystem. It fsyncs files, the manifest, and containing directories before publication. If the destination exists, the default command fails; explicit--replacefirst renames the old output to a timestamped backup. The source is never overwritten.

On one-shot extraction, selection, materialization, or audit failure, the official output is a verbatim copy of the source with an external failure manifest. On a continual optimization failure after a patch has been applied successfully, the official output is the verbatim patched bundle. Only a failure to apply or validate the patch transaction itself leaves the previous publication active. A temporary directory may be retained for debugging only under an explicit flag. This behavior makes failure visible while preserving the current authored semantics.

A-JDual-Mode Driver and Bundle-Aware Zip-on-Write

The command exposes--mode one-shotand--mode continual. One-shot requires only the source and entry path; it rebuilds all compiler state. Continual additionally requires the previous bundle identifier, state digest, and an incoming patch. A missing, corrupt, or source-mismatched state never causes an unsafe partial update: the driver applies the patch verbatim and switches to one-shot compression of that current authored state.

An incoming patch identifies added, modified, moved, and deleted paths. Before optimization, the tool creates a raw patched snapshot and validates patch preconditions and expected hashes. The invalidation closure contains changed nodes, their reference ancestors, newly or formerly referenced descendants, shared modules whose support sets changed, capsules whose guard spans changed, and environment witnesses whose digest changed. Extraction and candidate generation rerun only on this closure. Global reference, coverage, and hash checks still scan the full candidate, while unchanged file contracts are reused by source digest.

Each patch unit is classified asAbsorb,Refine,Extend, orRefactor. The first three update semantic content.Refactormay also change placement when a support set, guard, or path weight crosses the sharing or capsule threshold. The driver estimates recoverable saving from stale candidates and invokes one-shot repacking when any configured trigger is reached:θrepack\theta_{\mathrm{repack}}saving,ρ\rhogrowth,δW\delta_{W}workload drift, environment-digest change, orKKpatches. Trigger values and causes are logged in the state transition.

Deletion is especially conservative. A shared module is deleted only after all inbound dispatchers are removed and the recomputed coverage graph shows no remaining source unit depends on it. If compression of a valid raw patch fails, the raw patched snapshot is atomically published and a clean state is rebuilt from it. Thus a patch can reduce compression temporarily but cannot disappear because the optimizer rejected its rewrite.

Appendix BSchemas and Model Contracts

This appendix records the structured interfaces used by the extractor and rewriter. Prompts are templates; implementations should pin the system message, model snapshot, JSON validator, and retry policy.

B-AResource-Graph Record

{

“bundle_digest”:“sha256:...”,

“entry”:“SKILL.md”,

“nodes”:[{

“id”:“n17”,

“path”:“references/csv.md”,

“sha256”:“...”,

“media_type”:“text/markdown”,

“kind”:“reference”,

“locked”:false,

“token_count”:412

}],

“edges”:[{

“source”:“n1”,“target”:“n17”,

“source_span”:[88,126],

“syntax”:“markdown_link”,

“guard”:{“text”:“whenexportingCSV”,“status”:“explicit”}

}],

“external_edges”:[],

“unresolved”:[]

}

Line/byte offsets are measured against immutable source bytes. A graph containing an unresolved local reference cannot enter strict compression.

B-BTyped Contract Record

{

“resource_id”:“n17”,

“units”:[{

“unit_id”:“n17:u4”,

“type”:“output_obligation”,

“key”:“csv.encoding”,

“payload”:{“value”:“UTF-8”,“strength”:“must”},

“scope”:{“resource”:“n17”,“guard”:“exportCSV”},

“source_spans”:[[241,274]],

“confidence”:“high”,

“locked”:false

}],

“relations”:[{

“kind”:“before”,

“source_unit”:“n17:u2”,

“target_unit”:“n17:u4”,

“source_spans”:[[178,274]]

}]

}

Allowed unit types areinterface,workflow,tool,rule,prohibition,output_obligation,evidence, andlocked_residual. The validator rejects unknown types and units without source spans.

B-CEnvironment Contract and Witness

{

“environment_digest”:“sha256:...”,

“guarantees”:[{

“type”:“output_obligation”,

“key”:“csv.encoding”,

“value”:“UTF-8”,

“scope”:“all_spreadsheet_exports”,

“enforced_by”:“serializer/v3”,

“evidence_digest”:“sha256:...”

}]

}

A removal witness stores the source unit, guarantee index, exact comparison result, and environment digest. Natural-language descriptions of the host are not accepted as contracts.

B-DExtraction Prompt Contract

Contract extractionYou are extracting an auditable behavioral contract from ONE resource in an agent-skill bundle.Inputs: canonical resource path; ancestor headings; explicit loading guard; immutable source text with byte offsets; resource-graph neighbors.Return JSON matching the supplied schema. Extract every applicability condition, ordered workflow step, tool/resource requirement, normative rule, prohibition, output obligation, verification/evidence requirement, and ambiguous residual. Attach exact source spans. Preserve polarity, strength, and guard. Mark uncertain or non-decomposable text as locked_residual.Do not rewrite the resource. Do not infer requirements from world knowledge. Do not treat an example as normative unless the source explicitly does. Do not invent references or guards. Output JSON only.

B-ECandidate Rewrite Prompt Contract

File rewriteRewrite the supplied Markdown resource using ONLY the selected representation plan and mapped source units.Hard requirements: (1) preserve every selected typed unit at the specified scope and normative strength; (2) preserve every locked residual verbatim; (3) emit each provided relative path exactly; (4) for a capsule/shared module, keep the supplied explicit guard and mandatory read instruction; (5) do not add tools, claims, examples, branches, or host assumptions; (6) return one Markdown file with no commentary.If the plan is inconsistent or omits a mapped unit, return PLAN_REJECTED with the unit IDs.

The implementation does not rely on the rewriter to calculate coverage. It re-extracts and audits the emitted text.

B-FAudit Prompt Contract

Most audit checks are deterministic. A model is used only for semantic coverage pairs not discharged by exact normalization.

Semantic coverage adjudicationGiven one source unit and one candidate unit, decide whether the candidate entails the full source requirement under the same or narrower compatible scope.Return: COVERED, NOT_COVERED, or UNCERTAIN; a type match; a polarity/strength match; a scope match; and the minimal text spans supporting the decision.Rules: examples do not cover obligations; recommendations do not cover MUST; broader applicability cannot be assumed from a narrower branch; external knowledge and model plausibility are forbidden. UNCERTAIN is treated as NOT_COVERED by strict mode. Output JSON only.

B-GTransformation Manifest

{

“format_version”:“skillzip-pro/1”,

“phase”:“A”,

“source_digest”:“sha256:...”,

“output_digest”:“sha256:...”,

“models”:{“extractor”:“...”,“rewriter”:“...”,“auditor”:“...”},

“graph”:{“nodes”:0,“edges”:0,“unresolved”:0},

“transformations”:[

{“kind”:“host_entailment”,“units”:[],“witness”:“...”},

{“kind”:“scoped_share”,“units”:[],“scope”:[],“path”:“...”},

{“kind”:“capsule”,“units”:[],“guard”:“...”,“path”:“...”},

{“kind”:“file_cover”,“resource”:“...”,“units”:[]}

],

“cost_ledger”:{},

“audit”:{“passed”:true,“checks”:[],“fallback”:false}

}

The manifest is not required at agent runtime. It exists for provenance, regression testing, and exact reconstruction of experimental measurements.

Appendix CDetailed Experimental Protocols

C-APre-registration Sequence

The evaluation follows a fixed order to prevent test leakage:

1. 1.freeze benchmark versions, evolution/validation/test IDs, and task-template groups;
2. 2.construct native and structured-growth source bundles using only evolution tasks;
3. 3.freeze the bundle builder, path annotations, environment contracts, and source digests;
4. 4.tune only declared thresholds on validation tasks;
5. 5.freeze compressor code, prompts, model snapshots, tokenizers, and non-inferiority margin;
6. 6.run every compressor on the same source digests;
7. 7.audit outputs before any held-out execution;
8. 8.execute all valid or fallback outputs on paired held-out tasks;
9. 9.generate tables directly from immutable raw records.

Any post-freeze repair creates a new experiment revision and reruns all affected baselines.

C-BBundle Construction Checks

The structured-growth builder moves contiguous source spans into references or subskills and replaces them with explicit guarded links. Before compression, three checks establish that this transformation is not itself responsible for performance changes: (i) concatenating files in provenance order recovers all normative source spans; (ii) every moved span has exactly one reachable dispatcher; and (iii) the evolved flat skill and the structured bundle are compared on validation tasks under the same executor. A task-score difference above one percentage point triggers manual review and rebuilding.

Each benchmark includes at least four branch types: a common path, a rare format/tool path, a verification path, and a recovery path. Path-frequency scenarios include observed validation traces, uniform leaf paths, and a skewed stress distribution with 80% mass on the common path. This separates gains from bundle structure from gains tied to one traffic assumption.

C-CGold Resource Sets

For each held-out task, annotators identify the minimal set of source resources required to satisfy the explicit task and benchmark rubric. They may inspect the task, source bundle, tool schema, and official expected behavior, but not any compressed output. A second annotator independently labels a stratified 20% sample covering all branches. Disagreements are adjudicated before execution; Cohen’sκ\kappaand raw agreement are reported.

A resource is required if omitting it removes a unique normative unit needed by the task. Redundant references are marked acceptable alternatives rather than jointly required. Scripts invoked by a required workflow count as required even if their source code is not injected into the model context.

C-DRun Matrix

The full factorial matrix is summarized in TableXXIV. Budget-matched and native-cost comparisons are separate run groups. The no-skill condition is executed but not compressed.

TABLE XXIV:Minimum run matrix before stochastic seeds.For the main table, compressor model and traffic estimator are fixed in advance, reducing the execution grid to all methods, benchmarks, tracks, executors, tasks, and seeds. The full compressor–executor cross product is used only for RQ4.

C-EHarness Instrumentation

Instrumentation records timestamp, task ID, selected skill, read path, read result, byte count, model-token count, caller action, and current branch label. It does not expose gold paths to the agent. Catalog and root injection are recorded as synthetic events emitted by the existing harness; auxiliary loads are recorded at the ordinary file-reading boundary.

Two validation tests are mandatory. Thevisibility testverifies that the agent cannot read the trace buffer. Theequivalence testreplays a fixed set of actions with instrumentation on and off and compares all task-visible observations byte-for-byte. Hashes of the harness executable and configuration accompany each trace.

C-FTask Execution and Failure Policy

A compression-time exception, audit rejection, or timeout produces the original bundle as the executable fallback. Its task score and uncompressed costs remain in the method’s aggregate; excluding failed cases would reward unsafe aggressiveness. An execution-time missing file, invalid path, or unavailable generated module counts as both task failure (when it prevents completion) and a loading error.

Task timeouts and transient provider failures are distinguished. A provider failure is retried under the same seed up to the predeclared limit; a reproducible model or agent failure is not retried. Every exclusion is listed by task ID and reason.

C-GMetric Computation

Catalog and activation cost are deterministic functions of published files. Deployment cost includes all files distributed to the agent except the audit manifest when the production package explicitly excludes it; both inclusive and runtime-package counts are recorded. Path cost is calculated from actual load events, including duplicate loads. Mean and P95 are paired over identical tasks.

For a tasktt, required-file recall is defined as one whenRtR_{t}is empty. Irrelevant-load rate is zero whenLtL_{t}is empty. Generated shared modules inherit the union of source-unit annotations they cover, allowing them to count as a valid substitute for original resources. A capsule is relevant only when its guard is active for the task.

Quality macro-averages first within benchmark categories, then across the three benchmarks, preventing a large benchmark from dominating. Compression ratios are computed from summed token costs before averaging; we additionally report median per-bundle reduction to reveal size effects.

C-HConfidence Intervals and Tests

The task is the resampling unit. Paired bootstrap samples preserve all method outcomes, path costs, and seeds for a task. The primary comparison isSkillZip Proversus Evolved Bundle for quality and versus Root-onlySkillZipfor mean-path reduction. Secondary comparisons cover other baselines and cost layers.

We declare quality non-inferiority when the lower bound of the paired 95% interval exceeds−0.01-0.01. Only after non-inferiority is established do we test compression superiority. McNemar’s test operates on paired binary outcomes; multi-level official scores use paired bootstrap or permutation tests. Holm correction is performed separately within RQ2–RQ7.

C-ITable Population Contract

Every cell in SectionVIis emitted by the table script from a row-oriented result file; nothing is transcribed by hand. The pipeline writes one JSONL record per (benchmark, track, method) with the following shape, and the script renders each table body from those records:

{

“benchmark”:“...”,“track”:“native|structured”,

“method”:“pro|root_only|flat_concat|skillreducer|expert|...”,

“cost”:{“catalog_tokens”:0,“activation_tokens”:0,

“deployment_text_tokens”:0,“path_mean_tokens”:0.0,

“path_max_tokens”:0,“path_count”:0},

“J”:0.0,

“reductions”:{“catalog”:0.0,“activation”:0.0,

“deployment”:0.0,“mean_path”:0.0,

“max_path”:0.0,“J”:0.0},

“loading”:{“orphaned_modules”:0,“ref_errors”:0,

“dangling”:0,“unsafe”:0,“reachable_files”:0},

“routing”:{“pairs_before”:0,“pairs_exact_kept”:0,

“routing_fidelity”:0.0},

“efficiency”:{“time_s”:0.0,“compress_calls”:0,

“rollouts”:0,“peak_gb”:0.0},

“report”:{“selected_verbatim”:false,“audit_ok”:true,

“promotions_count”:0,“capsules_count”:0,

“env_drops_count”:0}

}

Quality and behavioral-loading records are stored separately, keyed by the same (benchmark, track, method) triple plus an executor field, and carryaccuracy,required_recall,irrelevant_load,dispatch, and the per-task read traces. Continual records add the per-patch trajectory withJ⁡(Btone)J(B_{t}^{\mathrm{one}}),J⁡(Btcont)J(B_{t}^{\mathrm{cont}}), the regret of Eq. (14), and an explicit repack flag.

The generated artifacts are:costs.jsonl(method costs and loading structure),ablations.jsonl,quality.jsonl,transfer.jsonl,continual.jsonl,lambda_sweep.jsonl, andrepack_sensitivity.jsonl. A failed compression remains in the denominator and is represented by the cost of its verbatim fallback, which the record marks withselected_verbatim.

C-JZip-on-Write Replay

Each evolution patch is a transaction with timestamp, added/modified/moved/deleted paths, inserted source spans, and expected source digest. All schedules see patches in identical order and operate on the same verbatim authored checkpoint: append-only, Pro One-Shot after every patch, root-onlySkillZipZip-on-Write, Pro Continual without repacking, and Pro Continual with the combined repack policy. We checkpoint after every patch and measure changed contract units, invalidation-closure size, reused-contract fraction, rewritten bytes, model calls, update latency, four costs, objective regret, audit outcome, fallback type, and validation quality. Held-out test quality is measured only at predeclared checkpoints to avoid adaptive tuning to the test set.

The growth plot uses patch index on the horizontal axis and reports absolute tokens, not only normalized reduction. Additional panels report objective regret, cumulative compression cost, and closure fraction so that frequent small updates are not favored by hiding total overhead. Repack events and their trigger causes are overlaid. Every rejected compression is checked automatically to ensure that the published fallback digest equals the verbatim patched snapshot, not the previous version.

C-KExact Setup of the Reported Runs

This subsection records, in full, the configuration behind every number in SectionVI, so that a reader can reproduce it without reading the code.

Bundle tracks.Three tracks are used. (i)Plain: the evolved class skills assembled into a root with a routing list, one reference per class, one class as a nested subskill, and one locked helper script. (ii)Grown: the same skills with evolution patches replayed into named branches, which re-append the output rules, the verification checklist and the accumulated pitfall list into every branch, plus one file of long guarded edge cases. A deterministic builder records the source span and patch identifier of every moved section and never rewords text. (iii)Real evolved libraries: three self-evolution runs stored with the project, each keeping all of its rounds as separate files, giving 17 files, 15 rounds, roughly 20,000 tokens, and 79–84% repeated text. Main cost tables use the grown track; SectionsVI-M–VI-Ouse the real libraries.

Held-out task counts.Math 33, BFCL 21, SpreadsheetBench 48, giving 102 tasks pooled. The same tasks are used for every method within a benchmark, which is what makes the paired test valid. SpreadsheetBench is sampled at twice the density of the other two because its verdict is the strictest (a task passes only if every one of its test cases reproduces the gold range), so single-task flips dominate at smallnn; atn=24n=24the ordering between the compressed and uncompressed bundles turned on one task, and doubling the sample removed that artefact without changing any method’s configuration. BFCL runs with its offline search tool enabled; without the tool the skill provides no measurable benefit on that benchmark (no skill and the uncompressed library score identically), so that configuration cannot separate compression methods and is not used.

Compressor configuration.Structural extraction and structural audit (no model calls), capsule minimum 40 tokens, shortest repeated statement worth factoring 8 tokens, storage weightλ=0.05\lambda=0.05, navigation locked, literal blocks locked, and pre-existing source reference defects tolerated but never introduced. Every method receives the identical source bundle and the identical environment contract.

Environment contract.Guarantees are only those the benchmark harness itself puts in front of the agent on every task, quoted from the harness: for math, “Solve the PROBLEM and end with the final result on its own line as\boxed{...}”; for BFCL, “Decompose it into ordered hops and resolve each one” and “end with a line EXACTLY in the form ‘ANSWER: <short answer>’ ”; for SpreadsheetBench, “Read the workbook at path IN and write the modified workbook to path OUT”, “Respond with ONErun_pythonblock … the variables IN and OUT are predefined”, and “write general logic (do not hard-code values you can compute)”. A statement the harness does not supply is never listed as a guarantee, because removing it would take away a rule the agent still needs.

Knowledge kept.A content unit is one behaviour-bearing line of the source (a bullet or sentence of at least a few words, excluding headings and fenced code). A unit counts as kept if its wording still appears, verbatim or lightly reworded, in a file the agent can reach by following links from the root; matching accepts either high local edit similarity or high local coverage of the unit’s content words inside one window, so moving a qualifier is not scored as a loss while scattering words across unrelated files is. Units removed under the environment contract are reported separately as witnessed removals.

Continual replay.Rounds are appended one at a time in evolution order. All five schedules start from the identical state and see the identical rounds. Repacking runs every fourth round after compression is switched on. Drift is the relative difference in objective against rebuilding the whole library at that same round. Model calls are counted as one per changed textual node for a local update and one per textual node for a rebuild.

Start-time ablation.Compression is switched on at roundk∈{1,4,7,10,13}k\in\{1,4,7,10,13\}, and for comparison never. Everything else is held fixed. The reported total is the sum, over rounds, of the per-run cost of the library published at that round, which is what an agent actually pays while the library evolves.

C-LCompounding Analysis (SectionVI-P)

The three findings behind the compounding effect are computed from the same full-resolution real evolved libraries used for the continual study, with no new model calls. For each roundkkwe build the prefix holding the firstkkrounds, measure its raw shipped sizeU⁡(k)U(k), compress it one-shot withSkillZip Proto sizeC⁡(k)C(k), and record both. The compression ratio at roundkkis1−C⁡(k)/U⁡(k)1-C(k)/U(k)(Figure9a). The repeated share of roundkkis1−(C⁡(k)−C⁡(k−1))/(U⁡(k)−U⁡(k−1))1-\big(C(k)-C(k-1)\big)/\big(U(k)-U(k-1)\big): the numerator is the genuinely new text the compressor kept, the denominator is all text the round added, so their complement is the fraction of the round that was already present (Figure9b). Reuse concentration counts, for each shared moduleSkillZip Procreated, how many strategy files link to it, sorted descending (Figure9c). We report the two libraries whose one-shot compression cleared the never-inflate check at every prefix; the third is excluded because at some prefixes its candidate did not beat the source and was republished verbatim, which would report a0%0\%ratio that reflects the safety guard rather than the redundancy structure under study. All numbers are averaged across the included libraries and are monotone in the same direction for each one individually.

Appendix DAdditional Analysis

D-AWhy a Deployment-Only Objective Is Insufficient

Consider a bundle with a 200-token root, two rare references of 800 tokens each, and an exact 300-token fragment shared by those references. Each rare branch is used by 5% of tasks. Global factoring into the root reduces deployment by nearly 300 tokens (minus references), yet increases expected runtime exposure by approximately0.9×300=2700.9\times 300=270tokens per task. Factoring into a shared on-demand module retains the deployment saving while charging the module only to the 10% affected paths. This example illustrates why deduplication scope is part of the representation, not an implementation detail.

The same reasoning applies to capsules. Moving a 600-token export guide behind a 20-token dispatcher at 10% frequency saves roughly600−(20+60)=520600-(20+60)=520expected path tokens before deployment weighting. At 95% frequency, the saving falls to 10 tokens and may disappear after reference overhead. The path distribution changes the best layout even when the underlying prose does not.

D-BSensitivity to Unknown Traffic

When traces are unavailable, uniform leaf-path weights can overvalue rare branches in a deep tree or undervalue a broad common branch.SkillZip Protherefore exposes three policies:uniform-leaf,guard-prior, andminimax. The minimax policy accepts a transformation only when it improvesJJfor every distribution in a declared uncertainty set. It is more conservative but avoids large regressions under traffic shift.

We recommend reporting both the optimization distribution and counterfactual distributions. A transformation that wins only under a narrow prior should be labeled workload-specific. Host-entailment witnesses are independent of traffic, while capsule and sharing placement are not.

D-CFaithfulness Is Structural, Not Universal Semantics

Typed coverage protects explicit instructions and their scope, but natural language can carry implicature, tone, and redundancy that help a particular model. Removing redundant emphasis may affect behavior even if normative content is retained. This is why the empirical protocol measures non-inferiority across executor families and why a strict structural audit does not replace held-out evaluation in scientific validation. “Evaluation-free” describes the compression algorithm, not the evidence standard for publishing its effectiveness.

The audit can also share errors with extraction. Independent prompts, source-span provenance, deterministic type checks, and verbatim locking reduce correlated failure but cannot eliminate it. High-stakes skills should use human review or stronger formal specifications for critical obligations.