Documentation

Everything you need to use the registry — and to publish into it when submissions open.

Getting started

The registry has one primitive: a skill — a documented, versioned capability you can install and pin. Browse the catalog, open a listing, read its README, and install the exact version you want.

$ skillbank search pdf
$ skillbank show pdf-analyst
$ skillbank install pdf-analyst@1.4.2

noteThe skillbank CLI shown here is illustrative — it describes the registry's intended interface while the project is in preview.

Using a skill

Every listing page follows the same README shape:

Overview — what the skill does and doesn't do.
Installation — the exact pinned install command.
Configuration — a commented config file with defaults.
Inputs — a table of every input, its type, and whether it's required.
Changelog — the full version history, breaking changes flagged.

Read the inputs table before first use; several skills (e.g. sql-assistant) ship with safety guardrails you should understand.

Version pinning & semver policy

All skills follow strict semantic versioning. The registry enforces the policy at publish time:

Major (2.0.0) — breaking changes: renamed inputs, removed behavior, new required config. Old majors stay installable forever.
Minor (2.1.0) — backwards-compatible additions: new optional inputs, new features.
Patch (2.1.1) — bug fixes and maintenance only. No new inputs, no behavior changes.

Pin production to an exact version (sql-assistant@3.0.1). Use a minor range (web-scraper@2) only in development — minor releases add features, and features can surprise you.

Publishing a skill

Submissions are not open yet, but the bar is already set. A publishable skill is a single directory:

my-skill/
  skill.yaml        # manifest: name, version, license, inputs
  README.md         # must meet the README requirements below
  CHANGELOG.md      # every version, newest first
  prompts/          # system prompts and templates
  examples/         # at least one worked example

The manifest pins the license per version and declares every input with a type. The registry validates the manifest, renders the README, and freezes the version — published versions are immutable.

Naming rules

Lowercase, hyphen-separated: invoice-parser, not InvoiceParser.
Descriptive of the job, not the model: email-triage, not gpt-email.
No squatting on generic single words, no trademarks, no misleading prefixes like official-.
Names are first-come within the registry; disputes go through the takedown process (to be published with the pipeline).

README requirements

A listing is rejected without all five sections:

Overview — one paragraph, honest scope, explicit non-goals.
Installation — the pinned install command, in a code block.
Configuration — a complete config file with every default visible.
Inputs — a table: name, type, required, description.
Examples — at least one end-to-end worked example with expected output shape.

rejectedREADMEs that are only marketing copy, or that document inputs the skill doesn't actually accept, fail review.

MCP server spec notes

Skills flagged MCP map onto Model Context Protocol tool surfaces. If you maintain both a skill and a server:

Server and skill versions move independently — the directory lists server versions, the catalog lists skill versions.
stdio servers must document every environment variable they read; SSE servers must document their auth scheme.
Tool names on the MCP surface should match the skill's input names where the semantics are identical, so agents can transfer knowledge.
Destructive tools (write, delete, send) must be marked as such in the server's README and require explicit confirmation by default.

See the server directory for the listing format.