Developer guide

What this is

A skill is a folder an AI agent loads: instructions in SKILL.md, plus any scripts, references and assets it needs. The format is the Agent Skills specification, not ours — a skill that works here works anywhere that implements it.

Nothing on this page needs anything installed. If you would rather work from a terminal, the Command line tab above does the same things with one command each.

Find a skill

Explore lists everything published, newest first. Filters opens the sort and the categories beside the results; the switch above them shows the catalogue as cards or as a list.

Search reads meaning as well as words, so you can describe the task rather than guess the name — make an animated picture for chat finds a Slack GIF skill that shares none of those words with it. If nothing contains every word, the results say so and offer what is related instead of pretending to match. Press / from anywhere to jump to the box; on a phone it sits under the header on every page.

A skill's page shows its description, the whole file tree, and any file you click, so you can read exactly what an agent would load before you install it.

Install a skill

1. Open the skill and pick a version from the dropdown, or take the latest.
2. Press Download. You get a .skill file, which is a zip.
3. Unzip it into your agent's skills directory. For Claude Code that is .claude/skills/ in the project, or ~/.claude/skills/ for every project.

Cursor and opencode read skill folders too — Cursor from .cursor/skills/, opencode from .opencode/skills/ — and both also read .claude/skills, so one unzip can serve all three. For an agent that reads one project file rather than a folder — Codex from AGENTS.md, Gemini CLI from GEMINI.md — paste the instructions out of SKILL.md into that file, leaving the --- header behind: the header is how this catalogue describes a skill, not something those agents read. The CLI does this placement for you with -for, and verifies the download's digest while it is at it.

~/.claude/skills/
└── llmskillhub/
    ├── SKILL.md
    └── ...

The archive contains one top-level folder named after the skill, so unzipping it there gives you exactly that layout.

A private skill opens only for its owner and the people they have shared it with, signed in; download works the same way. To have an agent install one, use Copy prompt on its page: it installs straight away if your CLI is already signed in with a token that reaches the skill, and otherwise walks you through creating one — the token is pasted into llmsh login in your own terminal, never into the chat.

Anatomy of a skill

my-skill/
├── SKILL.md          # required: the manifest and the instructions
├── scripts/          # optional: code the agent can run
├── references/       # optional: documentation it can read on demand
├── assets/           # optional: templates, images, data
└── examples/         # optional

Only SKILL.md is required, and only those four directory names are recognised. Anything else is allowed — you will see a note at publish, but nothing is refused for its layout.

The manifest

YAML frontmatter at the top of SKILL.md. Two fields are required.

---
name: llmskillhub
description: >
  How one can create llm skill and publish it to llmskillhub.com
license: MIT
metadata:
  llmskillhub:
    version: 0.1.0
    categories: [agents]
    capabilities:
      network: false
      filesystem: read
      shell: false
      secrets: []
---

# LLM Skill Hub

Guide to creating an LLM skill and publishing it to llmskillhub.com.

## When to reach for this

Instructions for the agent go here...

That is the manifest of zalpha/llmskillhub, a skill published here. Every field below is optional except the first two.

Fields the spec defines

name required

Lowercase letters, digits and single hyphens. Must match the directory name. It is unique to you, not to the catalogue: a skill is addressed as owner/name, so two publishers may each have a pdf-tools and neither blocks the other.

description required

What it does and when to use it. This is the field an agent routes on, so name the phrases someone would actually type. No angle brackets — descriptions are embedded in prompt scaffolding, where they are reserved.

license

A licence name, or a pointer to a bundled file.

compatibility

Environment requirements, if there are any. Most skills need none.

allowed-tools

Space-separated tools pre-approved to run. Experimental in the spec.

metadata

Anything else. Ours lives under metadata.llmskillhub.

metadata.llmskillhub

version

Semver. Without it you pass --version at publish; with it, the publish is refused if the two disagree rather than quietly relabelled.

categories, keywords

How it is found. Both feed search and the category browser.

