You can now delete skills, and here is exactly what that does

A confession from our own library: a while back, one of our team created a skill by accident. Not a bad skill, just one that was never meant to exist. And then we discovered something embarrassing about our own product: there was no way to actually remove it. You could empty a skill out, replacing its content with a stub, but the entry itself lived on forever, still showing up in the library, in search results, and in install flows. We had built a system where mistakes were immortal.

That is fixed. As of this week, skills on shareskills can be deleted outright, from the website and from any connected agent. This post covers who can do it, what it does, and, just as importantly, what it deliberately does not do.

Who can delete a skill

Deletion follows the same trust tiers as every other write on shareskills. Owners and admins can delete any skill in their team. A member can delete skills they created themselves, which neatly covers the created-by-accident case without a support ticket: the person who made the mistake can clean it up. Viewers cannot delete anything, and a member who wants someone else’s skill removed simply asks an owner or admin. We considered a formal deletion-request queue, mirroring the change-request flow that member edits already use, and decided against it for now: a removal is usually a one-line conversation, not a review workflow.

What deleting actually does

• The skill disappears from your team library, from search, and, if it was public, from the cross-team directory. For everyone, immediately.
• The skill’s name is freed straight away, so a replacement can take the slug without workarounds.
• Collaborators and team admins get a notification naming who deleted what.
• The deletion is written to the audit trail: who, what, when, and an optional reason.

On the website, deletion sits on the skill’s edit page behind a type-the-name confirmation. From an agent, there is a new `delete_skill` tool on the MCP server, gated by exactly the same rules, so asking your agent to remove a skill works if and only if you could have done it yourself.

What it deliberately leaves alone

Here is the design decision we want to be loud about. When a teammate installs a skill, they get a real copy in their own workspace, on their own machine. Deleting the skill from the shared library does not reach into anyone’s computer and remove that copy. It cannot, and we think it should not: a server that can delete files on your laptop is a much scarier product than a skill library.

Instead, the update channel carries the news. Agents are already told to check a skill for updates before relying on it. After a deletion, that check returns a clear answer: this skill was removed by its team, tell the person you are working with, and treat the local copy as deprecated, removing it only with their consent. No silent disappearance, and no silent local file deletion either. The person stays in the loop on both ends.

One nuance we sweated over: who gets told a skill was deleted, versus who is told it simply does not exist? If you could see the skill before, or you had installed it from the public directory, you get the honest removal notice. Anyone else gets a plain not-found, the same answer they would have gotten all along. Deletion should not become a way to probe what private skills another team used to have.

There is no undo button

Treat deletion as permanent. Under the hood we keep the record rather than destroying it, because we have learned that the ability to answer “what happened here?” is worth more than the disk space, and it leaves the door open for a proper restore feature later. But today nothing exposes an undelete, so the type-the-name confirmation is there for a reason.

The full permission table, including deletion, lives on our FAQ page. And if your library has its own immortal mistake sitting in the list, it can finally go.