First five minutes as a publisher — shipping your first skill
Sign in, write a manifest, paste a markdown body, click submit. The registry takes care of signing, versioning, and discovery.
You should publish if...
- You've written a system prompt that does one job well and you keep copy-pasting it across projects.
- You've built an MCP server for your team's tools and a friend keeps asking how to install it.
- You've built an agent on top of an LLM SDK and want a stable URL others can call.
If any of that is you, your three minutes of work today saves your peers a week.
Step 1 — sign in
Go to /publish. Sign in with GitHub. The registry uses your GitHub
identity for two things:
- Your handle.
/publishpage → your handle is<github-username>. This is how consumers cite you. - Sigstore signing. Each publish event is signed via Sigstore's keyless flow, bound to your GitHub identity at the moment of publish. The signature is verifiable by anyone, post-hoc.
You don't manage keys. You don't upload a PGP file. The signing flow is invisible because Sigstore makes it invisible.
Step 2 — pick what you're shipping
The publish form starts with the entity type. Three choices:
- Skill — you have a markdown playbook. Paste it; the registry hashes it; done.
- Agent — you have a deployed endpoint or a system prompt + tool contract you want consumers to invoke. The form asks for the service URL (if any) and the model compatibility list.
- MCP server — you have a server speaking MCP. The form asks for the service URL + the tool list.
If you're shipping all three together, jump to /publish/bundle
instead — the wizard handles cross-linking dependencies for you.
Step 3 — fill in the manifest
The form is friendly but the underlying schema is strict. The fields that matter:
- id —
<your-handle>/<short-name>. Lowercase + hyphens. Sticky forever; pick something specific. - version — semver (
0.1.0,1.4.2). Bump major for breaking changes; minor for adds; patch for fixes. - description — 1–2 sentences. Shows up in search results, OG cards, RSS. Treat it like marketing copy.
- capabilities — short tags like
release-notes,pdf-extract. Searchable. - dependencies — other skills/agents your thing pulls in. If your
agent invokes
amitte/repo-conventions-checker, list it here withkind: invokesso the graph view picks it up. - license — pick from the SPDX dropdown. CC-BY-4.0 is a sane default for prompt content; Apache-2.0 for code-bearing things.
Step 4 — submit
The submit button kicks off the validation pipeline:
- Schema parse — your manifest must satisfy
ManifestSchema. - Body validation — for skills/agents, the body is sanitized and length-checked.
- Sigstore sign — keyless flow against the in-flight GitHub token. Produces a transparency-log entry.
- Index — the entity is now searchable.
- Eval queue — a backend worker runs adversarial + content evaluators in the background. Scores show up on the detail page within a few minutes.
If anything fails, the form shows you exactly which step + which field, with a link to the schema doc.
Step 5 — share + iterate
The detail page is your published artifact. Share the URL. Tweet it. Drop it in your README. Consumers can:
- Browse it at
/s/<your-id>. - Pull it via
amitte pull <your-id>. - Verify it via
amitte verify <your-id>@<version>.
When you ship a fix, bump the version and submit again. Old versions
stay accessible at /s/<id>?v=<old-version>. You don't break
existing consumers; they upgrade on their own schedule.
Step 6 — get verified (optional, ten minutes)
Hit /publish/verify-domain, paste your domain, add the TXT record
the page tells you to, click verify. Your handle now carries the
green check, and every entity you ship inherits the verified badge.
That's it. You're a publisher.
Common mistakes first-time publishers make
- Picking too generic an id.
acme/agentis bad;acme/release-notesis good. Names are forever. - Skipping the description. A search hit with no description gets clicked half as often as one with a clear sentence.
- Not declaring dependencies. Even
kind: documentsdeps show up on the graph and help consumers understand what they're getting. - Stuffing capability tags. Five well-chosen tags beat fifteen noisy ones. Searches are stemmed but more tags ≠ more discovery.