You built the thing that finally worked. The workflow that gets the ACCOUNT_USAGE query right. The one that formats the weekly recap the way your director likes it. The one that finally got the dbt model to compile, including the edge case you hit at 11pm on a Tuesday and never want to debug again.

Then a coworker asks for it, and you realize you have no good way to hand it over.

So you get resourceful. A shared Git repo of skill folders. A Drive folder. A Slack message with the file attached. It works for about three weeks. Then the repo drifts from what people actually have installed, links rot, nobody can tell which copy is current, and a week later a different team builds the same thing from scratch.

And believe it or not, this is the most common situation for people creating skills. A developer on Reddit describing their own company put it plainly: "we are somehow wasting time reinventing the same agent every single day, and even worse we are not sharing the improvements."[1] Another, on managing skills across machines: "Some versions are starting to drift apart and get out of sync."[2]

Although the first talks about agents, it directly exposes the problem. Even with something as useful as skills, without proper distribution and discovery, the efficiency and effectiveness is nullified.

A skill is a packaged workflow you hand to an agent: the instructions, the order of operations, the tables and roles involved, and the context it needs to not guess. It's a folder with a SKILL.md file in it, sometimes with reference files alongside. Basically, just text.

A plugin is a bundle. Where a skill is one workflow, a plugin packages several things together and installs them as a unit: skills, hooks, agent definitions, and MCP server configs (MCP being the protocol agents use to talk to external tools). If a skill is a recipe, a plugin is the box the recipe came in, along with the pan.

The fact that both are files is what makes them easy to share badly. Anything you can attach to a Slack message feels solved. You send the file, the other person has the file, done.

This distinction took me a while to fully understand.

Distribution is getting the skills onto someone's machine. Git solves this. A repo, a git pull, done. Teams have been doing versioned distribution of text files for twenty years and the tooling is excellent.

Discovery is someone finding out the skill exists at the moment they need it. Git doesn't address this.

One user, writing about rolling out shared skills at his company via a private GitHub repo configured as a plugin marketplace, landed on exactly this after getting the whole thing working: "Distribution is solved, but discovery isn't." [3]

Nobody searches for a skill they don't know exists. Your teammate doesn't think "I bet Sam wrote something for this." They think "I need to pull cost data," and then they either write it themselves or retype the prompt. The skill sitting in the repo they cloned six weeks ago isn't part of that thought. It may as well not exist.

This causes an expensive byproduct: the skill getting rebuilt. The second version costs another afternoon, misses the edge cases the first one already solved, and now two versions drift while both claim to be how your team does this. You paid twice for one workflow and ended up with a worse one.

There's a second thing git may not provide: trust. A folder of eleven skills with no signal about which ones are any good means every user guesses. A wrong guess isn't a null result, because the skill is instructions for an agent. A wrong guess means an agent confidently running the wrong logic against the wrong tables, and being persuasive about it.

I went looking for how people are solving this in the wild, expecting to find one dominant pattern. There are at least five, and the most sophisticated one hits the same wall as the simplest.

A shared repo of skill folders. One repo, everyone clones, updates land via PR. Free, version-controlled, reviewable. It's also the pattern that produces the drift complaints above, because there's nothing forcing anyone to pull.

Project-level skills committed into each repo. Put them in the repo they apply to and everyone gets them on clone, no extra step. Clean, and it stops at the repo boundary. Cross-project skills get copied into every repo that needs them, which is where the "manually copying the skills folders from project to project" complaint comes from.

A central skills repo pulled in by reference. One clone, pointed at by every project, git pull to update. Solves the duplication. Still nothing pulls for you.

A private repo configured as a plugin marketplace. This is the most sophisticated option and it earns it: real versioning, selective install, an update command. It's also where the previously mentioned user hit the wall. There's no auto-install. The agent can tell a user a plugin is missing. It can't go get it.

A dotfiles repo with an install script, a lockfile, and a changelog. One practitioner's setup, and it's good engineering. It's also a small internal product that someone now owns.

Every one of these solves distribution well and none of them solve discovery, because discovery needs an index the agent can search at the moment of the task. A git repo isn't queryable that way.

I had eleven skills on my laptop and the same problem everyone above has. What I used was Skills & Plugins Sharing in Snowflake CoCo (currently in public preview and available to all accounts) which moves skills out of the filesystem and into the database. Here's how that went, including the parts that surprised me.

Publishing took one command and two questions. I ran /share-skill-and-plugin, and CoCo asked which role to share with (defaulting to PUBLIC) and whether to make it discoverable (defaulting to yes). Then it handed me a link.

