The best way to share AI skills across a company (it is not a wiki)

A shared skill can still be a bad one

If every skill helped, this post would be one paragraph long. They do not. SkillsBench is a research benchmark that runs the same expert tasks with and without curated skills. In its latest version, skills raised the average pass rate and made some tasks worse.

Those are lab tasks, not your work. I use them for the pattern. On average skills help, and on about one task in seven they hurt. Anthropic’s guide for administrators says the same in plain terms: skills can degrade an agent’s performance if they trigger wrongly, conflict with other skills or give poor instructions, so require evaluation before any production deployment (Skills for enterprise). A shared skill nobody tested is a shared guess.

Five ways, six needs

Here is the grid. A full circle means the pages I read describe the thing plainly. A half circle means they describe part of it, or describe a pattern you would have to build. An empty circle means I found nothing, which is not the same as saying it cannot be done.

1. Learning from use across the company. The only approach whose own pages promise a pass rate on your checks. Also the one with the least public proof, because it is ours.
2. A skills registry or repo. Port’s registry counts use and spend per skill. A bare Git repo has the best review and versioning I found and counts nothing.
3. The skills library inside your AI tool. Strong on review and access, and it counts how many people used a skill. It covers that vendor’s tool only.
4. A prompt library. The AWS pattern is thorough, but it is written for prompts inside software a team builds.
5. A wiki. Versions and views, and no way to tell a read from a result.

A wiki or shared doc

People start here because it is where they already write things down. I read Atlassian’s Confluence pages. Confluence makes a new version of a page every time it changes, lets you compare versions and restore an old one (page history, Data Center 11.0). It lets you set view and edit restrictions on a page, except on the free plan (page restrictions, Cloud).

Then there is measurement. Confluence Cloud shows how many people viewed a page. On Premium and Enterprise it adds who viewed it, whether they stayed 20 seconds or longer, and link clicks (content insights). That is the whole list. A page that was opened a lot is evidence that its title was good.

There is also a plainer problem. A skill is a folder with a SKILL.md file that the assistant loads when a task matches. A wiki page is not that, so someone copies it across by hand, and now there are two versions. I found no review step in the pages I read. I would use a wiki to explain why a process exists, and keep the skill somewhere an assistant can load it.

A prompt library

AWS’s Well-Architected guidance for generative AI has the most complete checklist I found. Its item GENREL04-BP01 says a prompt catalog should keep prompt versions, release a prompt to the live version once it passes testing thresholds, roll back when behavior goes wrong, keep test results for each model version, and track performance metrics and usage statistics. It lists approval workflows and audit trails under governance. Its companion item GENSEC04-BP01 adds identity-based permissions.

That is close to everything on my list. Two limits. It describes what a catalog should do, and it is not a product you switch on. And it is written for generative AI workloads, meaning software a team builds, down to tuning settings such as temperature. It says nothing about a finance analyst’s habit of asking the assistant to reconcile a ledger.

The employee-facing version is Microsoft’s Prompt Gallery in Copilot. Users save prompts and share them with a team. Admins can see the prompts a specific user saved, liked or shared, and the prompts shared with a team. The page describes no versions and no review. A like tells you someone enjoyed the prompt. If you keep retyping the same prompt, that is the moment to move to a skill, which is what the skills guide covers.

A skills repo or registry

This is where I would start. Claude Code’s docs say you can commit a skill to a repository to share it with everyone who works there, or distribute it through a plugin or managed settings to reach a whole team (Extend Claude with skills). Anthropic’s enterprise guide tells administrators to keep skills in Git as the single source of truth, for history, code review through pull requests and rollback. It says to pin production to a specific version, because if you leave the version out, a new version uploaded by anyone changes what production agents run. It says skill authors should not review their own skills.

It is also honest about what it leaves to you. The same guide asks you to require 3 to 5 test queries per skill, covering cases where it should trigger and where it should not. For monitoring, it says usage analytics are not currently available through the Skills API and tells you to log which skills are included in requests yourself. So Git gives you the best review and versioning on this page and hands you the measurement job.

