How shareskills works

A skill is a set of written instructions that teaches an AI assistant how to do a specific job the way your team wants it done — processing an inbox, writing meeting minutes, reviewing support tickets, and so on.

A skill is a folder of files, not a single snippet. It is versioned as a whole, so you can edit, compare and roll back everything together.

Shareskills is your team's shared library of those skills. Think of it as a shared drive for your AI assistant's know-how: once someone writes a good skill, nobody else has to reinvent it.

• Browse and search the skills your teammates have written.
• Install a skill onto your own machine so your AI tools can use it.
• Share a skill you have built so the whole team benefits.
• Pull down the updated version whenever someone improves one.

Yes. Choose "Continue with Google" on the login or signup page. If your work email is managed by Google — a Google Workspace account — this is the quickest way in, and there is no password to choose or remember.

If you already have a shareskills account with that same email address, signing in with Google connects the two rather than creating a second account. Your existing skills, organisation and role are exactly as you left them, and your password keeps working too — connecting Google adds a way to sign in, it never takes one away.

We only connect the two when Google confirms it has verified that email address. That check is the reason the feature is safe: without it, anyone could claim an address that was not theirs and walk into someone else’s account. If Google has not verified the address, we stop and explain why rather than guessing.

• Signing up with Google skips the verification email entirely — Google has already confirmed the address.
• You pick which organisation to join, or create one, straight after your first Google sign-in.
• Nothing is shared back to Google, and shareskills never sees your Google password.

No — the public directory is open to everyone, signed in or not. You can browse and search every skill teams have chosen to publish publicly, and read the full detail page for each one.

You need an account to see your own team's library. Team and private skills are never shown publicly, and the screens that manage them (your dashboard, Connect, API tokens, approvals) all require signing in.

Any MCP-ready client. Shareskills runs an MCP server, so Claude Code, Claude Desktop, VS Code with GitHub Copilot, and Cursor all connect the same way — point the client at the endpoint with your token.

The Connect screen gives you a ready-made, copyable config for each of those clients once you are signed in.

Yes. Every skill can be downloaded as an Agent Plugins 1.0 package for other clients such as VS Code, Copilot, Cursor, ChatGPT and Kiro, so you can use it outside Claude Code too.

That export is a snapshot, frozen at the moment you download it — it leaves the shareskills update channel entirely. It never comes with an update gate and it never checks for updates, the way install_skill and check_skill_updates do for skills fetched here.

The exported plugin.json still carries an ai.shareskills extension block that records the source URL it came from, so you can always check back there for a newer version.

Add shareskills to your client, approve the sign-in prompt in your browser, and you are done. The Connect screen gives you a ready-made snippet for your client with the endpoint already filled in — you do not need to hand-write any configuration.

There are two ways to authenticate, and both are supported. Browser sign-in is the one to reach for: your client opens a browser, you approve once, and it stays connected. An API token is the alternative, for cases where nobody is there to click Approve.

If you would rather have your assistant do the setup, paste the message from the Connect screen into it instead — a brand-new session has never heard of shareskills, so asking it to "set up shareskills" cold tends to produce guesswork.

Help me set up the shareskills MCP server. Shareskills is my team's shared library of AI skills, hosted at https://shareskills.ai/mcp.

Show me the exact command to connect to it as an HTTP server at user scope, with an Authorization: Bearer header. Use the placeholder YOUR_TOKEN_HERE for the token. I already have my real token and I will paste it into the command myself in the terminal.

Important: never ask me to type or paste my token into this chat, and do not run the command for me. Just give me the command, tell me where to paste it (the terminal), and remind me to restart afterwards.

Your AI client sends you to shareskills in your browser. If you are already signed in, you go straight to an approval screen; if not, you sign in first and land there afterwards.

That screen names the client asking for access, the organisation the access applies to, and exactly what it will be able to do. Approving hands your client a short-lived key that it refreshes quietly in the background, so you should not have to do this again on that machine.

Two things worth knowing. Access is granted to one organisation at a time — if you belong to several, the approval screen asks which, and you can connect again to add another. And approving never grants more than you already have: your role in the team still decides what the client can do.

• Nothing is stored in your configuration files, so the snippet is safe to share with a teammate as-is.
• Nothing to rotate or remember, and nothing to leak into a screenshot or a chat transcript.
• Access follows your account: a role change, or deactivating an account, takes effect on the very next request.

Use browser sign-in unless something stops you. It is less to handle and less to leak.

Use an API token when no human is present to approve the connection — a CI job, a scheduled script, a server-side agent. That is not a limitation we chose: connecting an AI client always requires a person to consent, so automation genuinely needs a token instead.

One caution if you mix them up: configure one method per server entry, never both. If your client is set up with an authorization header and shareskills rejects that header, Claude Code reports the connection as failed rather than offering to sign you in — so a token that has expired looks like an outage instead of a login prompt. Remove the header to fall back to browser sign-in.

Sign in, click your name in the top right, and choose API tokens. Create one, then copy it somewhere safe — a password manager is ideal. The token is shown once, at creation, and is never retrievable afterwards; if you lose it, revoke it and create another.

Choose the scope you need: read tokens can list and install skills, write tokens can also author and update them. Every member of a team can create their own tokens.

Where your client supports it, point the configuration at an environment variable rather than pasting the token inline. That keeps the credential out of your shell history and out of any config file you might commit.

