A Guide to AI Skill Sharing

Have you felt this pain?

Check any you've felt in the past month.

The teams we work with have gone from building their first Skills to managing libraries with hundreds, at the personal, team, and company level. The barrier to creation is extremely low, which means Skills spread faster than the systems around them. The pattern is familiar to anyone who's run a design system, an internal package registry, or an open-source project: capabilities accumulate, ownership blurs, quality drifts. The work is to put structure in place before chaos sets in.

In this guide we cover how to create high-quality Skills, establish ownership, decide where they live, and manage updates. This is written for operators leading a team that's building new Skills every week. You don't need to be technical to run it, and the setup guide is meant to be detailed enough for a step-by-step setup.

Best practices in Skill creation

Do the work first, then make it a Skill

The most consistent failure pattern: people build Skills before they fully understand and articulate the job-to-be-done. They write instructions for a workflow they haven't done manually, the Skill produces something plausible but wrong, and trust erodes.

Our strong recommendation: do the task manually first in either Cowork or Code and hone in on the output. Once you've nailed the quality and fidelity you're after, it's easy to save it as a Skill within the same chat session. This applies whether the Skill is:

• A capability: something Claude can't do well that you can.
• A workflow: chained steps with decision points.
• A preference: tone, voice, formatting.

The quality bar is different for each, but the rule is the same.

Make Skills self-contained

The biggest predictor of a Skill not surviving past one person: referencing files only that person has. A restaurant analogy brings it to life.

When you save a Skill, ask whether someone on a different laptop can use it without changing anything. If not, fold the missing context in. A Skill that depends on someone's local setup is fragile.

Keep the fast-moving stuff outside the Skill

Skills should be stable. If you're editing a Skill every week to add examples, update gold-standard outputs, or tweak reference content, that's a sign it's doing too much. The fix: move the fast-moving content into a separate file or folder the Skill references. The Skill stays stable; the external content updates.

Example: you have a creative-brief writing Skill and want Claude to learn from every gold-standard brief your team writes. Don't keep adding examples to the Skill itself. Point the Skill to a shared Drive folder where new briefs land.

Define "correct" before you ship

Anthropic's enterprise doc names five eval dimensions: triggering accuracy, isolation behavior, coexistence with other Skills, instruction following, and output quality. Even if you don't follow it exactly, the meta-point is essential: you need a defined quality bar to get consistency of output. What works in practice:

Evals deserve their own deep-dive, which we'll write separately. To start, a rough rubric and a list of good and bad examples for Claude will help you get more accurate and consistent outputs.

Ownership

Every Skill needs one person accountable for it.

One person should be clearly accountable for each Skill. There should not be a committee. The backups are for situations like people taking extended time off, and people leaving the company. Claude's native sharing only lets you set one owner today, but the GitHub setup below is exactly how you keep one clear owner and a safety net at the same time.

The single-owner model

The owner is responsible for three things:

The owner doesn't have to be the person who wrote the Skill or uses it most. The owner is the person on the hook when it breaks.

You name the backup in the Skill itself, and use GitHub to transfer ownership cleanly when it changes hands.

• OWNERS.md lives inside the Skill folder: a plain-language note listing primary and backup owner. Pure documentation, so anyone looking at the Skill knows who to bug when it breaks. GitHub does not read this file.
• CODEOWNERS lives at the root of the repo and maps each Skill folder to the same names. GitHub reads it automatically and requires those people to approve any change before it goes live. Note: CODEOWNERS follows a specific format and requires proper GitHub usernames, not plain English.

When the owner leaves, the transfer happens in GitHub: someone opens a pull request updating both files (backup becomes primary, a new backup is named). Once approved and merged, GitHub enforces the new ownership going forward. Until then, the departed person's name still gates every change, which is useful: it forces someone to notice and act.

Deciding when to deprecate

Most Skills will rot. The task changed, the tool changed, a better Skill replaced it, or nobody used it after the first month. That's normal. What gives a library bloat and confusion is leaving the unused ones in it.

Every library that grows past 30 Skills without an audit cadence develops the same pathologies: Skills nobody calls, broken references to files that moved or got renamed, duplicates that silently diverge. A quarterly review fixes most of this. Thirty minutes on the calendar. The owner of each Skill answers four questions:

• Did anyone use this Skill in the last quarter?
• Are any of the files or references inside it broken?
• Is another Skill doing the same job better?
• Should this Skill still exist?

Anything that fails the first three gets archived to a deprecated/ folder with a sunset date. Anthropic's guidance is simpler: "Deprecate Skills when evaluations consistently fail or the workflow is retired."

The system for managing Skills

At Glia, we believe Skills are the new code.

If that's right, a company wouldn't want to run on code that's a hodgepodge of files shared by different people. You'd put it in version control, and the same logic applies to Skills. Google Drive, Notion, and a shared chat workspace are not where serious Skill libraries live. Given the current limits of Claude's native sharing, the most viable option is a GitHub repo set up as a plugin marketplace and synced into Claude. It's not perfect for non-technical operators, but it covers the four things that matter (history, review, ownership, conflict resolution) and keeps your Skills portable.

Step 0: Lock down org-wide sharing in Claude

Before any GitHub setup, change one setting in your Claude admin panel. By default, Claude Enterprise lets any user share a Skill with the entire organization. That sounds collaborative but creates exactly the chaos this guide is meant to prevent. Go to Org Settings → Skills and disable broad org-wide sharing. Leave "share with selective members" enabled, so anyone can still share with specific teammates, but pushing a Skill org-wide should require an admin-in-the-loop process. Lowest-effort, highest-leverage change you can make today.

Why GitHub, specifically

GitHub gives you four things no other shared-storage system gives you in one place:

Drive folders, Notion, and Claude's native Skill sharing all lack at least one of these four primitives, which is why teams outgrow them quickly.

"But GitHub is for engineers"

That was true ten years ago. Today GitHub is a useful standard for any shared library that needs review, history, and ownership: open-source projects, internal docs, design systems, and increasingly AI Skills. A useful mental model: think of your GitHub Skill repo as an App Store for your team's Skills. Apple and Google both run app stores on top of technical infrastructure most users never see. The user experience is a clean catalog of installable apps; the engineering is hidden. Same here: GitHub is the infrastructure, and your team interacts with a folder of Skills, not with code.

Top 3 actions to take

If you have a team building Skills and no shared system yet.