How to Build a Skills Library Your Team Actually Uses
Naming, organizing, governing. The difference between a library and a folder nobody opens.
The prompt library problem is almost universal. A firm decides to build a shared library, someone creates a folder, people add things to it for a few weeks, and then it quietly stops growing and quietly stops being used. Six months later, the folder has forty prompts in it, none of them labeled consistently, and nobody can find the one they need in less than five minutes of searching.
The library failed not because the prompts were bad. It failed because a folder is not a library. A library has organization, findability, and governance. A folder has none of those things unless you build them in deliberately.
Start with use cases, not categories
Most people organize a library by type: research prompts, writing prompts, analysis prompts. This feels logical and is not how anyone actually uses the library. When someone needs a Skill, they are not thinking "I need a writing prompt" - they are thinking "I need to draft a client update after a difficult meeting."
Organize by use case. The name of the Skill should describe the task it handles, specifically enough that someone who has never seen it before knows whether it is what they need. "Draft client update - post-meeting" is a name. "Client writing" is not.
The test for a Skill name: can someone who has never used it before decide whether to use it, based on the name alone, in under three seconds? If not, rename it.
Three fields every Skill entry needs
A Skills library entry should have at least three things beyond the prompt itself:
When to use it
One sentence describing the specific situation this Skill handles. This is what helps someone scan the library and find what they need. It is also what prevents people from using the wrong Skill for a task that looks similar but is subtly different.
What to provide
What input does the Skill require? A document, a meeting summary, a client name and context? Being explicit about this saves the person running the Skill from having to figure it out by trial and error.
Who maintains it
A Skill with no owner is a Skill that gradually goes stale. Assign each Skill to someone responsible for keeping it current. This does not mean they have to do major revisions regularly - it means they are the person who notices when it stops working well and updates it.
Governance: the part most firms skip
Governance is not a complicated system. For most firms it is just three decisions:
Who can add to the library? Open contribution tends to produce noise faster than it produces useful Skills. A better approach: anyone can propose a Skill, but it goes through a quick review before it is added to the main library. The review does not need to be formal - a single person with AI fluency reading through it and confirming it works is enough.
What happens when a Skill stops being used? Every library accumulates Skills that made sense at the time but no longer get used. Set a simple rule: if a Skill has not been run in three months, archive it. This keeps the library manageable and prevents the "folder nobody opens" problem from creeping back in.
How do improvements get incorporated? Skills improve through use. When someone runs a Skill and gets a better result by tweaking it, that improvement should go back into the library. Build a lightweight process: note improvements in a shared document, review them monthly, update Skills accordingly.
Where to put it
The library should live where people already do their work. If your team uses Notion, put it in Notion. If they use a shared drive, put it there. The fanciest organizational system fails if people have to navigate to a separate tool to use it.
For most firms, the practical home for the Skills library is the same Claude Project they use for day-to-day work. Skills loaded into a Project are available in context during every session - there is no searching required, no switching to a separate document. You reference the Skill by name in your prompt and it is already there.
Starting small and staying useful
A library of five Skills that everyone uses is more valuable than a library of fifty that nobody can find their way around. Start with the five workflows that show up most often across your team's work. Build Skills for those. Get the library working at that scale before expanding.
Once people have the habit of reaching for the library, it grows naturally. Someone finds that a Skill they use has a gap. They fill it. Someone figures out a better approach to a common task. It goes in. The library compounds because the habit of using it creates the habit of improving it.
Building and organizing a firm Skills library is Module 2 of Apparatus 202. If you want to see how that fits into the broader infrastructure picture, the cornerstone piece on turning prompts into Skills is the right place to start.