How to roll out skills across your company

Most of what a company does in a week is the same work done again. Someone writes the Friday update to each customer, chases the proposal that went quiet, turns a call into action items, reviews a change against the same checklist as last time. How each of these gets done lives in someone's head, or in a doc nobody opens after onboarding.

Skills are how a lot of that work gets automated. A skill writes the job down so an AI can do it: the sources to read, the order, the format, who signs off. It sits on top of what a company already runs, its email, meetings, CRM, warehouse and internal tools, rather than replacing any of it.

Rolling skills out across a company takes two directions at once. Bottom up, people automate their own work. Top down, the company gives those skills a home, a standard and a scoreboard. Most companies we talk to have the first and are missing the second.

signup

01Bottom up: people automate their own function

By now a lot of people in every company are doing this already. Someone in finance has a skill that reconciles a report the way they like it. Someone in sales has one that drafts follow-ups. They built it for themselves, it works, and nobody else knows it exists.

That is the right instinct, and it is worth encouraging on purpose. Look at any role as the list of things that person does every week. Here are three of ours, written as the skills that do the first draft of each job:

A role is a collection of skills. A delivery lead's week is the Friday update, replies to customer questions, the follow-up after each call, turning calls into tracked work, and a change request when the scope moves. All five are skills. The lead still owns the relationship and decides what goes out, but the first draft of each job can be waiting before they start.

The people closest to the work know which of their jobs repeat, which is why bottom up works. Give them time and permission to automate their own function, then help them do it well. Two things do most of that. Workshops on what a skill is and how to write a good one, using real examples from your own company. And weekly office hours where people bring a skill they are stuck on, starting with the power users who have already built something and want to share it.

02Top down: the missing piece

Bottom up on its own stalls in a predictable way. Skills get shared ad hoc, even inside one team. A workflow one person built often does not run for a colleague. There is no central place to find what exists, no check before a skill spreads, and no view of what actually gets used. And people work in Claude, Copilot and Gemini side by side, so a skill written for one tool never reaches the people on another.

Top down fixes that with four things:

1. A central platform for skills. Every skill, organised by team, each with a page showing what it does, how to trigger it and who made it. Anyone can browse it, learn how to build a skill and submit their own.
2. Golden skills. A small set the company builds and vets itself, chosen because many people need them. Branding is usually the easiest first: everyone produces documents, and everyone wants them on brand. Pick the others by scoring each candidate on risk against reward: the workflow it replaces, who uses it and how often, the systems it touches, the time it saves, and what it must never decide on its own.
3. Central evals and a rubric. One standard every skill passes before it is published, and every new version passes again. More on this below, because it is the part most companies skip.
4. Usage. How often each skill runs, by team and by person. Without it you cannot tell a skill everyone relies on from one nobody has opened since it was written.

The golden skills matter more than their number suggests. They are the worked examples people copy when they write their own, so they set the bar for everything that comes after.

03Why not just use your model provider's marketplace

Every major provider now has some version of a skills library inside its enterprise product. Starting there is reasonable: it costs nothing to try, and a handful of shared skills is better than none. We think it is the wrong home in the long term, for three reasons.

1. You want to be provider agnostic. Your people already use more than one tool, and the best model for a job changes every few months. A skill locked inside one vendor's library has to be rebuilt for the next one. Your skills are how your company works, and that should not depend on which vendor you pay this year.
2. You want personalisation and deeper integration with your organisation. A marketplace knows a skill exists. Your own platform can know who joined on Monday, what their role is and which skills people in that role rely on, and recommend those first. It can tie a skill to the team that owns it and the person who maintains it.
3. You want to track usage and reward it. Adoption is a people problem as much as a tooling one. Seeing who builds skills and whose skills others use lets you recognise it, rank it and pay for it. A vendor dashboard, where one exists, gives you a count. It does not give you a way to change behaviour.

04Best practices: what a skill is

At a core level a skill is the simplest version of an agent. It is a playbook: a short description of when to use it, then a list of step by step instructions, in plain English. It can carry a script for the parts that have to be exact, but most are just text. The AI already knows how to write, research and use your tools. What it does not know is how you do things, and that is all a skill contains.

Every engagement we run gets an update on Friday: what we did last week, what we plan this week, and what we need from the customer. These are the steps of the skill that drafts it:

Read them the way a new hire would read a page of instructions from the person who did the job before them, because that is what they are. A few things the good ones have in common:

1. A description that says when, not just what. The AI picks a skill by reading its description against what you asked for. "Weekly update skill" is a label. "Draft the Friday weekly update for a customer engagement; use when asked for the weekly update, summary or report for a customer" is something a model can match.
2. Steps a smart intern could follow. If a capable new hire would have to ask what a step means, the AI will guess instead. Name the sources, the order, the format and who signs off.
3. Hard rules, written as rules. The few things that must never happen go in their own list. This one never sends anything to a customer; a person does.
4. The corrections, kept. Step seven was not there on day one. The first dry run wrote last week's plan up as though it had all happened, so the fix went into the file: every item carries its source and a tag. The correction now reaches everyone who runs it.

05Evals: making every version better

A skill is only as good as its last run, and it changes every time someone edits it. Evals are how you know an edit made it better instead of worse. This is the part most companies skip, and it is the reason their skills drift.

Every skill we publish carries a rubric: the goal of the skill, the dimensions it is graded on, and the failures that disqualify it outright. Our branding skill, for example, is graded on palette fidelity, logo and type, cover and contents, page layout and writing style.

