How the registry works

DevKit is a registry of Claude skills. A skill is a folder: a SKILL.md and whatever else that skill needs. It is published here, and it lives in this registry's database - not in a repository, and not in the container image.

Every skill belongs to an account, and a skill is named by both: @you/deploy-pipeline. Two developers can each have a deploy-pipeline and they are different skills. A bare name still resolves while it points at one thing, and you get an error naming the candidates when it does not - nothing here guesses which developer you meant.

Accounts

The first person to reach an empty registry claims it and administers it. After that, whether anyone else may join is a setting: an admin opens registration at settings, and people sign up at /register.

Everyone gets a namespace. Your page is /@you, your skills are yours to publish, edit and delete, and you see your own plus whatever other people have shared. Nothing else.

Sharing takes two decisions on a shared registry. Marking your skill public is a request; an admin approves it before the world can install it. Your own switch is enough if you are the admin, so a registry with one account has no extra step at all. The reason for the gate is plain: a skill is text that Claude reads as instructions on whoever installs it, and nothing detects that reliably, so a person looks.

Forking

Anything you can read, you can copy into your own namespace:

devkit fork @someone/deploy-pipeline --as my-pipeline

A fork takes the files as they are now, at version 1.0.0, private, and records where it came from. It does not follow the original afterwards - a skill whose contents change because somebody else decided so is the one thing a skill you rely on must not be. The digest of what you forked is kept, so "has this diverged" stays answerable.

Explore is where you find things to fork: everything people here have shared, and who publishes it.

There is no separate manifest. The YAML frontmatter at the top of SKILL.md is the metadata this site renders, and the body below it is the instruction set Claude loads. One file, one source of truth.

To add a skill you publish it, either from the editor or from a folder on your machine:

devkit publish ./my-skill

It is live immediately. There is no build, no pipeline, and no wait.

Versions are immutable. Publishing a version that already exists is refused, so an edit means bumping version: and publishing again. Every version is addressed by a content digest, which is what lets an install pin exactly what it received and a rollback be a matter of installing the previous one.

The install command

Every skill exposes a canonical install command:

curl -sSL -H "X-Install-Token: <your-token>" https://devkit.chempa.dev/install/@owner/<name> | sh

The owner is part of it because the name alone is not unique. A command without one still works while it points at a single skill, and fails with the list of candidates rather than picking when it does not.

The endpoint is token-gated. Every copy-curl button on this site already has a token inlined - just copy and paste. That token is signed and expires after a day, so a command pasted into a chat log stops working on its own; reload the page for a fresh one. Requests without a valid token (header X-Install-Token, Authorization: Bearer …, or ?token=…) get a 401 and an error script that prints the reason and exits 1. (The command uses -sSL rather than -fsSL on purpose - -f discards the response body on an HTTP error, which would turn that message into a silent no-op.)

The URL returns a small shell script that:

1. downloads /api/archive/<name> - a tar.gz of the skill folder, re-using the same token
2. unpacks it into ${CLAUDE_HOME:-~/.claude}/skills/<name>/, replacing any existing copy
3. pings the install counter, best-effort

It needs curl and tar and nothing else - no git, no SSH key, no clone. Set $CLAUDE_HOME to install somewhere other than ~/.claude.

Installing replaces the target directory outright. Anything you edited by hand inside ~/.claude/skills/<name>/ is lost on reinstall.

The CLI

devkit is the same registry from the terminal. Install it from here rather than from npm - the copy you get is the one built alongside the server you got it from:

curl -sSL https://devkit.chempa.dev/install/cli | sh

No token: the CLI is a client, not content, and needing one to fetch the tool you use to log in was a circle. It needs curl, tar and node 20+, and the tarball carries its one dependency, so nothing is fetched from a package manager. It unpacks into ~/.devkit/lib and puts a devkit launcher on the first writable directory it finds on your $PATH, telling you what to add if there is not one.

Skills

devkit list                      # the catalogue
devkit list --installed          # what is on this machine
devkit search mongo
devkit info maintainability
devkit install @someone/maintainability   # or @someone/maintainability@1.0.0
devkit install maintainability            # fine while the name is unambiguous
devkit fork @someone/maintainability      # copy it into your namespace
devkit update                             # refresh everything, each from its owner
devkit uninstall maintainability

An install verifies the content digest against what the registry says it sent, and records the version and the registry it came from beside the skill.

Authoring

devkit init my-skill       # scaffold a folder that already validates
devkit validate my-skill   # the server's own checks, run locally
devkit publish my-skill

validate runs the exact function the server judges a publish with, so it cannot pass locally and fail on upload for a different reason.

Several registries at once

One machine, many registries - a client’s, your own, a staging box. The CLI stays logged in to all of them and always resolves one explicitly:

devkit login https://devkit.acme.com --as acme   # prompts for the token
devkit registries    # list them, marking the active one
devkit use acme      # change the default
devkit whoami        # which one is active, and why
devkit list -r other # override for a single command

The token is typed at a hidden prompt rather than passed as an argument, so it does not end up in your shell history or in ps. For CI there is --token <value>, the DEVKIT_TOKEN variable, and --token - to read one from a pipe.

Which registry a command uses, most specific first:

1. --registry <name|url>
2. DEVKIT_REGISTRY
3. .devkitrc.json - {"registry": "acme"} - in the working directory or any parent
4. the default set by devkit use

The third is the one worth setting up. A repo that pins its registry means a contributor publishes to the right place without being told, and cannot quietly publish an internal skill to their own default instead.

Config lives in ~/.devkit/config.json, written owner-only because it holds tokens. Point $DEVKIT_HOME somewhere else to keep experiments away from your real logins.

Frontmatter spec

A complete SKILL.md looks like this - everything above the second --- is metadata:

---
name: claude-skill-summarizer
description: Claude skill that summarizes any document, URL, or codebase in one command.
version: 1.2.0
author: anthropic-labs
license: MIT
tags: [ai, claude, summarization]
status: stable
featured: true
created: 2025-08-12
updated: 2026-05-10
installs: 18420
---

# claude-skill-summarizer

A drop-in Claude skill for high-fidelity summarization.

## Usage

```bash
claude /summarize ./README.md
```

The parser is deliberately not a full YAML implementation - it handles key: scalar and inline lists, and throws on anything else (nested maps, block sequences, multi-line scalars) rather than mis-parsing it.

Writing a skill

The body below the frontmatter is the skill itself - the instructions Claude loads, and what this site renders on the skill’s page. Keep it focused; put detail in sibling files and tell the model to read them on demand:

skills/
  code-reviewer/
    SKILL.md          ← required
    references/
      checklist.md    ← shipped, loaded only when SKILL.md says to

Every file in the folder ships in the tarball, so anything you add is available on the user’s machine after install.

The full flow - scaffold, validate, publish ›

Public API

The registry is exposed as a read-only JSON API:

• GET /api/skills - paginated list
• GET /api/skills/:name - one skill, including its body
• GET /api/skills/search?q=… - full-text search
• GET /api/tags - all tags with usage counts
• GET /api/featured - the featured skills
• GET /api/archive/:name - tar.gz of the folder (token-gated)

List responses omit the body field; fetch a single skill to get it.

Validation

devkit validate runs the same checks locally, before you publish. It parses each SKILL.md with the same code the site uses, so a green run means the catalogue will build. It checks:

• folder name is a valid slug and matches name
• frontmatter parses, with all required keys and no unknown ones
• SemVer version, known status, SPDX license
• description length, tag count and format, date format
• a non-empty body

Ready to add a skill? Start here ›