Share a skill

You've written a skill and a colleague wants to use it. Neither of you is in a shared organization. You don't want to transfer ownership to them, or move it into an organization. You just want them to have access.

That's sharing:

airskills share chrismdp/code-review --with alice@acme.com

Alice gets an email. She can then install the skill:

airskills add chrismdp/code-review

And that's it. Alice has access, you still own the skill, no ownership changes hands.

How it's different from transfer

• Share gives someone permission to see and install your skill. You still own it. You can revoke share access. The skill stays in your namespace.
• Transfer gives someone the skill itself. Ownership moves. You lose edit rights (unless you're in the receiving organization). You can't undo it without the new owner's cooperation.

If you're hesitating between the two, start with share. It's reversible.

How it's different from organization skills

Sharing with a specific person is a one-off grant. If you find yourself sharing the same skill with most of your team, you probably want it in an organization skill instead — one change there reaches everyone, and new joiners get it automatically.

Sharing is great for:

• A skill a handful of people want
• Someone outside your organization you trust
• Test-driving "would my team find this useful?" before promoting it

Organization skills are great for:

• Anything your whole team should have
• Skills that change often (one update reaches everyone)
• Governance (admins decide who gets what)

Who can change an organization skill

Write access to an organization skill follows your role in the org:

• Owners and admins read and write. An admin edits the skill locally and runs airskills push — it updates the org skill in place. (Behind the scenes push always tries the direct write first and the server authorizes it by your owner/admin role — the CLI never needs to know your role; the server's answer is the role check.)
• Members read, then suggest. A member can sync and edit an org skill locally, but push does not overwrite the shared copy: the server rejects the direct write (403). Instead the CLI backs the member's version up to their own account and asks one question — suggest these edits to the org? (In a terminal it's a prompt; headless, the decision is deferred — push --force-suggest submits it without asking.) An owner or admin reviews the suggestion with airskills review and accepts or declines. Either way the member's edits are never lost.

So the same edit-and-push gesture does the right thing for everyone: admins publish, members propose.

You can share skillsets too

The same share command works on skillsets — a skillset being a curated group of skills you can install as one unit:

airskills share chrismdp/starter-pack --with alice@acme.com

Alice then gets access to every skill inside the skillset in one step.

Revoking a share

If you need to take back access, remove the share from the skill's page in the dashboard. The person will still have whatever they already installed locally — sharing controls future access to pulls and installs, not files that have already been copied to someone's disk.

---

Deep dive: how share works

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

A share grants a row in skill_shares linking the skill's ID to a user ID, not an email. Sharing by email first resolves the email to a user. If no user exists with that email, the share is queued pending signup — they'll get the access the first time they log in with a matching email.

Shares are enforced by RLS policies on the skills table: a row is visible to its owner, to members of the owning organization, and to anyone who has an active row in skill_shares pointing at the skill. Revoking deletes the skill_shares row; RLS then makes the skill invisible to that user on their next request.

Sharing does not affect write permissions. A shared skill is read-only to the recipient — they can install and update it, but not edit it or push new commits. Edit rights require ownership.