How skills are named

When you install a skill, you'll see it referenced two ways:

airskills add chrismdp/code-review
                └───────┬───────┘
                a "slug" — the skill's name

The slug is how people and tools refer to a skill. It shows up in:

• CLI commands (airskills add chrismdp/code-review)
• The skill's public page URL (airskills.ai/chrismdp/code-review)
• The directory name on disk (~/.claude/skills/code-review/)

Personal skills: just a name

If you own a skill, its slug is just its name:

code-review
release-email
pr-etiquette

You can have any name you like, as long as no other skill you own is using it.

Organization skills: prefixed with the organization's name

If an organization owns a skill, its slug carries the organization's name in front:

acme-code-review
acme-release-email
acme-pr-etiquette

The prefix makes it obvious at a glance who owns a skill, and means two organizations can both have a code-review skill without stepping on each other.

Naming rules

• Lowercase letters, numbers, and hyphens only ([a-z0-9-]+).
• No leading or trailing hyphen. No double hyphens.
• Up to 64 characters.
• Unique within the owner — you can't have two skills called code-review in your personal account, and an organization can't have two skills called code-review either.

If you type a name with capital letters or spaces, the server automatically converts it — Code Review becomes code-review.

How slugs change

A slug only changes when you change it, in one of two ways:

• Rename — keeps the owner the same, changes the name part: code-review → pr-etiquette.
• Transfer — changes the owner (and the prefix): code-review → acme-code-review.

Either way, the old URL stops resolving. Skills do not move silently.

Some reserved names

A handful of names are held back for the site itself, so you can't take them as usernames or skill slugs. They include api, auth, dashboard, docs, login, mcp, organization, security, and a few more. If you try to use one, the server will tell you and offer a nearby alternative.

---

Deep dive: slugs vs skill IDs

For curious developers — skip if you just want to use it.

The slug is how humans refer to a skill. Internally, every skill has a UUID skill_id that never changes, even if the slug does. The CLI stores both — the slug for display, the skill_id for fetching updates. This is what makes rename consumer-transparent: on pull, the CLI asks the server for the same skill_id and the new slug comes back as part of the metadata.

When a skill is transferred, a genuinely new skill (new skill_id) is created at the new slug; the old one is soft-deleted. The old slug returns 410 Gone, and consumers see an "upstream archived" message on their next pull rather than being silently redirected.

Slugs are derived from the name field on the skill row via a slugify() helper: lowercase, collapse non-alphanumerics to hyphens, strip leading/trailing hyphens. For organization skills, the server prepends <organization-slug>- before the slugified name. The CLI does not invent slugs — it sends the name and trusts the server's derivation.