Skill Vault

The problem

Our team does not work in one AI tool. We move between Claude, Cursor and others depending on the job, and each wanted its own copy of the skills we rely on. Copies drift. Before long nobody could say which version of a skill was current, or which tool was still running the old one.

A skill improved in one tool stayed stale in the other three. A fix made on one laptop never reached the next person. Nobody could see which skills were actually used, or whether a change had made them better or worse. For a team whose delivery process runs on AI, the process itself had no single source of truth. The brief: write a skill once, change it deliberately, and have every tool read the same version.

What I built

A vendor-neutral repository for AI skills. Not a gateway and not a marketplace: skills are plain markdown, the repository is the product, and MCP is simply how AI tools read it.

• One endpoint, every client

  A single MCP endpoint serves each person every skill they can reach, across every organisation they belong to. People connect their AI client through the browser once, and there is nothing to set up per tool.

• Change, on the record

  Only authorised admins change a skill. Every save becomes an immutable version you can compare and roll back to, with an audit trail of who did what and when.

• Everyone contributes, admins decide

  Anyone can raise feedback or propose an improvement, including from inside their AI client. Admins review the change side by side with the current version and choose what lands.

• Know what is actually used

  Usage is recorded when a skill is read, not when a client connects, so analytics show which skills are retrieved, by which teams and clients, and how often a use ends in success.

My role

Sole developer. I wrote the product spec first and had it reviewed independently, then split the build into sixteen epics and ran them in dependency waves: several agents building at once, each on its own branch against its own isolated database, with me merging and verifying every wave before the next one started.

I designed and shipped identity with organisation and team roles, multi-file skill versioning, the contribution-and-review workflow, an OAuth 2.1 server with MFA and dynamic client registration for MCP clients, consumption analytics and audit, all on Postgres row-level security across 24 tables.

Key decisions

1. A repository, not a gateway

   Skills stay plain markdown and the product never sits between a team and its model. Any MCP-capable tool can read them, so nobody is locked to one vendor.

2. Listing and reading are separate calls

   A client only loads the skills it actually uses, and usage is counted on read. Both keep context small and make the analytics honest.

3. Permissions live in the database

   Rules are enforced by row-level security and checked live on every request, so removing someone takes effect immediately. More than a thousand tests guard them, and nothing merges unless the suite passes.

In the product

Outcome

Written once

Every skill lives in one library instead of a copy per tool, per person.

Read everywhere

Claude, Cursor and our own agents all read the same current version.

Changed deliberately

Every edit is versioned, attributed and reversible.

Proven in‑house

One Eleven’s own delivery process runs on it before any client project does.

Stack