Chapter 14 of 15

Build a Skill Library People Can Actually Use

The organisational problem is not just creating skills. It is making them discoverable, understandable, owned, and safe enough that teams use the existing capability instead of rebuilding the same thing in five places.

  • Skill catalogue and discovery
  • Naming and documentation
  • Owners and subject-matter experts
  • Shared versus tenant-specific skills
  • Templates for new skills
  • Preventing duplicate capabilities

The situation

As more teams adopt agents, duplicate capabilities appear quickly. Sales builds a company-research skill, marketing builds another, customer success builds a third, and each one retrieves similar data with slightly different rules. Nobody knows which version is authoritative.

The naive solution

Let every team create whatever skill it needs. Reuse can be cleaned up later once adoption is proven.

The hidden constraint

Duplicate skills create duplicate cost, inconsistent answers, inconsistent permissions, and inconsistent policy. Centralising everything is not automatically better either; one platform team can become a bottleneck that does not understand domain details.

The decision

Create a shared skill catalogue with clear ownership and contribution rules. I want common infrastructure and governance with domain experts owning domain behaviour.

The implementation

Each catalogue entry should explain purpose, owner, inputs, outputs, permissions, status, version, expected use cases, when not to use it, dependencies, and evaluation coverage. I would provide a standard template so new skills begin with the same questions. Search and tagging matter as the library grows. Tenant- or client-specific variants should be explicit extensions or configurations rather than hidden copies when possible.

The tradeoff

A catalogue adds process and requires someone to curate it. The payoff is that capabilities become discoverable assets rather than private prompt fragments living in individual projects.

The evidence I would look for

I would look for increasing reuse of stable capabilities, fewer near-duplicate tools and prompts, clear ownership when a business rule changes, and faster creation of new workflows because teams can compose trusted skills rather than rebuild foundations.

The reusable lesson

The skill library is a product for the people building agent workflows. Treat discoverability and ownership as seriously as the skill implementation.

The consultant's questions

  • How would a new engineer discover that a capability already exists?
  • Who decides which of two overlapping skills is authoritative?
  • Which skill behaviour should be shared globally and which genuinely needs tenant-specific variation?
  • Do new skills start from a consistent design and review template?