The Library Meta-Skill: Distribute Private Skills Across Codebases

You have 10 codebases. Each one has its own deploy skill, its own review agent, its own planning command. Some are current. Most are out of date. A few are duplicates you copied three months ago and never touched again. Sound familiar?

This is the skills distribution problem, and it gets worse with every repo you add. The library meta-skill solves it with a single YAML file that acts as a catalog of references to your private skills, agents, and prompts. Nothing gets copied. Everything stays in sync.

Pioneered by IndyDevDan and inspired by Stripe's internal "tool shed" concept, the library pattern treats your agentics like dependencies in a package.json. You catalog once, distribute everywhere.

The Problem: Skills Sprawl

If you work across one or two repos, you don't need this. Your skills, agents, and commands live right next to your code. Everything is easy to find.

Once you pass five or six codebases, things break down fast:

• Duplication everywhere. The same deploy skill exists in 8 repos, each slightly different.
• Version drift. You improved your code review agent last week, but only in one project. The other 9 repos still run the old version.
• No coordination. Your teammate built a killer database migration prompt. You built your own because you didn't know theirs existed.
• Device fragmentation. You run agents on your laptop, a Mac Mini, and a cloud sandbox. Keeping skills synced across all three is manual and error-prone.

The instinct is to just copy files. It's fast, it works in the moment, and it falls apart within a month. This is the "sloppy fast" approach, and every engineer running multi-repo agent setups has been there.

What the Library Actually Is

The library is a meta-skill: a skill that manages other skills. It consists of two pieces:

1. A SKILL.md file with instructions Claude follows to manage your catalog
2. A library.yaml file that stores references (not copies) to your agentics

Here is what the YAML catalog looks like:

default_dirs:
  skills:
    - default: .claude/skills/
    - global: ~/.claude/skills/
  agents:
    - default: .claude/agents/
    - global: ~/.claude/agents/
  prompts:
    - default: .claude/commands/
    - global: ~/.claude/commands/
 
library:
  skills:
    - name: deploy
      description: Production deployment with rollback support
      source: https://github.com/yourorg/private-agentics/blob/main/skills/deploy/SKILL.md
 
    - name: code-review
      description: Security and performance review checklist
      source: /Users/you/agentics/skills/code-review/SKILL.md
      requires: [skill:security-rules]
 
  agents:
    - name: planning-agent
      description: Multi-phase implementation planning
      source: https://github.com/yourorg/private-agentics/blob/main/agents/planner.md
 
  prompts:
    - name: prime
      description: Session priming with project context
      source: https://github.com/yourorg/private-agentics/blob/main/commands/prime.md

Notice what this file contains: names, descriptions, and pointers to where each item actually lives. The skills themselves stay in their source repositories. The library just knows where to find them.

Three source types are supported:

• Private GitHub repos for team-shared agentics
• Public GitHub repos for community skills
• Local file paths for items still in development

The Core Workflow: Build, Catalog, Distribute, Use

The library pattern follows four steps that map to how you naturally develop agentics:

Build. You create a new skill inside whatever project needs it. This is where the work happens organically. You don't interrupt your flow to think about distribution. You build the skill where it provides immediate value.

Catalog. When the skill is stable, you register it in your library. The /library add command updates your library.yaml with a reference to the skill's source location, commits the change, and pushes it.

Distribute. The catalog is backed by a git repository. Any device or teammate with access can pull the latest catalog. One git pull and everyone has the same index of available agentics.

Use. In any project on any device, /library use deploy pulls the deploy skill from its source and installs it locally. Dependencies get resolved automatically. If the deploy skill requires a security-rules skill, both get installed.

Commands That Make It Work

The library exposes eight commands. Each one reads a corresponding cookbook file before executing, so the agent knows exactly what steps to follow:

The sync command deserves special attention. This is not just syncing your catalog file. It re-pulls every installed item from its source, ensuring your local copies match the latest versions. Run it at the start of a work session and your entire agentic toolkit is current.

The push command handles the reverse flow. You improve a skill locally, and push sends those changes back to the source repository. It checks for conflicts, warns you if the source has diverged, and handles the git operations automatically.

Why This Is a Pure Agentic Solution

There is no code backing this system. No CLI tool, no npm package, no binary. The library is a skill file, a YAML catalog, and a set of cookbook instructions. Claude reads the instructions and executes the operations using standard tools: git, file system operations, and bash commands.

This is significant. It means the library works on any device where Claude Code runs. No installation dependencies, no version compatibility issues, no build step. The agent is the runtime.

This pattern will become more common as agentic engineering matures. When your tools can read instructions and execute multi-step workflows, you don't always need compiled code. Sometimes a well-structured markdown file is the entire application. This connects directly to the broader shift toward designing systems for agents rather than humans.

Scaling Across Teams and Devices

The library solves three distribution scenarios:

Personal distribution. You work on a laptop and a headless Mac Mini running agents overnight. The library ensures both devices have identical skills. One sync command and your overnight agent has the same capabilities as your development machine.

Team distribution. Your private GitHub repo holds the team's library.yaml. When someone improves a skill, they push it. When someone needs a skill, they use it. The catalog is the single source of truth.

Multi-agent distribution. If you run multiple agents (each in their own worktree or sandbox), the library gives each agent access to the same skill set. This matters for sub-agent architectures where specialized agents need consistent capabilities.

The dependency resolution system handles skills that build on other skills. If your deploy skill requires security-rules, the library installs both. Dependencies use typed references (skill:name, agent:name, prompt:name) and resolve recursively.

Implementing Your Own Library

You can adopt this pattern today. Fork IndyDevDan's the-library repo, customize the SKILL.md to match your workflow, and start cataloging.

Here is a minimal setup:

1. Fork the repo and make it private (your catalog references private code)
2. Clone to your skills directory: ~/.claude/skills/library/
3. Run /library install to set up the directory structure
4. Start with three entries: your most-used skill, your best agent, and your most-repeated command
5. Test the cycle: add an entry, use it in a different project, modify it, push it back

The library stores its catalog at ~/.claude/skills/library/library.yaml by default, making it available globally across all your projects. Items get installed to either project-local directories (.claude/skills/) or global directories (~/.claude/skills/) depending on your needs.

If you already have a collection of custom agents and skills built up from your CLAUDE.md configuration, the library gives you a way to stop treating them as project-specific and start treating them as a portable toolkit.

The Bigger Picture

The library meta-skill points to where agentic engineering is heading. As engineers accumulate more specialized agents, skills, and prompts, distribution and version management become real infrastructure problems.

Stripe recognized this early with their internal "tool shed." IndyDevDan formalized it into a reusable pattern. The core insight: your agentics are assets worth managing with the same rigor you apply to your code dependencies.

Today it's a YAML file and a skill. Tomorrow it could evolve into something closer to a package registry for agentic capabilities. But the pattern itself, catalog references and pull-on-demand, is sound right now.

If you want a working foundation for the skills and agents that the library distributes, the ClaudeFast Code Kit ships 20+ production skills, 18 specialized agents, and a team orchestration system ready to catalog and share. Start building your library from battle-tested components instead of blank files.