A skill library is a collection of related skills. As skill use grows, libraries become essential — for personal organization, team sharing, public distribution.
This page covers how skill libraries work and the patterns for managing them.
Skills you've created for your own use. In your local Claude installation.
Path: ~/.claude/skills/ or similar.
Skills shared across an engineering team. Living in a git repo; checked out by team members.
Use cases: team-specific code style, project workflows, internal tool integrations.
Across many teams in one company. Common conventions; shared workflows.
Often versioned; reviewed; managed.
Open-source skills. Shared on GitHub or skill registries.
Examples: the superpowers plugin, language-specific skill collections.
Standard: skills in a git repo. Users clone; install.
git clone https://github.com/user/skills.git ~/.claude/plugins/skills
Updates: git pull. Versioning via git tags.
Some Claude environments have plugin systems. Plugins bundle skills + configuration.
For Claude Code: the plugin marketplace.
Copy skill directory into the right location.
For one-off skills, this is fine. For collections, git is better.
Future: a package manager for skills. Not yet standardized.
Skills for one topic: "java-skills", "python-skills", "code-review-skills."
Easier to maintain; easier to opt into specific topics.
A library covering many topics: "engineering-essentials" with code review, debugging, testing, etc.
Easier installation; harder to manage.
Smaller libraries that compose: "core" + "java" + "kubernetes." Users install what they need.
For organizations with many users, this works well.
Skill names should be unique within a library. Across libraries, conflicts are possible — installing two libraries with the same skill name is ambiguous.
Conventions help: prefix per library ("acme-code-review" vs. just "code-review").
Each library version exists at a point in time. Skills change; users on different versions get different behavior.
Strategies:
Within a library, some skills may invoke others:
This skill uses the `helper-skill` for X.
Document the dependency. If the helper skill is missing, the dependent skill fails gracefully.
Generally avoid. Library A depending on library B becomes a maintenance nightmare.
If unavoidable: explicit declaration; version compatibility matrix.
Each library has an owner (or group). Decisions; updates; conflict resolution.
For shared libraries, changes deserve review. Skill changes affect downstream users; review catches issues.
Where do users report problems? GitHub Issues, internal tracker.
What changed in each version? Especially for breaking changes.
Skills age. Some get replaced. Mark old skills as deprecated; provide migration path; eventually remove.
Users browse libraries to find skills. The README/index of the library matters.
Format that works:
Some skills have configuration. Library can include:
Some libraries include hook configurations. Suggest adding them to settings.json:
For best experience, add these hooks:
{ "hooks": [...] }
For libraries used at scale, automated testing of skills:
This is emerging practice; tools are limited.
For open-source skill libraries:
Pick a license. MIT or Apache 2 are common; pick deliberately.
README; per-skill docs; examples; contribution guide.
Semantic versioning helps consumers.
Make it easy to report problems.
Sample conversations showing skill use.
Public collection of foundational skills: brainstorming, writing-plans, test-driven-development, etc. Common starting point.
Various community-contributed libraries.
Many companies build internal libraries. Conventions, build tooling, deployment workflows.
For your own libraries: