Skill Registries and Marketplaces

Beyond a Folder on Disk

The free course’s Skill Discovery lesson covered how an agent finds skills sitting in .claude/skills/, ~/.claude/skills/, or a plugin. That works well at the scale of one project or one person’s machine. It stops working once an organization has hundreds of skills, written by many different teams, and someone starting a new project has no way to know most of them exist. A registry is the answer to that specific problem — the same relationship Docker Hub has to a local image cache, or npm has to a project’s node_modules.

Core Operations

Publish. A CI/CD pipeline’s final stage, from the previous lesson, pushes a versioned, packaged skill to the registry — making it centrally discoverable rather than living only in whatever repository it was written in.

Install. A consumer — a person or a project’s CI setup — pulls a specific skill (and version) from the registry into their own environment, the way npm install or docker pull works today.

Search. Given that hundreds of skills might exist, a keyword or free-text search over names and descriptions is the baseline discovery mechanism — “find anything related to invoice processing.”

Semantic search. Keyword search misses a real query like “help me route this expense for approval” against a skill named finance-workflow-router with no literal word overlap. Semantic search — matching on meaning rather than exact terms — closes that gap, and matters more for skills than for typical package registries precisely because a skill’s whole activation mechanism (per the free course’s discovery and description lessons) already depends on semantic matching, not keyword matching.

Dependencies. A skill can reasonably depend on another — a document-intelligence composition (from Skill Composition) that assumes an OCR skill is also installed. A registry needs to express and resolve this the way a package manager resolves a dependency graph, rather than leaving consumers to discover a missing dependency only when something fails at runtime.

---
name: document-intelligence
description: Extracts and validates structured data from scanned documents.
metadata:
  version: "1.4.0"
  depends_on:
    - "ocr-processor@^2.0.0"
    - "field-validator@^1.1.0"
---

Trust. Search results need trust signals beyond relevance — who published this, has it been reviewed, what trust level does it carry (per Security and Governance). A registry that ranks purely on description-match relevance, with no visibility into provenance or review status, makes the semantic supply-chain risk from that lesson easier to exploit, not harder — a well-written, deceptive description would rank exactly as well as a legitimate one.

Ranking Is a Design Decision, Not Just a Search Problem

How a registry orders search results shapes which skills actually get adopted, which makes ranking a governance decision as much as a technical one. Pure relevance ranking rewards whoever writes the most keyword-dense description, independent of quality or trust — exactly the incentive that produces more of the “Vague Description” and “over-broad description” problems from earlier in this course, just aimed at gaming a ranking algorithm instead of triggering correctly. A registry serving an organization, not just the public, can and should weight ranking toward signals relevance alone can’t see: review status, trust level, and — once enough usage history exists — the benchmark and reliability data from Testing and Evaluation at Scale.

The Docker Hub / npm / PyPI Comparison, Precisely

The analogy is useful but not exact, and the differences matter:

The biggest practical difference: a package manager can often verify a package does what it claims through automated testing of a fixed interface. A skill’s “interface” is natural language, interpreted differently by different models — which is exactly why the trust and review layer matters more here than it does for a typical package registry, not less.

Building vs. Buying

Not every organization needs to build a full registry from scratch on day one. A minimal version — a shared Git repository of packaged skills, a README acting as a manual index, and CI enforcing the pipeline from the previous lesson before merge — covers publish, install (via git pull or a package step), and a basic form of search (repository search) well enough for a small number of skills. Full semantic search, dependency resolution, and ranking become worth building deliberately once the number of skills and the number of distinct teams publishing them both grow past what a manually-maintained index can keep up with.

Summary

• A registry solves the discovery problem that filesystem-based scanning (the free course’s model) doesn’t scale to: finding a skill you don’t already know exists, across an entire organization
• The core operations are publish, install, search, semantic search, dependency resolution, and trust signaling — each with a direct analogy to Docker Hub, npm, or PyPI, but not an exact one
• Ranking is a governance decision, not just a relevance algorithm — pure keyword relevance rewards the same over-broad, keyword-stuffed descriptions the rest of this course has flagged as a quality and security problem
• The biggest structural difference from a code registry: a skill’s interface is natural language interpreted with judgment, not a fixed, testable signature — which is why trust and review carry more weight here than in a typical package ecosystem

You’ve now covered every practice this course set out to teach — patterns, quality, engineering, architecture, composition, multi-agent systems, testing, security, lifecycle, CI/CD, and registries. The capstone puts all of it together into one real deliverable.