SkillRepo is the open distribution layer for AI agent skills. Where engineering teams discover, curate, and standardize what every agent runs across 30+ compatible tools. Where publishers supply the skills that power them.
We built SkillRepo as the open distribution layer for these skills to give every agent the same starting point: one shared library of skills instead of a dozen hand-copied folders. It's built on the open Agent Skills standard (agentskills.io). Every skill in it carries a grade from SkillRepo's automated analysis before anyone runs it, every engineer's agent syncs it at the start of a session, and an improvement published in the morning reaches the whole team by the afternoon.
Teams kept telling us two things. First: not everyone should run the same skills. The set your marketing team needs has some overlap with what customer support needs — and a lot that has no business being there. Second: an outside publisher's update shouldn't reach our whole fleet before we've read it. You gate the dependencies that matter in your code. The instructions your agents follow deserve the same gate.
So we built Skillsets.
A skillset is a named, graded collection of skills from your library, composed by a team lead, that a group of repositories runs. You decide what goes in each set and which team runs which — publishers supply skills; they never decide who runs them. Two sets can share skills and each carry skills the other doesn't. A repository adopts a skillset with a one-line committed file, reviewed like any other change. And every skill in every set is still a SkillRepo skill: graded, attributed, delivered by the same session-start sync as today.
Here is what that lets you do:
Give each team exactly its set. Compose a skillset per team or per class of repository — its own name, description, and grade roll-up — instead of sending the whole library everywhere.
Approve updates before they roll out. When a public publisher releases a new version of a skill in one of your sets, it does not propagate. You get a notification, review the change, and approve it — then everyone on the team gets the updated version at their next sync. Publishers you explicitly trust skip the queue; your own team's skills ship the moment you publish them.
See what actually reached every repository. Each skillset shows its repositories with a plain answer per row: compliant (exactly matches the approved set), not compliant (with what's off — "writing-voice missing — in the skillset but not delivered here"), or not synced recently (no sync report in 14+ days). Every sync is recorded: which skills, which versions, when.
If your agents run skills across an organization, this is the difference between instructions as informal knowledge — copied around, changing on someone else's schedule — and instructions as a managed asset: composed deliberately, updated when you approve it, with a record of what ran where. The skills stay in the open format your tools already read, whether that's Claude Code, Cursor, or Copilot; what Skillsets adds is the decision layer around them.
What it guarantees — and what it doesn't
Skillsets controls and records the input: the approved skill, delivered to the path the tool reads. It does not guarantee that an agent then follows the guidance perfectly — no one can promise you that, and you should be wary of anyone who does. Controlling and recording the input is the same basis every audited discipline relies on when it certifies a procedure rather than inspecting every result. Against today's alternative — no control and no record — it is a large step, and an honest one.
Two more honest notes. A review queue that nobody tends is a team slowly falling behind; give it an owner. And a machine that never syncs can't be forced — it shows up as silent in the same view, so you follow up.
Why not just git?
For one repository, git is the right start: skills are files, protect the branch, review the changes. What git in one repository cannot do is carry an approved change across fifty repositories at once, put an outside author's release behind your approval, or hold one approved set across the different tools your teams actually use. The moment the same skill must be identical in more than one place, hand-copying is the drift you were trying to remove. Each tool vendor is adding governance inside its own product — which helps, and leaves the gap exactly where it was, because no serious organization runs on one tool. A neutral layer across them is the thing a tool vendor can't build. That layer is what SkillRepo is for.
Available today
Skillsets is live now for every Team plan. Open Skillsets in the sidebar, compose your first set from your library, and point a repository at it — the whole loop takes minutes. The docs cover the review queue, trusted publishers, and recall.
Your agents were already running on these instructions. Now you decide which ones, everywhere, on the record.
We built SkillRepo as the open distribution layer for these skills to give every agent the same starting point: one shared library of skills instead of a dozen hand-copied folders. It's built on the open Agent Skills standard (agentskills.io). Every skill in it carries a grade from SkillRepo's automated analysis before anyone runs it, every engineer's agent syncs it at the start of a session, and an improvement published in the morning reaches the whole team by the afternoon.
Teams kept telling us two things. First: not everyone should run the same skills. The set your marketing team needs has some overlap with what customer support needs — and a lot that has no business being there. Second: an outside publisher's update shouldn't reach our whole fleet before we've read it. You gate the dependencies that matter in your code. The instructions your agents follow deserve the same gate.
So we built Skillsets.
A skillset is a named, graded collection of skills from your library, composed by a team lead, that a group of repositories runs. You decide what goes in each set and which team runs which — publishers supply skills; they never decide who runs them. Two sets can share skills and each carry skills the other doesn't. A repository adopts a skillset with a one-line committed file, reviewed like any other change. And every skill in every set is still a SkillRepo skill: graded, attributed, delivered by the same session-start sync as today.
Here is what that lets you do:
Give each team exactly its set. Compose a skillset per team or per class of repository — its own name, description, and grade roll-up — instead of sending the whole library everywhere.
Approve updates before they roll out. When a public publisher releases a new version of a skill in one of your sets, it does not propagate. You get a notification, review the change, and approve it — then everyone on the team gets the updated version at their next sync. Publishers you explicitly trust skip the queue; your own team's skills ship the moment you publish them.
See what actually reached every repository. Each skillset shows its repositories with a plain answer per row: compliant (exactly matches the approved set), not compliant (with what's off — "writing-voice missing — in the skillset but not delivered here"), or not synced recently (no sync report in 14+ days). Every sync is recorded: which skills, which versions, when.
If your agents run skills across an organization, this is the difference between instructions as informal knowledge — copied around, changing on someone else's schedule — and instructions as a managed asset: composed deliberately, updated when you approve it, with a record of what ran where. The skills stay in the open format your tools already read, whether that's Claude Code, Cursor, or Copilot; what Skillsets adds is the decision layer around them.
What it guarantees — and what it doesn't
Skillsets controls and records the input: the approved skill, delivered to the path the tool reads. It does not guarantee that an agent then follows the guidance perfectly — no one can promise you that, and you should be wary of anyone who does. Controlling and recording the input is the same basis every audited discipline relies on when it certifies a procedure rather than inspecting every result. Against today's alternative — no control and no record — it is a large step, and an honest one.
Two more honest notes. A review queue that nobody tends is a team slowly falling behind; give it an owner. And a machine that never syncs can't be forced — it shows up as silent in the same view, so you follow up.
Why not just git?
For one repository, git is the right start: skills are files, protect the branch, review the changes. What git in one repository cannot do is carry an approved change across fifty repositories at once, put an outside author's release behind your approval, or hold one approved set across the different tools your teams actually use. The moment the same skill must be identical in more than one place, hand-copying is the drift you were trying to remove. Each tool vendor is adding governance inside its own product — which helps, and leaves the gap exactly where it was, because no serious organization runs on one tool. A neutral layer across them is the thing a tool vendor can't build. That layer is what SkillRepo is for.
Available today
Skillsets is live now for every Team plan. Open Skillsets in the sidebar, compose your first set from your library, and point a repository at it — the whole loop takes minutes. The docs cover the review queue, trusted publishers, and recall.
Your agents were already running on these instructions. Now you decide which ones, everywhere, on the record.
Poke at the public catalog, no signup: https://skillrepo.dev/skills. The Team plan's a 14-day trial, no card: https://skillrepo.dev/pricing.
If you lead a team, what would keep you from rolling this out: the migration, the grading, or how your repos are wired?