A registry adds the measuring. Port’s skills registry is a central library where people publish and install skills through its UI, its MCP server or a command line. It ingests skills from Git, gives you one path to propose, review and publish, runs a certification review and flags duplicates. Its usage analytics bring in daily invocation counts from Cursor and Claude Enterprise, plus distinct users and optional spend from Claude Enterprise.

Port is the closest of the four documented approaches to answering whether a skill is worth keeping, and its guide is frank about the gap. A skill can pass every registry check, it says, and still not be worth running. Its answer is skill ROI: the cost of doing the task by hand divided by the cost of running the skill. You set the manual hours yourself, because Port says no integration can tell how long a task takes by hand. That measures cost. A skill can be cheap, used daily and wrong. Port’s registry is also written for engineering organizations, with squads, platform teams and CI pipelines in its examples.

The skills library inside your AI tool

For a company where most people live in one assistant, this is the least effort for the most machinery. On Claude Team and Enterprise plans, an owner can provision skills to everyone, and Enterprise plans can give a skill to one group by bundling it into a plugin. Users can submit their own. Under the “Requires review” setting an owner approves each submission and every later version, sees every file and what changed, and cannot approve their own. Reviewers get a “possible duplicate” hint. On Enterprise plans with scanning on, a version that fails the security scan cannot be approved.

The plugin pages add an Inventory that lists each item’s source, version, audience and how many people used it in the last 30 days. Claude Code’s plugin marketplaces do the same job for teams that live in a terminal: a catalog with discovery, version tracking and automatic updates, hosted in Git. A published skill stays in the library when its author leaves, which is a quiet point in its favor.

ChatGPT has its own version. OpenAI says workspace owners control who can share and install skills. That is the limit. Each vendor’s library covers its own tool, and Anthropic’s enterprise guide notes that custom skills uploaded through the API do not appear on claude.ai or in Claude Code, and the reverse. A company using two assistants has two libraries and two sets of counts. And a count of people who used a skill in 30 days says it was used. It does not say it was right.

Learning from use across the company

The fifth approach starts from a different place. Instead of asking people to publish their skills, you watch how work actually gets done, find the skills and habits that already exist, and check how they do. I believe this because of something I think is true of most companies and cannot prove: a few people have already worked out how to make AI useful in their own jobs, and what they know sits in personal folders and private chats. Sharing starts with finding it.

It can do three things the others cannot, on paper. It can see skills nobody published. It can see use across tools, where a vendor’s library sees only its own. And it can check results on your own past cases after release, with a pass rate per skill. This is the approach my company takes, so the honest account of what it does and does not do is in the Nolli note at the end. It costs more than a repo. Someone has to deploy it, your company has to set the policy for what it may learn from, and someone who knows the work has to say what a correct result looks like.

How a skill should travel

Here is the path I would want a skill to take, from one person’s habit to the whole company and back with evidence. Three of the six steps are well covered by the repo and library pages above: writing it down, review and publishing. The other three are finding the habit, testing and watching real work. Those are the ones the pages hand back to you or leave out.

Effort against what you learn

The last picture puts the six approaches on two lines: how much effort to set up and run, and how well you would learn which skills work. It is the grid squeezed into one view. The order of the dots matters more than the exact spots.

Pick this, skip that

• Pick a Git repo if

  you have engineers and want pull-request review and rollback today. Add your AI tool’s review step so non-engineers can publish too.

• Pick your AI tool’s library if

  most people work in one assistant and you want owner approval without new software. Choose “Requires review” on Claude, and check who may share and install in ChatGPT.

• Pick a registry like Port if

  you run an engineering platform team and have Claude Enterprise analytics, so use and spend per skill are available.

• Pick learning from use if

  you want to find the skills nobody published and see how they do on real work, and you can deploy software on company devices under your own policy.

• Use a prompt library if

  your team builds software that calls models and needs prompts versioned and tested. Skip it for everyday employee prompts.

