The uncomfortable number
Two months ago I counted the skills in our repo: 41. Then I checked how many people were actually using them. One. Me.
They were not bad - some of them saved me hours. But a skill library that one person built and one person invokes is not infrastructure. It is a hobby.
The previous two parts of this series were about building: how to package knowledge into a skill, and how to let an agent act on its own. This part is about the harder question: how do you get the other 39 people to trust what you built and use it as part of their work? That is not distribution work that starts after development. It is part of the product.
A note on the data: the numbers and scenarios in this post illustrate patterns we actually saw across 12 weeks of internal use. They are not a precise measurement of a single organisation, and names and details have been changed.
The four tests of a team skill
For a skill to go from personal tool to team infrastructure, it has to pass four tests:
- Discovery. Does it show up at the moment it is needed?
- Fit. Does it match the way the team actually works?
- Trust. Can you predict its output and the limits of what it will do?
- Ownership. Who maintains it, measures it, and retires it?
The rest of the post walks through those tests one at a time, including what each one looks like when it fails.
Discovery and fit: why good skills die
Most skills do not die because of code quality. They die before anyone gets far enough to judge the code at all.
Discovery failure. Nobody knows they exist, or the description does not make the agent pick them at the right moment. A skill that does not surface when it is needed is a skill that does not exist.
Trust failure. Someone tried it once and got an inaccurate result. With engineers, one bad first attempt outweighs ten promises that it "usually works".
Fit failure. The skill was built around the author's workflow - their names, their task structure, their assumptions. For the rest of the team it might be good, but it does not fit the work they actually do.
None of these three show up while you are building. They only show up when the tool meets people who did not build it. Here is what that looked like for us:
Adoption: three mechanisms, not three alternatives
The mistake we made at the start was treating the champion, the paved road and the mandate as competing options. They are not. They operate at different stages of the same process.
A champion starts the movement. One engineer believes in the tool, uses it in front of others, and produces the first wins. It is the best way there is to build trust, but it is bounded by their social network. For us it stalled at 14 people and did not move for two months.
A paved road makes the behaviour easy. The skill appears inside the place where the work is already happening: in the ticket template, in the PR, in the CLI. Nobody has to remember its name or look up how to invoke it.
A mandate defines the places where consistency is a requirement, not a preference - migrations, production deploys, security operations. Too broad a mandate produces compliance theatre; a narrow one turns an important standard into the default.
What does paving a road actually mean? Before paving, the engineer has to remember a skill exists, find its name, supply the context, and decide when to trust the result. After paving, opening a migration ticket already supplies the schema, adds the context, and offers the right skill. A few examples:
- The migration review skill fires from inside the relevant PR.
- The sprint summary skill automatically receives the sprint's tickets.
- The deploy skill loads from inside the command already used to ship.
If someone has to remember the skill exists, search for it, and re-explain the task to it, you have not paved a road. You built a sign.
The illustration below is based on the patterns we saw over those 12 weeks. It is not a forecasting model. It is a way to compare how each mechanism tends to behave over time:
The sequence that worked for us was not picking one curve: the champion proved the value, the paved road removed the friction, and a narrow mandate closed the places where consistency was non-negotiable.
Trust: guardrails that do not rely on the author being careful
When one person runs an agent, they can be their own guardrail. They see every action and notice anomalies. On a team of 40 that stops being a strategy: there are 40 different levels of experience and caution, and eventually someone will run with the most open permissions the system allows.
For us it looked like this: a testing agent got into a loop and ran for an entire weekend against a paid API. We only found out through an unusual invoice. That was not one user's mistake, it was a design mistake: we built a path where an unbounded run could continue with no alert and no ceiling. A daily spend cap would have stopped it within hours.
So the caution has to live in the tool, not in the user:
- Human approval before irreversible actions.
- Usage and cost ceilings.
- Task-scoped permissions, and a small blast radius by default.
Every guardrail adds friction, and friction hurts adoption, so the goal is not to switch on every possible protection. It is to define the minimum an entire team can rely on. Our rule: an irreversible action always requires approval; the remaining limits get tuned to the risk and the workflow. A guardrail everyone routes around is worse than no guardrail - it does not protect anything, and it teaches people that the rules are a suggestion.
Ownership: who handles it when something breaks
A skill in a shared repo is production code. It has users, it has dependencies, and it fails at an inconvenient time. Walk the path below - how it ends was decided by choices made long before the incident:
The model we settled on: every skill in the shared repo has an owning team and a person who leads maintenance. When that person changes roles, ownership stays with the team and a new maintainer is named. This sits at the top of every skill:
owner_team: platform # the team that inherits maintainer: dana.k # the person who leads today backup: platform-oncall # who acts when both are away review: 2026-11-01 # next scheduled look
Before merging, a new skill is tested against a few representative scenarios that the author did not choose, including at least one edge case. The review asks: does the description get it selected at the right moment, and does it avoid being selected at the wrong one; is the output consistent; which permissions and tools does it get; does it duplicate an existing capability; and who owns it after the merge.
And retirement: low usage triggers a review, not automatic archiving. A skill invoked once a quarter during a security incident can be critical; a skill invoked hundreds of times that generates unnecessary rework may be the better retirement candidate. If there is no usage, no critical scenario, and no owner willing to justify continued maintenance, the skill gets archived. Not deleted, but not left in everyone's way either. A repo full of dead tools destroys trust in the live ones too.
Measurement: reach, speed, quality
After a quarter, someone will ask whether any of this was worth it. You will have a dashboard full of numbers going up, and most of them do not answer the question. The test: a real metric is hard to move without a real change in behaviour.
| Metric | What it actually tells you |
|---|---|
| Number of skills in the repo | How much got built |
| Number of invocations | How much activity was created |
| Unique users per week | How wide adoption really is |
| Task completion time | Whether the work got shorter |
| Fixes and failures | Whether quality held |
What worked for us was checking three dimensions together. Reach - how many unique users this week. Speed - whether completion time or time to first PR came down. Quality - whether rework cycles and manual interventions stayed flat or fell. Adoption without improvement is activity; speed without quality is debt. A successful skill reaches more people, shortens the work, and does not push the cost into review or production.
One important caveat: time to PR is only a useful metric when you compare similar tasks and look at the trend over time. Otherwise it is driven by task size and engineer seniority far more than by the skill.
The first two parts of this series were about what you build: a good unit of knowledge, and an agent capable of acting. This part was about what happens when they meet an organisation. Building a good skill is development work; getting a whole team to find it, trust it and maintain it is engineering work. A skill becomes infrastructure not when it lands in the repo, but when it disappears into the way the team works. As long as you have to remind people to use it, you have not finished building it.