First five minutes as a publisher — shipping your first skill

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. /publish page → 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 with kind: invokes so 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:

1. Schema parse — your manifest must satisfy ManifestSchema.
2. Body validation — for skills/agents, the body is sanitized and length-checked.
3. Sigstore sign — keyless flow against the in-flight GitHub token. Produces a transparency-log entry.
4. Index — the entity is now searchable.
5. 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

1. Picking too generic an id. acme/agent is bad; acme/release-notes is good. Names are forever.
2. Skipping the description. A search hit with no description gets clicked half as often as one with a clear sentence.
3. Not declaring dependencies. Even kind: documents deps show up on the graph and help consumers understand what they're getting.
4. Stuffing capability tags. Five well-chosen tags beat fifteen noisy ones. Searches are stemmed but more tags ≠ more discovery.