Running a Skill Library: Owners, Versions and Retirement

A skill library stays useful when every skill has a named owner, a version number and a status. Changes are tested and approved before release. Each skill is reviewed on a schedule, and skills that are unused, superseded or ownerless are retired to an archive. Without that, a library quietly fills with stale, overlapping methods.

What does running a skill library involve?

Running a skill library means keeping a catalogue of every skill, deciding who may change each one, releasing changes deliberately and removing skills that no longer earn their place. It is light work once set up: an owner per skill, a review rhythm and a simple rule for what counts as live.

Skills are easy to create, which is the problem. A team that adopts them enthusiastically can have dozens within months, several doing nearly the same job. Each one looked useful when it was written. Together they confuse both the assistant and the people using it.

A catalogue fixes most of this. One row per skill, listing its name, purpose, owner, version, status and last review date, is enough to see what exists and who answers for it.

Who should own each skill?

The owner should be the person whose method the skill captures, or whoever now leads that work. They decide what the skill should do, approve changes, check a sample of its output and retire it when the method changes. Name one person per skill, not a team, and record a deputy.

Ownership follows the work, not the author. A marketer who wrote the reporting skill may move on; the new head of reporting inherits it. So the owner field changes whenever roles change, and the catalogue review checks that it has.

Skills that run as agents need the same discipline as the agents themselves. The guide to owning AI agents explains how ownership splits between the business and IT.

How should skills be versioned?

Give each skill a version number and a short changelog saying what changed, why and who approved it. Keep skills in a versioned store, such as a shared repository, so any change can be compared and reversed. Raise the version on every released change, however small, so people can tell which one produced an output.

The open standard leaves room for this. According to the Agent Skills specification, the optional metadata field holds "additional properties not defined by the Agent Skills spec", and its own example records a version alongside the author. A changelog section at the end of the skill, or a separate file beside it, covers the rest.

Keep dates out of the instructions themselves. Anthropic's authoring guide warns against time-sensitive information and suggests an "old patterns" section for anything superseded.

How do you approve changes to a skill?

Treat a skill change like a change to a process document that runs itself. Edit a copy, rerun the skill's test set, have the owner review the results, then release it. Organisation-wide skills should only be released by the people allowed to provision them, so a well-meant edit cannot reach everyone untested.

Claude's organisation controls support this shape. According to the help centre, "only owners can add or remove organization-wide skills", and individual users can switch a provisioned skill off but cannot delete it. Users stay on the currently approved version until a new one is approved.

The test set is what makes approval quick. If every change reruns the same real tasks, the owner compares results instead of rereading the whole skill. The guide to testing a skill covers how to build that set.

When should a skill be retired?

Retire a skill when nobody has used it for a quarter, when another skill does its job better, when the method it captures has changed beyond a simple edit, or when it has no owner and nobody will take it. Move it to an archive with a note on what replaced it, rather than deleting it.

Retirement is the step teams skip, because an unused skill seems harmless. It is not. Every installed skill's description competes for attention, and a stale one may still fire on a request and apply an old method.

A quarterly review keeps this manageable:

1. Usage. Which skills ran this quarter, and which did not?
2. Owner. Does each skill still have a named owner in the role?
3. Accuracy. Does a sample of output still match how the work is done?
4. Overlap. Do any two skills now cover the same job?
5. Decision. Keep, update, merge or retire, recorded in the catalogue.

How do you stop skills from overlapping?

Check every proposed skill against the catalogue before it is written. If one already covers most of the job, extend it instead. Keep descriptions specific about what each skill does and when to use it, and test near-miss requests so similar skills do not compete for the same work.

The description is how an assistant chooses. Anthropic's authoring guide says Claude uses it to choose "from potentially 100+ available Skills", so two vague descriptions will collide. Consistent naming helps people too; the same guide recommends patterns that make a library easy to search.

Shared foundations reduce overlap further. When every skill reads the same product facts and voice rather than carrying its own copy, skills stay small and focused on method. A fact then changes in one place, not in twelve skills at once.

Skein keeps each client's method in shared skill files the client owns, with an owner for each and client specifics held in the client's own workspace; the skill library page shows the kinds of skills involved. That suits a team running a growing set of skills across several functions. A team with three or four skills can manage with a list and a named owner each.

Frequently asked questions

What is a skill library?

A skill library is the collection of skills a team uses, each a packaged method an AI assistant follows when a task matches. Running it well means keeping a catalogue, naming an owner for every skill, versioning changes, approving releases and retiring skills that are no longer used or accurate.

Who should own a skill?

The person whose method the skill captures, or whoever leads that work now. They approve changes, check a sample of output and decide when to retire it. Name one person rather than a team, record a deputy, and update the owner whenever roles change so no skill is left unowned.

How do you version a skill?

Give it a version number, raise it on every released change, and keep a short changelog of what changed, why and who approved it. Store skills somewhere versioned, such as a shared repository, so changes can be compared and reversed. Larger changes in purpose may deserve a new skill instead.

When should a skill be retired?

Retire it when it has gone unused for a quarter, when a better skill does the same job, when its method has changed substantially, or when nobody will own it. Archive it with a note on what replaced it rather than deleting it, so past outputs can still be traced.

How often should a skill library be reviewed?

Quarterly suits most growing teams. Check which skills ran, whether each still has an owner, whether sample output still matches the real method, and whether any two skills overlap. Record a decision for each: keep, update, merge or retire. Busy libraries with frequent changes may need a monthly check.

Related reading