repository, homepage, authors

Where it came from and who wrote it.

capabilities

What it touches: network, shell, filesystem (none, read, read-write) and named secrets. Worth filling in — it is what tells someone installing your skill what it will do, and it is shown on the page beside it.

Limits

A package well inside these is the normal case — most skills are a few tens of kilobytes. Exceeding one is a refusal rather than a warning, so it is worth knowing before you publish.

Publish a skill

Sign in, then go to Publish. You need an account because a published version belongs to someone.

Write it here

A skill can be one file, and the page will take it that way — there is nothing to zip and nothing to install. Choose write a SKILL.md here and you get a form for the manifest, an editor for the instructions, and a preview of how they will read.

1. Fill in the name, description, licence, version and category. These are the manifest, and the form writes the YAML so the shape of it is never something you have to get right by hand.
2. Write the instructions below, in Markdown. Preview shows them the way an agent's reader will.
3. Press Check this file. The two halves are combined into a SKILL.md, and from there it is the same road a dropped archive takes: the server packs it with the same packer the CLI uses, and the same validation, scanning and review follow.

There is no such thing here as a skill that was published the easy way. A file typed into the page is checked exactly as one that arrived as an archive, and reviewed by the same person.

Or bring a package

A skill with scripts, references or assets is more than one file, so it arrives as an archive.

1. Zip your skill folder. The archive has to contain the folder itself — so my-skill/SKILL.md inside, not SKILL.md at the root.
2. Drag it onto the page. It is checked immediately and nothing is stored yet: you get the file tree on the left, the verdict in the middle, and what the package declares on the right.
3. Read the report. Anything wrong is listed with the file and line it came from.
4. Choose where it goes. Public puts it in the catalogue, after a person has read it. Private puts it in your own space: available to you at once, not reviewed, and not listed anywhere anyone else can see. Then submit.

If your SKILL.md has no frontmatter, the page offers to write it: fill in the name and description and it hands you back a corrected .skill file. Download that — it is the package that gets published, so the next one you make should start from it.

Every public version is reviewed before it is listed, including updates to a skill that is already public. The live version keeps serving while the new one waits, so publishing never takes your skill down. If you send several versions while one is still waiting, approving the newest discards the older ones still in the queue; a version that was approved is never removed. Your account shows where each one has got to.

Private skills and sharing

Your space is where private skills live. Nobody else sees them — they are not in Explore, not in search, not over the public API, and reviewers do not see them either, because they are never reviewed. Publish into it by choosing Private when you publish; a new version is available the moment it is stored.

Sharing is per person, from your account or the skill’s own page. Someone who can read sees the skill and installs it; someone who can read and publish can also publish new versions of it, from the website or with llmsh publish owner/name. Taking someone off the list takes their access with it.

Moving a skill between your space and the catalogue is on its page. Making a private skill public sends its versions into review, and it is listed once a person has approved one; making a public skill private takes it out of the catalogue at once and ends any review still waiting.

Removing a private skill is final: it is deleted, files and all, within minutes, and cannot be restored. A public skill is only delisted, so anyone who pinned a version keeps working.

The command line reaches private skills with a token whose reach includes them — see Tokens.

Evals

An eval is the second kind of package: a set of cases for measuring how well a skill, or an agent, does a job. Explore’s Kind filter lists them on their own, and every eval’s card and page carries an eval tag.

my-eval/
├── manifest.yaml      what it measures, its licence, and which columns hold what
├── dataset.jsonl      one case per line: an input, and what a good answer contains
└── rubrics/           optional: how an answer should be judged, in prose

Write one here: on Publish, choose An eval and fill in what you are measuring, how an answer should be judged, what fraction has to pass, and the cases. Or drop a package with the layout above. A public eval is reviewed like a skill; a private one goes straight to your space.

Using one: download it from its page, or llmsh install owner/name, which puts it in ./evals. An eval is data, not instructions — it does not belong where your agent loads skills, and its cases are test input, never commands.