Skills as the unit of reusable knowledge

Three layers carry knowledge into a run, and only one of them is writable by the people doing the work. Prompts are per-session and thrown away. Weights are closed to everyone outside a lab, and slow even there. Between them sits a versioned file that says how a thing is done here — the layer that is cheap to write, reviewable, and diffable. The field's phrasing is blunt: do it once, prompt; do it repeatedly, make a skill. Investigation method belongs there too — how to approach an HTTP 500, a memory leak, a performance regression — because re-deriving a known procedure spends tokens and reasoning on something already settled.

Two properties do the work. The artifact is portable across harnesses and models in a way a fine-tune is not — when the architecture underneath changes every few weeks, the context is the durable investment. And it compounds: a library of validated skills is an asset whose value grows with use, which is why several groups now propose counting validated skills rather than commits as the growth number. One framing puts it as a second scaling law stacked on the neural one, with tokens on one axis and the count of validated skills on the other.

The counter-position is argued from measured results, not taste: this only pays when the knowledge is curated and routed. Pointing a retrieval layer at raw documentation underperforms a hand-built structure — a router that maps a concern to a symptom to a handbook — on grounding, specificity, first-pass success and dead-end rate, with token and error reductions that a frontier-model upgrade did not match. The related warning is that knowledge is not strategy: a package full of product facts will still give confidently wrong advice until the people who own the strategy write theirs into it.

Also: tessl.io and its skill registry; Anthropic's skill best practices (progressive disclosure, concision, explicit activation declaration); NVIDIA NeMo Agent Toolkit; ASPIRE.

Assay's desk roles ship as exactly this artifact: a versioned skill per role, installed into an adopting project, plus a project-level instruction layer that says how this particular house works. That structure was in place before the conference framing arrived, which makes this concept a description of Assay rather than a proposal to it.

The design that answers Cisco's "15 engineers, 15 overlapping skills" complaint is a split: one neutral skill body per role, with house-specific values resolved from the project layer rather than forked into a second copy. Nothing a skill body requires lives in the project layer — only the values it asks for. That is the deliberate antidote to duplicate-skill sprawl, and a structural lint holds the remaining duplicated copies byte-identical to their source.

First, Assay counts work — briefs, pull requests, verified rows — and not validated skills. The second-scaling-curve framing suggests a reporting upgrade: count the skills that pass lint, carry usage evidence and have review sign-off, as the compounding asset. Second, the capture path for a recurring solution is currently a memory note; the field's position is that it should be a skill edit, because a method is executable where a note is prose. The measured 43%/48% result is the strongest external evidence for Assay's curated-package posture over pointing sessions at raw sources, and worth citing the next time that trade-off is argued.

• Whether any group publishes a reproducible lift number for a skill library against a matched no-library baseline; the compounding claim is still mostly asserted, and the 43%/48% figure is the only hard number in this scan.
• Whether validated-skill count becomes a metric anyone actually reports, or stays a talk slide.
• Cross-harness portability under stress — the claim that skills port where fine-tunes do not is repeated by several speakers, but nobody in this scan measured the same skill's behaviour across harnesses.