Collections, Versions, and Weeding
Collections, Versions, and Weeding
A shared skill library fails the same way an unmaintained collection fails: not at acquisition, but three years later, when nobody remembers who selected an item, what it was for, or whether it still works.
Kanon builds the answer into metadata. Maturity is a lifecycle, and deprecating an artifact requires naming its successor. Trust is a declared lane. Visibility controls what appears in the catalog at all. Versions are mandatory, so an install can be pinned and an upgrade reviewed. For teams, a manifest describes what should be installed and guild status reports the drift between that and reality.
None of this is verification. Every one of those fields is asserted by whoever wrote the artifact. The infrastructure gives you a place to record a judgment; making the judgment, and revisiting it, is still the librarian's work.
Design a local collection
A collection manifest carries metadata only. Membership is declared by each artifact, in its own frontmatter.
Draft a Kanon collection manifest for a collection of AI skills maintained by an academic library, following the conventions used in https://github.com/jhu-sheridan-libraries/agentic-skill-library Include name, displayName, description, version, author, trust, and tags. Then list five artifacts you would want in it, and for each one say who in the library would own it, what evidence would justify moving it from experimental to stable, and what would trigger its removal.
Every proposed artifact has a named owner and a stated condition for promotion and for removal.