Skill lifecycle and sprawl

Software rots, and so does the context wrapped around it — only faster. The estimate offered in this scan is that three months of code rot compresses to roughly two weeks once models, APIs and the codebase are all moving. Past that point the artifact is not neutral. A skill that names a retired API or a superseded convention actively steers the agent wrong, which is worse than having no skill at all. Guidance therefore has to be allowed to die: a one-off incident can be left alone, but recurrence is the trigger to consolidate, and deduplication against existing entries is part of the write.

The named failure modes are overlap, drift, non-activation, rot, and context-window overloading. The last one deserves separate billing because it is mechanical and produces no error. Every installed skill's name and description is injected into every session; the total is capped as a fraction of the window; the surplus is truncated. Beyond some count, skills simply stop existing, and the symptom looks exactly like non-activation. Sprawl's structural cause is the fork: someone shares a skill, the next team forks it for a one-percent change, and the two copies drift apart forever. Skills need extensibility and a contribution-back path, or forking is the only move available.

Nothing exotic is required: version pinning and registries, semantic versions used as a maturity signal (use-it-yourself, stabilizing, then a 1.0 that promises to work first try — where a 1.0 that fails destroys trust), staleness detection, dataset freshness treated as a first-class trust question, and a prune protocol that treats deletion as a first-class operation. The sharpest version of pruning is measurable: periodically remove the knowledge base and re-measure; if performance improves, prune. And when something breaks, check whether an existing rule caused it and edit or delete that rule, rather than stacking another on top.

Also: the Tessl registry; Tessell's skills inventory (private beta); Snyk; APM, Microsoft's agent package manager.

There is one bundle rather than per-team forks, which structurally removes the fork problem before it starts. A parity check acts as a rot control on the copies that do exist, holding them byte-identical to their source. And version pinning with released tags is already how Assay distributes its tooling — the dependency-management answer the evidence asks for, implemented for the tools but not yet for the skill bundle itself.

Two items are specified and unshipped: per-skill maturity versions in the semver sense, and a rot sweep that flags skills untouched for months or still naming retired tools and retired role vocabulary. The raw material for the sweep exists — retirements are traceable — but no sweep runs.

Context-window overloading is the blind spot. Assay does not count its installed skills or estimate their description-token footprint, so if the bundle ever crosses the truncation threshold it will fail silently and look like non-activation. Two cheap experiments follow: a boot-time budget assertion that counts installed skills, sums description tokens and asserts under a stated fraction of the window; and a transcript-derived activation audit showing which skills ever actually fire. Alongside them sits a retirement rule the evidence argues for and Assay has no convention for — retiring a skill or a role verb should leave a tombstone rather than a hole, so an agent acting on a stale model prior gets a redirect instead of a silent failure.

• Whether anyone publishes a measured skill-count threshold where description truncation begins — the number that would turn overloading from a warning into a budget.
• Whether prune-and-re-measure shows up in a second house; one source is thin for a protocol that deletes working artifacts.
• Whether skill registries adopt deprecation and tombstone semantics, or repeat the npm pattern of leaving retired names to rot.