The Specific Situation

Your company has 12 engineering teams, each independently creating Claude Code skills. The backend team built a generate-tests skill. The frontend team built a different generate-tests skill. The platform team built a third. All three produce different output formats, use different testing frameworks, and have incompatible conventions. Nobody knows what skills exist across the organization. You need a centralized skills library.

Technical Foundation

Claude Code supports four distribution methods that a centralized library can use:

The library pattern works by maintaining a single repository with curated, reviewed, versioned skills. Teams pull from the library rather than creating skills independently.

The Working SKILL.md (Library Catalog Skill)

A skill that lists and describes all available skills in the library:

---
name: skill-catalog
description: >
  Browse the organization's Claude skills library. Lists available
  skills by category with descriptions and usage examples. Use when
  the user says "what skills exist", "browse skills", or "skill catalog".
---

# Organization Skills Library

## Categories

### Development
| Skill | Description | Invoke |
|-------|-------------|--------|
| generate-unit-tests | Unit tests with team patterns | /org:generate-unit-tests |
| generate-integration-tests | Integration tests | /org:generate-integration-tests |
| code-review | Structured PR review | /org:code-review |
| lint-fix | Auto-fix lint errors | /org:lint-fix |

### DevOps
| Skill | Description | Invoke |
|-------|-------------|--------|
| deploy-staging | Staging deployment | /org:deploy-staging |
| deploy-prod | Production deployment | /org:deploy-prod |
| docker-dev | Local Docker management | /org:docker-dev |

### Documentation
| Skill | Description | Invoke |
|-------|-------------|--------|
| generate-api-docs | API documentation | /org:generate-api-docs |
| generate-changelog | Changelog from commits | /org:generate-changelog |

## Adding New Skills

1. Submit a PR to the skills library repo
2. Follow the style guide in CONTRIBUTING.md
3. Security review required (CODEOWNERS)
4. After merge, all teams get the update on next session start

Library Repository Structure

org-claude-skills-library/
├── skills/
│   ├── generate-unit-tests/
│   │   ├── SKILL.md
│   │   ├── templates/
│   │   └── references/
│   ├── generate-integration-tests/
│   │   ├── SKILL.md
│   │   └── templates/
│   ├── code-review/
│   │   ├── SKILL.md
│   │   └── references/
│   ├── deploy-staging/
│   │   └── SKILL.md
│   ├── deploy-prod/
│   │   └── SKILL.md
│   ├── docker-dev/
│   │   └── SKILL.md
│   ├── generate-api-docs/
│   │   ├── SKILL.md
│   │   └── templates/
│   └── skill-catalog/
│       └── SKILL.md
├── CONTRIBUTING.md
├── SECURITY.md
├── CHANGELOG.md
└── README.md

Distribution Architecture

The library repository IS the plugin. Teams enable it:

{
  "plugins": [
    "/path/to/org-claude-skills-library"
  ]
}

All skills appear namespaced: org-claude-skills-library:code-review. No conflicts with project-level skills. Updates when teams restart Claude Code.

Option B: Git Submodule

Add the library as a submodule in each project:

git submodule add https://github.com/org/claude-skills-library .claude/skills-library

Then configure Claude Code to use the directory:

claude --add-dir .claude/skills-library

Skills from the submodule are discovered automatically. Update with git submodule update --remote.

Option C: Copy-on-Demand

Teams copy specific skills from the library into their project:

# Copy one skill from the library
cp -r /path/to/library/skills/code-review .claude/skills/code-review

Simple but loses central update capability. Each project has its own copy that diverges over time.

Governance Model

Skill Submission Process

  1. Developer opens a PR to the library repo with the new skill
  2. PR template requires: description, use case, test results, security notes
  3. CODEOWNERS routes to appropriate reviewer (security team for allowed-tools changes)
  4. Two approvals required: domain expert + security reviewer
  5. CI validates YAML frontmatter, script syntax, naming conventions
  6. After merge, a notification goes to #claude-skills team channel

Skill Ownership

Each skill has an OWNER file:

# skills/code-review/OWNER
team: backend-platform
maintainer: @alice
created: 2026-02-15
last-review: 2026-04-01

Ownership determines who reviews changes and who to contact for issues.

Deprecation Process

  1. Mark the skill with a deprecation notice in the body
  2. Add disable-model-invocation: true to prevent auto-triggering
  3. Update the catalog skill to show DEPRECATED status
  4. Remove after 30 days

Common Problems and Fixes

Teams want different versions of the same skill: Use the paths field to create team-specific variants. Or create distinct skills: code-review-backend vs code-review-frontend.

Library updates break team workflows: Use a release-based update schedule. Tag library versions. Teams pin to a tag and update on their own schedule (git submodule approach).

Too many skills clutter the /menu: Set user-invocable: false on reference/background skills. Only task skills should appear in the menu. Use the catalog skill for discovery.

Plugin namespace is too verbose: org-claude-skills-library:generate-unit-tests is long to type. Use a shorter plugin directory name: org-skills gives org-skills:generate-unit-tests.

Production Gotchas

There is no skill analytics in Claude Code. You cannot track which skills are used, how often, or by whom. Build feedback loops through quarterly surveys, PR activity on the library repo, and Slack channel discussions.

The library pattern adds a dependency. If the library repo is down, git submodule update fails. Plugin-based distribution using a local clone avoids this.

Enterprise managed settings can enforce skills from the top, but they cannot distribute a full library structure with supporting files. Managed settings work for CLAUDE.md rules, not for complex multi-file skills. Use plugins for rich skill distribution.

Checklist