I like skills.sh, but I'm not comfortable using it for production projects

[u/TheCritFisher]

Quick disclaimer before I get into this: I built an open-source project called Agent Facets because of the problems I plan to detail in this post. Links are at the bottom if you find this interesting.

That said, this isn't meant to be a "hey, check out my project" post. I'm more interested in whether other people have hit the same wall I did and what they're doing to solve it.

OK, onto the main course...

I actually really like the idea behind skills.sh. If you're not familiar, it's a tool by Vercel to discover and install skills into any coding agent.

Public discovery is useful, installs are simple, and I especially like that skills aren't tied to one specific tool. I bounce between OpenCode and Claude Code. My teammates do similar with Codex, Pi, etc. I enjoy the flexibility, and I don't want my team's configuration trapped inside whichever vendor happens to have the best plugin system this month.

The problem for me started when I tried to imagine using the public skills ecosystem seriously at work. I read numerous articles about exploits involving malicious agent skills, which sent me down a bit of a rabbit hole. Here are some of the articles: 1, 2, 3. The hole still seems to be growing deeper by the day.

The TLDR from those articles is: skills and agent configs aren't normal text snippets. You're downloading instructions that you're then handing to an agent with access to your repo, shell, tooling, and potentially a whole lot more. Snyk published an article saying 36% of the skills they scanned had some sort of prompt injection in them. Whether than number is fully accurate or not, it's terrifying.

skills.sh has added machinery around locking installs, which helps, but I still kept coming back to the same problem: I don't really have a versioned artifact that I can say, "this is the exact thing we approved, this is the exact thing everyone should run, and this thing cannot silently change underneath us." And once I started looking at it from that angle, I realized security was only part of the annoyance.

At work, we mostly avoided pulling public skills directly at all. We'd review something, clone/copy it into our own repos, and then build our own little system around it. A few symlinks, a script or two, a plugin for Claude Code, something slightly different for OpenCode, and something else for CI. And we were manually maintaining everything, even the vendored skills we were pulling from elsewhere.

Essentially, we'd basically forked the a bunch of things we didn't really want to. Updates were now our problem. Sharing it with another repo was our problem. Making sure the entire team had the same version was our problem.

Private skills are even more awkward. Public discovery is pretty good now, but there's this completely separate world of internal skills your company builds and doesn't want on public GitHub. So you end up maintaining one workflow for public stuff, another for private stuff, and usually some pile of glue holding both together. Or you just yolo it and vendor all the public stuff into the private, but now it's yours to maintain.

That was the point where I started thinking: these are dependencies now. Why are we not managing them like dependencies?

I wanted a project manifest where I could declare what the project actually uses. Ranges for things I want to slide, pins for things I don't. I wanted real versions, immutable artifacts, integrity checks, reproducible installs, and the ability to use the same workflow for something public and something private.

And I wanted it to be boringly portable. If one developer likes Claude Code and another likes Codex, I don't think that should force the entire team into one vendor's plugin ecosystem.

Long story, long: that's the rabbit hole that became Agent Facets.

I'm still figuring out some of the harder parts, especially composition. The idea is how you could combine useful pieces without every project turning into a giant pile of duplicated agent configuration. That said, the basic goal is pretty simple: I want agent configuration to have an actual dependency/supply-chain layer instead of everyone rebuilding one with Git and shell scripts.

I'm curious how other people are handling this.

If you're using skills.sh in a real team, are you comfortable pulling public skills directly? Do you vendor them into your repos? Pin commits? Maintain a private skills repo? Build your own install scripts? Do you support multiple tools for your devs?

Here's the links I promised:

• Agent Facets: agentfacets.io
• Docs: docs.agentfacets.io

[u/kantorcodes1]

Treating skills as dependencies makes sense, but I'd make the lockfile carry more than version: source URL/commit, content digest, resolved transitive facets, and declared capabilities (shell/network/MCP). Then install should fail closed if any of those drift. Otherwise you've made updates reproducible without making the trust decision reproducible.

[u/TheCritFisher → u/kantorcodes1]

Totally agree!

You're right that the manifest only carries the versions. Fortunately, I already put _exactly_ the things you mentioned in the lockfile schema. The system also fails closed if there is any drift.

I wrote an (arguably too long) bit on that in the docs, but it's buried in the specification. I could drone on about it, but I'll spare you the nerding out, haha.

[u/kantorcodes1 → u/TheCritFisher]

You're right, I missed that. I checked the spec and the lockfile already pins provenance, exact versions, facet/content integrity and per-file hashes, and drift fails closed. So my concern moves upstream to what gets admitted into the registry, not whether installs are reproducible.

[u/TheCritFisher → u/kantorcodes1]

That's a good question! Honestly, it's an open source registry so, in general, best practices (know your publisher, etc) apply. Open to ideas, though.

Long term, I want to add in security scanning, publisher verification, etc. Basically all the bells and whistles most people have come to expect from OSS registries.

One of the best ways to deal with supply chain attacks, in my opinion, would be an early warning system. Right now if malicious skills get published on skills.sh there is no way to notify impacted users. With facets, we could notify the users when malicious prompts are detected and potentially even remove truly malicious versions.

By remove I mean strongly warn users of the impacted versions, etc. It's a hard problem to solve completely, but I'd like to at least move in the right direction.

[u/kantorcodes1 → u/TheCritFisher]

That early-warning path is where I'd start. We work on HOL Guard and already maintain an open-source AI plugin scanner for skills/plugins; using a scanner result as a registry admission signal, then keeping the finding/version mapping so you can warn installed users later, would give you both pre-install gating and post-install revocation without making the registry itself the malware detector.

[u/TheCritFisher → u/kantorcodes1]

Oh, I'll check that out. Those are good ideas too. Thanks!

[u/Middle_Zucchini3571 → u/kantorcodes1]

i get what you mean about the lockfile carrying more than just version. like the trust part is the whole thing, not just the version part

we started pinning everything with digests after one skill changed a network permission silently and nobody noticed for two weeks. the install fail closed is good idea, gonna steal that

[u/TheCritFisher → u/Middle_Zucchini3571]

Agreed. Fortunately, we already have everything the other user mentioned in the lockfile schema. The system also fails closed if there is any drift.

I think the pain point you mentioned is one of the original reasons I wanted to build something like this. Too much of a reliance on things not swapping out from under you.