No. Treat your token exactly like a password.

Conversations with an AI assistant are typically saved to your computer in plain text, so a token pasted into a chat is no longer secret. That is why the setup flow gives you a command containing a placeholder, and you substitute the real token yourself in your terminal or config file.

If a token does end up in a chat, even by accident, revoke it on the API tokens screen and create a new one. Revoking takes effect immediately.

Browser sign-in sidesteps this entirely: there is no token to paste, so there is nothing to leak into a transcript. It is the safer default for exactly this reason.

If you connected through the browser, sign in again — in Claude Code that is `claude mcp login shareskills`. A connection can lapse if it went unused for a long time, or if someone revoked it.

If you connected with an API token, that almost always means the token is missing, expired or revoked. Create a fresh token, update your client configuration with it, and restart the client.

If the client connects but cannot see the skills you expect, check which team you are connected to — the answer to "Am I connected to shareskills?" names the team and your role in it. Skills live in one team at a time, so connecting to the wrong organisation shows you an unexpectedly empty library rather than an error.

It is the only piece you need to remember. Once installed, ask your assistant for "shareskills start", "sync my skills", "check for skill updates" or "publish this skill" and it works out what is needed — including walking you through fixing a broken connection.

To install it, ask your assistant to search shareskills for a skill called shareskills-start and install it.

Over time two copies of a skill drift apart: the one on your machine and the one in the team library. Maybe you tweaked yours; maybe a teammate improved theirs. Syncing brings them back in line, in both directions.

• Sends your improvements up — offers to share changes you have made.
• Brings team updates down — offers to update your copy when a teammate improves a skill you use.
• Publishes new skills you have built that the library does not have, checking first that a near-duplicate does not already exist.
• Suggests skills from the library that look relevant to what you are working on.
• Flags near-identical copies of the same skill so an admin can tidy them up.

That is a conflict, and nothing is guessed. You are shown both sets of changes side by side and you decide: keep yours, take theirs, combine them, or leave it for later.

No. A sync on its own changes nothing — it shows you what it found and asks about each item. If you say no, or say nothing, nothing happens.

• Your old copy is saved before any local update, so an update you change your mind about can be put back.
• Nothing is shared with the team until it has spelled out exactly what would be shared, what it will be called, and who will be able to see it.
• It never asks for your token. If anything ever does ask you to paste a token into a chat, stop — that is not how this works.

Because that skill was published by another organisation in the public directory, not by your own team. The first time anyone on your side installs a public skill like that, shareskills has no earlier version to compare it with, so it trusts that first version — trust on first use — and quietly remembers it as the version you approved.

After that, an ordinary update — a clearer instruction, a typo fix, a reworded example — installs the same way it always has. What stops and asks first is a material change: an update that meaningfully changes what the skill can actually do, such as adding a shell command, calling out to a network address it never used before, or reading files that hold credentials or tokens. When that happens, the new content is held back and your assistant is shown exactly what was flagged and why, instead of a vague warning.

Nothing installs from there until a person says yes. Your assistant should show you those findings and wait for your explicit approval before going any further — treat any shortcut around that as a red flag, not a convenience. And this whole process is specific to the public directory: skills published inside your own team are never gated this way, however often they change, because you already trust the people who wrote them.

• Applies only to the public directory — nothing inside your own team is ever gated.
• A held-back update always comes with a specific reason, never just "something changed."

About once a week is plenty, or whenever you have improved a skill and want the team to have it.

It does not run on its own. Each run leaves a date stamp your assistant reads at the start of a session, so if it has been more than a week you get a nudge to sync before relying on your installed skills.

Not from your end — treat publishing as permanent. Removing a published skill is an owner or admin job, so your assistant will always confirm with you before publishing anything.

Every person in a team holds exactly one of four roles. There is a full breakdown of each capability in the permissions table below.

• Owner — one per team. Everything an admin can do, plus team settings, and transferring ownership.
• Admin — manages people and skills: edits any skill, approves change requests, publishes, deletes, invites.
• Member — creates and edits their own skills; changes to other people’s skills go through review.
• Viewer — read-only. Can browse and install, but not create or suggest.

If you are a member, your edit becomes a change request rather than an immediate change — much like a suggestion in a shared document. An owner or admin reviews it and approves or rejects it.

Skills you created yourself are different: you can edit those directly, whatever your role. Whoever creates a skill keeps direct-edit rights over it.

Only its collaborators — the person who created it, plus anyone they explicitly share it with. Role does not override this: an admin who is not a collaborator cannot see a private skill.

Because of that, counts can differ between people. Your dashboard shows the number of skills you can actually see, and notes separately how many private skills exist that have not been shared with you.

Collaborators must also still be active members of the team, so removing or deactivating someone revokes their access straight away.

Private means collaborators only. Team means everyone in your team can see and install it. Public means it also appears in the open directory, where anyone on the internet can find and install it.

Making a skill public requires an owner or admin — members can create and edit their own skills, but the step that takes a skill outside the organisation is deliberately held back to admins.

Owners and admins both manage team members, from the menu on a person’s card on the Team screen. An admin can promote a member or viewer — including promoting them to admin.

Changing an existing admin’s role is owner-only, though. An admin cannot demote a peer admin or alter the owner. Ownership itself is never assigned from that menu; it moves only through an explicit transfer by the current owner.

Every role change is recorded in the team audit log.