Skills are how your company works, written down for agents

Written by Knut Melvær

If you scrolled a tech feed lately, you have probably seen folks market their SKILL.md files as the canonical ones to install in order to get agents to output better stuff. Almost all of it skews toward engineering. But what about the rest of us?

Turns out skills are just content on how business operations work. And if you're describing business operations for agents to act on, that is stuff that needs governance and distribution. Sure, you can stick it in a private GitHub repo and call it a day (in fact, for the time being, you kind of have to). But you also want to make it available for the people who shouldn't need a GitHub account to collaborate on, contribute to, review, and control the skills a business runs on.

This post is how we built that at Sanity, and how you can stand up the same thing: somewhere for non-engineers to author skills, a pipeline that gets them into everyone's Claude minutes after publish, and the steps to add the same repo to the other agents your team uses, Codex and Cursor included.

So what is a "skill," really?

Strip it down and a skill is a folder with a markdown file and a little metadata, loaded into an agent's context on demand. The format is an open spec Anthropic published in 2025, and it caught on fast with developers. Vercel grabbed the npm package skills and launched skills.sh as the main registry. The popular entries are what you'd expect from that crowd: frontend design, React best practices, and working with Azure (yup!).

But the format is the boring part. A skill typically describes some kind of workflow, process, or standard operating procedure. How we run a product launch. How we turn one announcement into eight platform-specific posts. Which table in our data warehouse actually means what, and which one will quietly mislead you if you trust the column name. The content is the stuff that usually lives in a senior person's head, or in a doc nobody has opened since they onboarded.

Once you see skills this way, the engineering framing starts to feel small. A skill isn't just a trick for making an agent write better React code. It's a way to write down how your company actually operates, in a form an agent can pick up and act on. And the moment you treat company knowledge as something you publish to agents, you inherit every problem that comes with publishing company knowledge. Someone has to own it. Someone has to keep it up to date. And you need a way to get it from the person who knows the thing to the agent that needs it.

In my opinion, GitHub isn’t that place.

The people who hold the operational knowledge are mostly not the people who are comfortable committing markdown to a private repo and opening a pull request. Skills can be a powerful and simple way for a company to automate more with AI, but if you want adoption, you also want to lower the threshold for adding and using skills as much as possible.

Making skills management available outside of GitHub

We built a Skills Studio on Sanity. It has a rather simple content model: a skill document with a body, an owner, a visibility setting, and a set of categories, plus skillReference documents that hold the deeper content a skill loads only when it needs it. You log in to add and edit skills, either directly or using AI via the Sanity MCP or the built-in Content Agent. You write, you set who owns it, you publish. No branch, no PR, no YAML. At least not for the user in the studio.

But how do we get from the Studio and the dataset that these skills are stored in, to everyone's Claude, Cursor, and Codex? Different agent harnesses each handle skill intake differently, so we're going to focus on how this works for Claude in this blog post.

How we automate skills distribution

When someone publishes an update to a skill it triggers a Sanity Function that commits the updated markdown to a GitHub repo. From there, the Claude org plugin picks it up, and within a few minutes the new version is live in the Claude Chat and Cowork of everyone at the company. Nobody re-installs anything. You're mid-task, and the company standard operating procedures under your agent quietly got better while you weren't looking.

A Sanity Function is just code that runs in response to a content change, configured in a blueprint. Ours listens for changes to skill documents and pushes them to Git. The GROQ filter and projection define what needs to change for the GitHub sync to trigger. We have additional metadata in the Studio that doesn't need to be synced down, so the filter watches only the fields that make up the skill itself (the name, description, content, and references). Editing a skill's owner or category doesn't fire a commit.