The system of record for the skills our AI tools run on.
Our team does not work in one AI tool. We move between Claude, Cursor and others depending on the job, and each of them 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. We needed one governed home for all of it, so we built SkillVault.
The problem
The problem was never writing skills. It was keeping them the same everywhere.
A skill that improves in one tool stays stale in the other three. A fix made on one laptop never reaches the next person. Nobody could see which skills were actually being used, or whether a change had made them better or worse. For a team whose whole delivery process runs on AI, that meant the process itself had no single source of truth.
So the brief was short: write a skill once, change it deliberately, and have every tool read the same version.
What we built
SkillVault is a vendor-neutral repository for AI skills. It is 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.
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. Listing a skill and reading it are separate calls, so a client only loads the skills it actually uses.
Result: Claude, Cursor and our own agents all read the same live version.
Only authorised admins change a skill. Every save becomes an immutable version you can compare and roll back to, and an audit trail records who did what and when. Permissions are checked live on every request, so removing someone takes effect immediately.
Result: A bad edit costs a rollback, not an investigation.
Anyone can raise feedback, report an issue or propose an improvement, including from inside their AI client while they are using the skill. Admins review the proposed change side by side with the current version and choose what lands.
Result: Improvements come from the people using the skills, without anyone losing control of them.
Usage is recorded when a skill is read, not when a client connects, so the analytics mean something. They show which skills are retrieved most, which teams and clients use them, and how often a use ends in success.
Result: We retire what nobody reads and invest in what everyone does.
In the product
Admins get versioning, review and analytics. Everyone else gets their skills inside the AI tool they already use, and a way to say when one could be better.
How we built it
SkillVault was built with our own AI-orchestrated delivery process. We 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 a lead merging and verifying every wave before the next one started.
The guardrails did the heavy lifting. Permission rules live in the database and are covered by more than a thousand automated tests, and nothing merges unless the suite passes. Speed came from parallel work. Confidence came from never letting any of it merge unchecked.
It is the same process we run on client projects. SkillVault is where we proved it on ourselves first, and today it stores the skills that process runs on.
Value delivered
The team stopped maintaining skills tool by tool. Now there is one place to improve a skill, and every tool picks up the improvement.
The toolkit
We start every relationship with a free consultation: an honest conversation about what you are trying to do. No pitch, no obligation.