• Skip the wiki for skills

  and use it for the why. A page view is not a result.

1. 01

   Put every skill that matters in one Git repo, each with an owner

   Name one person per skill who answers for it and updates it when the work changes.

   Do this todayAsk your team chat which skills people already use. Start with those.

2. 02

   Switch on review

   On Claude, set Publishing to “Requires review.” On ChatGPT, decide who may share and install. Nobody approves their own.

   Do this todayName the reviewer for each skill before you publish it.

3. 03

   Write 3 to 5 test queries per skill, from past cases

   Use cases with a known right answer. Include one where the skill should not fire. Run each with and without the skill.

   Do this todayTake the cases from last month’s real work, not from the author’s head.

4. 04

   Count use

   Use the vendor’s counts where they exist. Where they do not, log which skills are in each request, as Anthropic advises for the API.

   Do this todayWrite down who owns the number.

5. 05

   Re-test on a trigger, and retire what slips

   Re-run the tests when the model, the skill or the process changes. Anthropic says to deprecate skills whose evaluations consistently fail.

   Do this todayPut the model name in each test result.

That plan costs close to nothing and covers sharing, review and versions. The last three steps are real work, and they are where I think a tool should help. It also lines up with the job I wrote about in what a Head of AI Enablement does: measurement was the one duty all ten postings I read shared. For how we think about the job, see Nolli for AI enablement teams.

What I could not find

I found no page, for a wiki, a prompt library, a repo or a vendor library, that describes checking whether a shared skill’s output is right on real work after release. Port’s Claude usage data lists invocation counts, distinct users, share status, product surface and optional spend. I saw nothing about results. I found no customer result for learning from use from anyone, including us. I did not read a price for any product, so this is not a price comparison.

I read the Confluence version history in its Data Center documentation and the restrictions and view counts in its Cloud documentation. The SkillsBench paper changed between versions, so I used version 4 and noted the difference in my sources. Five approaches and a handful of vendors is a small sample, and docs say what a vendor wants you to believe. They are not what a product does on your Tuesday.

Sources

1. “Provision and manage skills for your organization.” Claude Help Center, Anthropic, accessed October 16, 2026.
2. “Manage plugins for your organization.” Claude Help Center, Anthropic, accessed October 16, 2026.
3. “Skills for enterprise.” Claude Docs, Anthropic, accessed October 16, 2026.
4. “Extend Claude with skills.” Claude Code Docs, Anthropic, accessed October 16, 2026.
5. “Create and distribute a plugin marketplace.” Claude Code Docs, Anthropic, accessed October 16, 2026.
6. “GENREL04-BP01 Implement a prompt catalog.” Generative AI Lens, AWS Well-Architected Framework, accessed October 16, 2026.
7. “GENSEC04-BP01 Implement a secure prompt catalog.” Generative AI Lens, AWS Well-Architected Framework, accessed October 16, 2026.
8. “Understand Prompt Gallery in Copilot.” Microsoft Learn, accessed October 16, 2026.
9. “Content insights and analytics.” Confluence Cloud, Atlassian Support, accessed October 16, 2026.
10. “Change who can find content and what they can do with it.” Confluence Cloud, Atlassian Support, accessed October 16, 2026.
11. “Page History and Page Comparison Views.” Confluence Data Center 11.0, Atlassian Documentation, accessed October 16, 2026.
12. “Skills registry.” Port documentation, accessed October 16, 2026.
13. “Skills usage analytics.” Port documentation, accessed October 16, 2026.
14. “Measure the ROI of skills in your org registry.” Port documentation, accessed October 16, 2026.
15. “Using skills.” OpenAI Academy, accessed October 16, 2026.
16. Xiangyi Li, Yimin Liu, Wenbo Chen, Bingran You and others. “SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks.” arXiv (2602.12670, version 4), read October 16, 2026.

Plain-text copy: /blog/best-way-to-share-ai-skills-across-a-company.md