Primer: a library for your team's agent skills

The day a skill needs to leave the repo

Your team runs agents, and somewhere along the way it started writing skills. An engineer wrote one that teaches the agent to sort inbound claims mail by severity. Another reviews campaign copy against the voice guide. They live in a git repository next to the code, which felt natural at the time: engineers wrote them, agents read them, and for a while nobody else needed to care.

Then the person who owns the claims process asks a reasonable question. Can I see what the agent is following? The severity rules changed last month; can I update them? The honest answer is awkward. The procedure that runs part of their job sits in a repository they have never opened, in a review process built for code, editable only by the people who write it. The skill needs to leave the repo, and there is nowhere for it to go.

Primer is one of our sprint prototypes, about exactly that next step: a library where a team defines, updates, shares, and watches its skills. What follows is a walkthrough of the design and the thinking behind it. It's an exploration, honestly labeled: screens and sample data, a prototype rather than a shipped product.

What a skill is now

A skill, as the standard has settled, is a folder with a SKILL.md file at the top: plain-language instructions for how a piece of work should be done, packaged with whatever the job needs. That can include reference documents, snippets of code the agent can run, and templates for the artifacts it produces. Anthropic published the format (see their introduction to Agent Skills), and it has since spread well past one vendor's harness. The important property is right there in the design: the core of a skill is prose. A person who has never written code can read one, and with a decent editor, write one.

That property is what moves skills out of the engineering department. A claims lead can read the severity rules and see whether they match how the team actually triages. A marketer can see exactly what the voice check enforces. The format was built so agents can follow a method reliably. It also happens to be the first automation format the whole organization can read, and that second property is the one this prototype takes seriously.

Company assets, filed under engineering

Skills are the organization's methods, codified. That makes them assets with a lifecycle, and today the lifecycle runs entirely through engineering: a skill gets created in a branch, reviewed in a pull request, updated when an engineer gets to it, and shared by being in whatever repo the agents happen to read. With a dozen engineer-authored skills, that works. It stops working the day people outside engineering need to author and maintain the methods for their own work.

The management problem has four parts, and the prototype gives each one a surface. Defining: authoring a skill with enough structure that it's complete, with its instructions, references, and artifacts in one place. Updating: versions and review, so a method can change without a pull request. Sharing: which teams and which agents get which skills, including bundles that ship together as plugins. And watching: whether the skills are actually being used. The first three are familiar library problems. The fourth is the one agentic software adds, and it deserves its own section.

Watching what actually gets used

The prototype counts one concrete event and builds the screen around it: a fire, one instance of an agent loading a skill to do a piece of work. Every skill in the library table carries its fires for the week, and the tiles at the top state the library's condition in the same currency: how many skills exist, how many ship in plugins, how many fired this week, and how many have never fired at all. The walkthrough runs on sample data (a busiest skill at 41 fires in a week, a library total of 100), so read those numbers as an illustration of the mechanism. What's being counted is a plain tally of loads, and the tally is the observability.

The tally earns its place with the zero. A skill that shows zero fires in thirty days has a specific, fixable problem: no request has ever matched its description. The prototype flags one such skill in a corner card and diagnoses it in a sentence anyone can act on.

“Audits expenditure reports for compliance” is what the skill says. “Check my expenses” is what people ask. Same intent, zero fires.

The card offers a single action: rewrite the trigger. Two cautions keep the metric honest. A fire count locates a failing description, but it doesn't write the better one, and the rewrite still takes judgment about the words your team really uses. And a rising count is a signal to read rather than a score to maximize: a skill that loads constantly may be worded too broadly and crowding out the ones that should win. The design leans on the zero, where the meaning is unambiguous.

The description is the trigger

The reason a zero is even possible is worth internalizing, because it's where agentic software departs from the software most teams have shipped before. In a conventional app, a feature runs because a user clicked the button wired to it. In agentic software, a skill runs because the agent read its description and judged that it fit the request in front of it. The description isn't documentation for whoever browses the folder. It's the trigger.

One request through the trigger loop. The match against the description decides everything downstream, which is why a zero in the fires column points at the wording.

Follow one request through the loop and the design of the library falls out of it. The words a person uses are matched against the words the author wrote. A match fires the skill; a miss produces silence, with no error and no trace. A skill can therefore be flawless inside and still unreachable, and the fix is an edit to one sentence. That is what the fires column is measuring: whether the words on the skill meet the words people use.

Start with an inventory

Two pointers before the practical step. We measured how much skills change what an agent can do unsupervised in Why Agents Need Skills; this prototype is about the day after that argument lands, when a team has thirty of them and non-engineers need to own theirs. And a skills library is the kind of tool we'd build into a customer's own stack under the bespoke SaaS model, fitted to how that organization already names, shares, and governs its work.

The Monday step costs about an hour: inventory the skills your team already has. List each one, where it lives, who can read it, who can edit it, and when an agent last loaded it. The first four columns tell you whether your methods are stuck in engineering. The last column is the one most teams can't fill in today, and that gap is what this prototype was drawn to close.