Primer: a library for your team's agent skills

The description is the trigger

Somewhere in your team's agent setup there is probably a skill that has never once run, and the reason is a sentence. A skill runs because the agent read its one-line description and judged that it matched the request in front of it. The description isn't documentation for whoever browses the folder. It's the trigger. In our prototype's sample data, a skill described as “Audits expenditure reports for compliance” sat at zero fires for thirty days while people kept asking “Check my expenses.” Same intent, different words, so the skill never loaded.

The mechanism is 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, the wiring is made of sentences. A skill, as Anthropic's Agent Skills format (published October 2025) settled it, 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 reference documents, runnable scripts, and templates for the artifacts it produces. The agent scans the descriptions of the skills available to it and loads the one that fits the task. So a skill can be flawless inside and still unreachable, and the fix is an edit to one line.

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 above and the design of a skill 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. Primer is one of our design-sprint prototypes, built around that loop: screens and sample data you can click through, a prototype rather than a shipped product. First we show the day a skill outgrows its git repo, then the four jobs a library does, then the zero that makes the whole thing measurable.

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 internal for it to go. Public distribution has moved faster: registries and marketplaces for shared SKILL.md skills, such as Agensi and SkillsMP, appeared through late 2025 and 2026. Those catalogs distribute generic skills to strangers. The skills that encode your organization's own methods still live in repos, and nothing in that tooling tells you whether your agents load them.

The format itself is ready for the move. The core of a skill is prose, so a claims lead can read the severity rules and see whether they match how the team actually triages, and 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.

A library has four jobs, and the fourth is new

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 the prototype counts it in one currency: 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 terms: 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 rather than a measurement.

The zero is the fixable state

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. That is the whole intervention, and it's available to whoever owns the method, because rewriting one descriptive sentence takes judgment about the words your team really uses, and no engineering at all. The zero is where the design leans, because its meaning is unambiguous: the method exists, the work exists, and the words between them don't meet.

Build the library as an editorial system

Once agents do the work, the thing a person supervises is the method the agent loads and follows, and the authority to maintain a method belongs with whoever owns it: the claims lead maintains the severity rules, the marketer owns the voice check, neither one opening a repository. So build the library as an editorial system rather than an IDE: versions, sharing, a reading room where anyone can read what the agents follow, and method owners maintaining their own methods. We measured how much a written method changes 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 a hundred of them and non-engineers need to own theirs. A skills library is also 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.

Two cautions keep the metric honest. A fire count locates a failing description, but it doesn't write the better one; the rewrite still takes judgment about how your team actually asks. And a rising count is a signal to read rather than a score to maximize, because a skill that loads constantly may be worded too broadly and crowding out the ones that should win.

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 closing that gap is what this prototype was drawn for.