Claude can now share skills between colleagues. Here is the difference between sharing and a library

Anthropic has switched on sharing skills and plugins with specific people or groups inside Claude. A member on a Team or Enterprise plan opens Customize, clicks the three-dot menu next to a skill they built, chooses Share, and picks colleagues by name. The recipients find it under “Shared with you”, switched off until they turn it on. When the owner saves a new version, everyone they shared it with gets it the next time they use it.

We build shareskills, so you would expect us to have opinions about this, and we do. The first is that it is good news, said without gritted teeth. Every argument on this blog rests on the claim that skills are the unit in which organisational know-how now travels, and that people need a way to hand them to each other that is not a zip file in a chat thread. The largest vendor in the space has just agreed, in product form. The second opinion is the subject of this post: sharing a skill and running a skill library are different jobs, and the gap between them is exactly the gap an organisation falls into somewhere around its fortieth skill.

What the native feature does, in plain terms

Read the two help-centre articles together, the one for users and the one for admins, and the shape is clear. Sharing is person-to-person: a skill you created, offered to named colleagues, to a group if you are on Enterprise and an admin has switched groups on, or to the whole organisation if an admin has switched that on too. Recipients get a view-only copy. They can enable it and use it; they cannot change it. Updates flow automatically from the owner. Access ends when the owner removes it, or when the recipient leaves the organisation. Share events land in the audit log, though not the contents of what was shared, and the article says plainly that there is no admin screen for inspecting skills passed between users. The whole thing lives where Claude skills live today: chat on the web, the Chat tab in Claude Desktop, and Cowork.

That is a well-judged first version for the job it is built for: one person, one colleague, one useful skill, no ceremony. If your organisation is a dozen people who mostly work in claude.ai, it may be all you need, and you should use it.

An inbox is not a library

Here is the distinction we would draw. Sharing puts a copy of your thing in my list. It is an inbox: items arrive, attributed to a sender, and I switch them on or ignore them. A library is a different object. Things in it belong to the organisation rather than to whoever typed them first. They have a history. They can be improved by people other than their author, under rules. Someone is responsible for what is in it and can see all of it. And it does not care which tool you open it from.

Every one of those properties is something the inbox model, by design, does not have. Not because Anthropic missed them, but because peer-to-peer sharing is the wrong primitive to hang them on. Below are the five that bite first, with what shareskills does about each and, where it is honest to say so, what we do not do.

1. Who owns it

In the sharing model the skill is the owner’s. It sits in their Customize, they decide who sees it, and their account is where it lives. The help centre describes what happens to a recipient who leaves: their access is removed automatically. It says nothing about a skill whose owner leaves, and we would not want the future of a team’s contract-review playbook to depend on the answer.

On shareskills a skill belongs to the team from the moment it is created. The person who made it is its author, with direct-edit rights, but the folder, its versions and its change notes are the organisation’s. When someone leaves, an owner or admin removes them and decides, in the same step, what happens to the skills they authored: take them over or delete them. Either way the version history and every attributed change stay put. Nobody discovers three months later that the skill the whole sales team ran was living in a departed colleague’s account.

2. Who may improve it

Shared skills in Claude are view-only. A colleague who spots a mistake in your skill can tell you about it, or copy it and fork it. What they cannot do is fix it in place, and what you cannot do is review their fix. So the best skills, the ones many people use and many people have opinions about, accrue their improvements in chat threads and private forks. At the other end of the scale, publishing to the whole organisation has no review step at all:

This is the problem we built our review flow for. On shareskills a member’s edit to somebody else’s skill becomes a change request: the proposed change, waiting on the approvals page for an owner or admin to approve or reject. Members create and edit their own skills directly, and the step that takes a skill outside the organisation, publishing it to the public directory, is held back to admins. It is the pull-request idea for people who will never open a pull request, and it is the difference between a skill that decays and one that gets better because more people use it.