I nearly clicked through those two questions without reading them, which would've been a mistake. Access is which roles can install and use the thing, enforced by the same role-based permissions as any other object in the account. Discoverability is whether it shows up when someone browses. Separate axes, so I could publish the half-finished one link-only and unlisted, the same idea as an unlisted video, and publish the good one to PUBLIC where people can find it by browsing.

Then I sent the link to a coworker. She pasted it into CoCo and it installed straight into her session, without me explaining where the skills folder lives on her machine.

The drift problem I'd been burned by has an answer too, which I went looking for specifically because I didn't believe it would be there: cortex skill update <skill-uri> pulls the current version of one skill, and cortex plugin update with no argument updates every installed plugin. That's the "get out of sync" complaint answered directly, and it's the piece I'd steal conceptually even if you stay on git.

But what I actually wanted was discovery. How can I find a skill that I don't even know exists? That happened a few hours into testing. /find-skill-and-plugin searches the catalog against whatever you're currently working on and surfaces matches in context, so a teammate got handed my cost-analysis skill by the agent while asking about spend. She hadn't known it existed. That's the only mechanism in any of the options above that reaches someone mid-task.

There's also a browsable list in Snowsight, the Snowflake web console, under Catalog > Skills & Plugins (inside Horizon Catalog, which is where Snowflake keeps its data governance and discovery surfaces). It shows install and usage counts over the last 28 days, aggregated across clients. Rough numbers, but enough to tell which skills people keep using versus which ones they installed once. Also allows me to search for skills I need as well, which has been my main way of finding skills besides asking CoCo to find them for me.

The trust problem needed an admin, not me. Someone holding ACCOUNTADMIN, the top-level administrative role in a Snowflake account, can mark a skill as certified. What I didn't expect: certification is pinned to a specific version, not to the skill's name. So an admin endorses the version they actually read, and a later upload doesn't silently inherit that badge. A link with no version in it resolves to the latest certified version if one exists, and the latest available version otherwise. Which means the link I dropped in Slack two months ago now hands people the reviewed version, without me editing the message.

To get technical behind the implementation, each shared skill is stored as a Cortex Extension, a first-class Snowflake object like a table or a view, and it lands in your personal database by default. When an admin certifies it, Snowflake copies that object into a separate governed database rather than modifying yours in place. My original stayed where it was. I thought the duplicate was a bug for about ten minutes. It isn't: centrally governing an object that lives inside one person's private database is the wrong way to ensure governance, so the governed copy is a different object. Because these are ordinary Snowflake objects, you can also drive all of this in SQL instead of through CoCo, which is how I'd wire it into a setup script.

None of the above helps with a blank file, however. I didn't hand-write most of those eleven skills. I ran /skill-development, described the workflow, and in a couple of cases pointed it at the session where I'd already done the work manually. A skill that writes skills.

This was great because I was able to use CoCo to help me write the CoCo skills and I was able to be as involved or hands-off as I wanted depending on the specificity that the skill required (governance, accuracy, table names, etc).

This bought me discovery and a trust signal. It cost portability, and that's a real cost rather than a rounding error. When this exact question came up in a thread, one practitioner's advice was blunt: "dont Vendor Lock into a specific Harness' package registry system."[4] That applies here. My skills are now in an account, and these are the documented limits:

And certification needs ACCOUNTADMIN, so if that role is hard to get time from at your company, expect the catalog to fill up faster than the trust signal arrives.

There are many solutions and a lot of them are viable, though not optimal. You should choose the one that best balances your needs so that you can best utilize skills in your organization.

Review the docs for more: https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-skill-plugin-sharing

[1]: u/Scary_Mad_Scientist, "How are you sharing skills within your organization?", r/ClaudeAI. https://www.reddit.com/r/ClaudeAI/comments/1rjwxpg/how_are_you_sharing_skills_within_your/

[2]: u/Unlucky_Evening_9982, "How do you manage and sync Claude Code skills across projects and machines?", r/ClaudeCode. https://www.reddit.com/r/ClaudeCode/comments/1ubdz8g/how_do_you_manage_and_sync_claude_code_skills/

[3]: Will Jackson, "Distributing Claude Code skills across a team," LinkedIn. https://www.linkedin.com/pulse/distributing-claude-code-skills-across-team-will-jackson-1gx6e

[4]: Comment on u/jakub_curik, "How do you share Claude Code skills, plugins, commands, hooks, and MCP servers across a team?", r/ClaudeCode. https://www.reddit.com/r/ClaudeCode/comments/1v47ald/how_do_you_share_claude_code_skills_plugins/