Skill Libraries

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.

Levels of library

Personal

Skills you've created for your own use. In your local Claude installation.

Path: `~/.claude/skills/` or similar.

Team

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.

Organization

Across many teams in one company. Common conventions; shared workflows.

Often versioned; reviewed; managed.

Public / community

Open-source skills. Shared on GitHub or skill registries.

Examples: the superpowers plugin, language-specific skill collections.

Distribution patterns

Git repository

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.

Plugin system

Some Claude environments have plugin systems. Plugins bundle skills + configuration.

For Claude Code: the plugin marketplace.

Direct install

Copy skill directory into the right location.

For one-off skills, this is fine. For collections, git is better.

NPM-like package

Future: a package manager for skills. Not yet standardized.

Organization patterns

Single category

Skills for one topic: "java-skills", "python-skills", "code-review-skills."

Easier to maintain; easier to opt into specific topics.

Multi-category

A library covering many topics: "engineering-essentials" with code review, debugging, testing, etc.

Easier installation; harder to manage.

Composable libraries

Smaller libraries that compose: "core" + "java" + "kubernetes." Users install what they need.

For organizations with many users, this works well.

Design considerations

Naming

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").

Versioning

Each library version exists at a point in time. Skills change; users on different versions get different behavior.

Strategies:

- Semantic versioning (1.2.3)

- Pinning to specific versions

- Migration guides for breaking changes

Dependencies between skills

Within a library, some skills may invoke others:

```markdown

This skill uses the `helper-skill` for X.

```

Document the dependency. If the helper skill is missing, the dependent skill fails gracefully.

Cross-library dependencies

Generally avoid. Library A depending on library B becomes a maintenance nightmare.

If unavoidable: explicit declaration; version compatibility matrix.

Maintenance

Owner

Each library has an owner (or group). Decisions; updates; conflict resolution.

Review process

For shared libraries, changes deserve review. Skill changes affect downstream users; review catches issues.

Issue tracking

Where do users report problems? GitHub Issues, internal tracker.

Release notes

What changed in each version? Especially for breaking changes.

Deprecation

Skills age. Some get replaced. Mark old skills as deprecated; provide migration path; eventually remove.

Specific patterns

Skill discovery

Users browse libraries to find skills. The README/index of the library matters.

Format that works:

- Index by purpose (code review, planning, debugging)

- Brief description per skill

- Links to detailed SKILL.md

Configuration

Some skills have configuration. Library can include:

- Default config files

- Schema

- Examples per use case

Hooks integration

Some libraries include hook configurations. Suggest adding them to settings.json:

```markdown

For best experience, add these hooks:

{ "hooks": [...] }

```

Skill testing

For libraries used at scale, automated testing of skills:

- Test conversations that invoke each skill

- Verify expected behavior

- Run on CI

This is emerging practice; tools are limited.

Sharing skills publicly

For open-source skill libraries:

License

Pick a license. MIT or Apache 2 are common; pick deliberately.

Documentation

README; per-skill docs; examples; contribution guide.

Versioning

Semantic versioning helps consumers.

Issue templates

Make it easy to report problems.

Examples

Sample conversations showing skill use.

Specific libraries to know

Anthropic's superpowers

Public collection of foundational skills: brainstorming, writing-plans, test-driven-development, etc. Common starting point.

Plugin marketplace

Various community-contributed libraries.

Internal company libraries

Many companies build internal libraries. Conventions, build tooling, deployment workflows.

Common failure patterns

- **Library too large.** Hard to maintain; users overwhelmed.

- **No versioning.** Changes break users silently.

- **Skill name conflicts.** Multiple libraries; ambiguous which skill applies.

- **No discovery aids.** Users don't know what's available.

- **Dependencies between libraries.** Maintenance burden.

- **Stale skills.** Documentation says X; behavior is Y.

A reasonable approach

For your own libraries:

1. Start small (a few skills you actually use)

2. Document each skill clearly

3. Version when sharing widely

4. Iterate based on real usage

5. Deprecate; don't accumulate cruft