3. What happens when it changes

In the sharing model, when the owner saves a new version, every recipient gets it automatically the next time they use it. That is convenient, and it is also quiet: the help centre describes no notification, change note or history alongside that update. The recipient simply runs whatever the owner saved last. If the owner’s account is compromised, or the owner simply makes a mistake, it reaches everyone at the same speed.

shareskills also delivers updates from within your own team without a consent prompt; we wrote up why, and the short version is that a gate on every internal tweak trains people to click yes. What internal changes get instead is visibility. Every version records its author and change note. Collaborators are notified when a skill they care about changes, with a label when the change added anything material, such as new shell execution or a network call to a host the skill never talked to before. Admins are alerted when a widely installed skill gains a material change. And a skill from another organisation, installed from the public directory, is held at the door when a material update arrives, until a human approves that exact version.

4. What an admin can see

The audit log in Claude records the share event: who shared what with whom. It does not record the contents, and there is no admin view for inspecting what is circulating. An organisation can therefore know that skills are being passed around without knowing what any of them say.

On shareskills a team-visible skill is visible to every admin, in full, with its history, and the team audit log records who created, changed, reassigned or deleted a skill and whether they did it from the website or through an agent. The one deliberate exception is a private skill, which only its collaborators can see, admins included. We think a private draft should stay private; we also think that the moment it is offered to the team it should be readable by the people responsible for the team.

5. Where it runs

Skills shared inside Claude appear in Claude: the help-centre article lists chat on the web, the Chat tab in Claude Desktop and Cowork, and does not mention Claude Code or any other tool. Meanwhile the skill format itself is an open standard that around forty products now read, and the packaging standard around it, Agent Plugins 1.0, was written by Amazon, Microsoft, OpenAI, Cursor, GitHub and Vercel together. The people who most need a skill to actually run are often in a terminal, not a chat window.

shareskills is an MCP server, so it reaches any client that speaks MCP: Claude Code, Claude Desktop, VS Code with Copilot and Cursor connect the same way and stay in sync with the same library. For everything else, every skill exports as an Agent Plugins 1.0 package for ChatGPT, Kiro and others, a frozen snapshot that we are careful to say leaves the update channel. The library is one place; the tools are many.

And a quieter sixth: the same skill, six times

When sharing is peer-to-peer, nothing stops three people building the same meeting-notes skill and sharing it with overlapping sets of colleagues. On shareskills an agent about to create a skill searches the library first, is refused if the name is taken, and is told when near-duplicates exist; a sync flags near-identical copies for an admin to tidy up. We wrote about why this matters more than it sounds in our post on skills sprawl.

When the native feature is the right call

• Your people work almost entirely in claude.ai or Cowork, and nobody runs skills from a terminal.
• You want to hand one colleague one skill, today, with zero setup. Nothing beats a button that is already there.
• You are on Enterprise and want access scoped to your directory groups. shareskills has teams and per-skill collaborator lists; it does not have groups.
• You are in a regulated configuration where skills default to off, and you want the vendor’s defaults to do that thinking for you.

In each of those cases, use it. It is also perfectly reasonable to use both: sharing for the quick hand-off, a library for the skills that have become load-bearing.

The layer above the tool

The bigger point is about where an organisation’s know-how should live. A skill is the most portable form that know-how has ever taken: a folder of markdown an agent can run. It would be a strange outcome if the answer to “where does our know-how live?” became “in one vendor’s Customize menu, owned by whoever typed it first, unreviewable, and unreadable to the people accountable for it”. Not because the vendor is wrong to offer sharing, but because the asset matters more than any one tool that runs it.

That is the layer we think an organisation needs to own: an organisational intelligence layer, above any single agent, where skills belong to the organisation, are improved under rules, carry their history, are visible to the people responsible, and run wherever the work happens. Anthropic making sharing native is a good day for that idea. It is also a good day to notice that sharing was never the hard part.