Transfer a skill

Transfer changes who owns a skill. Use it when you want to hand a personal skill over to your organization so the team owns it, or pull an organization skill back to your personal account.

If you only want to give a skill a different name, you do not want transfer. You want rename.

Who can transfer

• Into an organization: you must own the skill, AND be an owner or admin of the target organization.
• Out of an organization (back to a personal account): only the owner of the organization can do this, and they can only transfer it to themselves. Admins cannot transfer skills out.

This stops a regular member or admin from quietly walking off with a team skill, while still letting team leads bring new skills in.

When to use it

The common case is: you wrote a skill on your personal account. The team finds it useful and you want it to live in the organization so anyone there can edit it, the organization keeps it after you leave, and updates flow to the whole team.

airskills transfer my-ruby-workflow --to-org acme

The reverse also works — pulling an organization skill back to your personal account, only the organization owner can do this (admins can't):

airskills transfer acme-ruby-workflow --to-user

The CLI shows you what's about to happen and asks you to confirm before anything moves.

What people see

Three groups of people are affected by a transfer. Each one sees something different.

You (the person doing the transfer)

For a transfer into an organization, the skill is now an org asset delivered through skillsets — so your local copy is removed from every detected agent (~/.claude/skills/, ~/.cursor/skills/, etc.), backed up first to ~/.airskills/undo/<timestamp>/ so nothing is lost. To use it locally again, add it to an org skillset and make sure that skillset is assigned to you:

airskills org skillset add-skill <skillset> my-ruby-workflow --org acme
airskills org member skillsets <you> --add <skillset> --org acme
airskills sync

For a transfer back to your personal account (--to-user), the skill becomes your personal skill and your local copy stays in place, re-linked to the new owner.

Other members of the organization you transferred into

On their next airskills pull, the new skill appears in their list as a fresh organization skill. They install it the same way they install any other skill the organization owns.

People outside your organization who had already installed your skill

This is the part to think about. Anyone who had previously run airskills add <your-username>/my-ruby-workflow will see this on their next pull:

! my-ruby-workflow: upstream archived. Local copy kept.

Their copy is not changed. It is not deleted. They keep using exactly what they had. If they want to follow the skill to its new home, they need to run airskills add acme/ruby-workflow themselves — which means someone has to tell them where it went. That's the trade-off: transfers are deliberate and visible, never silent.

If they push the kept-local copy after the upstream is archived, it lands in their own namespace as a skill they now own.

What it costs

Transfer is permanent in the practical sense — the old slug returns 410 Gone afterwards. URLs, install commands, and bookmarks pointing at the old slug stop working. Plan a small announcement when you do this for a skill that has external users.

Transfer is not rename

A common mistake: trying to use transfer to give a skill a new name. Transfer is for changing ownership, not the label. If your skill is called ruby-workflow and you want it called ruby-style-guide, that is a rename, even if you never change owner.

A useful way to think about it:

• Rename = "I'm calling this thing a different name." No one but you cares. Your consumers do not see anything change.
• Transfer = "This belongs to a different account now." The skill effectively moves house. Old address stops working.

Restoring a transferred skill

A transfer is a soft action under the hood — your old skill is archived, not destroyed. If you change your mind and the new owner agrees, you can restore it:

airskills restore my-ruby-workflow

This brings back the skill at the old slug, with the content it had at the moment of transfer. It does not undo any edits the new owner has made on their copy in the meantime. The two skills now exist independently.

---

Deep dive: how transfer works

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

A transfer is implemented as soft-delete + create, not as a slug rewrite. When you run airskills transfer my-ruby-workflow --to-org acme:

1. The skill <your-username>/my-ruby-workflow is soft-deleted, the same way airskills rm would soft-delete it. The row stays in the database with deleted_at set; storage objects are retained.
2. A new skill acme/my-ruby-workflow is created with the content forked at the moment of transfer.
3. Any request to the old slug — API, public page, install command — returns 410 Gone with a body explaining how to restore.

There is no redirect — requests to the old slug do not silently serve the new skill. The archived row does record where the skill went (a forward pointer to its successor), so consumers who can already see the new location get told about the move on their next sync; everyone else gets a plain 410. This is intentional: ownership changes surface as a visible event ("we moved Chris's Ruby skill into the organization as acme/ruby-workflow") rather than being masked behind silent CLI behaviour.

The consumer-side warning lives in airskills pull, which compares each sourced skill in the local sync state against the API. A 410 on the old slug becomes the "upstream archived" message; the local files are never touched.