Skills need an SDLC

Skills have near-zero authoring cost and outsized influence on agent behavior, so they multiply unchecked. One widely-told story: a company shared everyone's skills into one repository and got seven near-duplicate code-review skills with no quality signal — trust collapsed and everyone went back to private copies. The missing pieces were exactly the ones package management solved for code a decade ago.

Overlap (duplicate skills, divergent conventions), drift (upstream improves, users never learn), non-activation (nobody can tell if a skill ever fires), rot (the surface it describes moves on in weeks), and overloading — the mechanical one: every installed skill's name and description is injected into every session, capped as a share of the context window, then silently truncated. Too many skills and some simply stop existing, with no error.

Treat skills as software: decompose into small single-purpose units; extend third-party skills rather than editing vendored copies; ban local-only setup ("all agent workflow improvements must be checked into the repo"); lint structure in CI; publish to a pinned, versioned registry with update diffs and rollback; scan for security issues at install and publish; refuse packages newer than a few days. The umbrella name several speakers used: the Context Development Lifecycle — humans own context, agents own the SDLC.

A large eval study found agents follow a skill's instructions 55% of the time with no skill installed — that knowledge is already in the weights. Skills earn their tokens almost entirely on house-specific knowledge the model was never trained on: approved libraries, required steps, prohibited patterns. And repositories without structured agent context measurably degrade under agent use, while skill-bearing repositories degrade roughly three times less at the same speed. Governance is not overhead; it is the difference between agents helping and harming.

Assay ships one curated bundle rather than an open corpus, so the sprawl modes mostly do not apply: everything is checked in (no global or local-only skills), each skill is small and single-purpose, and the two copies that must stay identical are held byte-identical by a parity check — drift caught by a machine, not a diligent reader.

Releases are pinned and hash-verified, consumers lock versions, and installation is tooling rather than a clone. The registry-and-lockfile story the speakers described as the aspiration is the shipping mechanism here today.

The neutral-body-plus-config-layer design means an adopter never edits a shipped skill to customize it — the skill resolves their values at run time. The upgrade path can never be broken by a local patch, which is the failure the rule exists to prevent.

Assay's lint checks structure — parity, unresolved values, format. Nothing yet answers "did this skill edit make behavior better or worse?" That is the largest honest gap against this concept, and the conference supplied the method: fixture scenarios drawn from historical mis-fires, run on every skill change; with-and-without lift measured against the 55% baseline; replayed incidents as regression tests. A scheduled stale-skill review — rot caught on a cadence rather than by luck — is the companion piece. Both are designed, not yet shipped.

8 of 29 talks shown — the ones that reach the most concepts in this theme. Every sighting, per talk, is on the concept pages above.