To grade a version, the skill is run on a real sample and three AI judges score the output, one model each from OpenAI, Anthropic and Google. Each judge scores every dimension from 1 to 10. The lowest of the three scores counts, and every dimension has to reach 7. Using three providers matters: a model is a more lenient judge of output that reads like its own, and taking the lowest score means one generous judge cannot carry a weak skill through.

Two more rules make it a ratchet. Before the eval, an audit reads the instructions themselves for safety, for whether the steps on the page match what the skill really does, and for whether it duplicates one we already have. And an edit to an existing skill cannot drop any dimension's average by more than a point against the version it replaces, so a skill can only move forward.

The author sees every score and the reason for it. When our branding skill was first submitted, it scored 2s and 4s across the board. By its third try it scored between 7 and 9 on every dimension, and the rubric is what told the author where to look each time.

06Integrating with the marketplaces

Your skills should live in one place you own: a git repository. When a skill merges there, it publishes to each tool from there. Nobody copies files into five admin consoles by hand, and the version in every tool is the version that passed the eval.

Ours reach Claude Code and Codex, which both install skills straight from the repository, so a skill merged on Tuesday is on everyone's machine by Wednesday. Where a tool has no way to sync from a repository yet, the publish step produces the package its admin console expects.

Usage is the harder part. Instead of relying on each marketplace's metrics, install a hook that fires when a skill runs and reports it to your own platform. That is the only way to get one view across several providers. Ours is a small hook in Claude Code that records every teiō skill run. In a chat product with no hooks, a skill's first step can report the run itself, where the tool lets skills make network calls.

Where each provider stands, as of October 2026:

• Claude. Team and Enterprise owners upload a skill and it reaches everyone in the organisation, switched on by default. Claude Code can also install skills from a git repository. Enterprise's analytics report skill usage; that is the plan you need to see it from Anthropic's side.
• ChatGPT. Skills are on Business, Enterprise, Healthcare and Edu. Admins can upload skills to the workspace or let members publish to it, and uploads are scanned first. On Enterprise and Edu the admin skills page shows users and invocations per skill over 30 days.
• Gemini. In Gemini Enterprise people create skills in the app, and admins switch skills on and can require approval before a shared skill reaches anyone else. Google's documentation describes no usage reporting per skill.
• Microsoft Copilot. Organisation skills work in PowerPoint today. Admins upload a skill package in the Microsoft 365 admin center and assign it to everyone or to groups. The admin view shows each skill's version and deployment status, not its usage.

Four tools, four admin models, and usage visible in two of them only on their top plans. That is the practical case for a platform of your own.

07How teiō uses skills

We run all of this on our own platform. We have 19 skills live across seven categories, written by six people: our chief of staff, our data lead, a senior data engineer, two agentic software leads and me. Our platform runs some of them itself: release notes are written by the release note skill every time a change ships, and the audits that review every feature and bug fix are skills too.

081. Discovery

Our skills page works like an app store: search, a section per category, and a page for every skill with its steps in plain English, the phrases that trigger it, ratings and comments. The steps shown are the skill's own, written by its creator and checked against the file before it merges, so what you read is what runs.

The For you row at the top is how a new joiner finds their first skills. A model picks up to four for each person from their job title, what they have already run, and each skill's usage and rating. On day one there is no usage, so the title does the work: a salesperson sees the proposal and follow-up skills, an engineer sees the review ones. The skills themselves are already on their machine from setup. Type /teio in Claude Code and every company skill is there, with its description a hover away:

092. Submissions

Anyone can submit a skill, and one that passes its checks merges without a person reviewing it. A skill goes through five steps: submit, audit, a sample of real output, the eval, and merge. Any failed step sends it back with the reason posted on the submission, and a push starts it again from the audit. Over the last 30 days, twelve skills went live, with a median of 15 hours from submission to live. Most of that time was with the author, fixing what the audit or the eval found.

When someone edits a skill they did not create, the creator decides whether the edit goes in. If the creator does not answer within a week, an admin decides.

103. Gamification

Every skill page shows a face and a name, and a Top creators page ranks the people who made them by how much others use their skills and the points they have earned. People write better instructions when their name is on them, and they keep them current when a colleague leaves a comment or a low rating.

The points are real. A merged skill earns its creator between half a story point and two, set by the audit on its impact, and then a quarter of a point for each day a colleague uses it. Story points are the same unit we credit any other work in, so they flow into incentive pay the way delivery work does. Using skills counts too: trying new skills and using some regularly adds a small, capped bonus to each person's engagement score. Every month a Skills champion goes on our Wall of Fame, scored on how often their skills ran plus ten points for every skill of theirs that merged. September's was Prince, one of our agentic software leads.

Usage is still early. Over the last 30 days skills ran about 300 times, most of them the platform writing release notes on its own. The proposal skill was run by three different people. The count is how we know where we are, and it is what the points and the leaderboard are built on.

11Build your own

You can use this to build your own skills platform and roll it out across your company. In order:

1. Pick one golden skill everyone needs, usually branding, and build it properly, rubric included.
2. Put it in a repository you own and publish it to the tools your people use.
3. Install a usage hook from the first day, before you need the number.
4. Run a workshop and start weekly office hours, with your power users first.
5. Stand up the platform: discovery, the eval gate in front of every submission, and a leaderboard.
6. Recommend skills to new joiners by role, and reward the people whose skills others use.

It gets easier once the first one is in use.

cta

If you want to set this up in your own company, reach out.

Tarush