localskills.sh

AI Skill & MCP server management for teams & enterprises

Productivity

Developer Tools

GitHub

Visit WebsiteSee on Product Hunt

We publish a few dozen agent skills, so I live on the other side of this. The problem that hurts most isn't install, it's drift: the skill updates, and every agent that loaded the old copy keeps confidently doing the old thing. Does localskills pin versions per team, and can I see which version each agent actually has loaded? That audit view would be the feature that sells me.

Would love to see a way to version-pin specific skills when installing, so a team can lock to a known-good build instead of always pulling latest. Something like a lockfile or a `--version` flag per skill would make shared agent rules way more reliable across projects.

The single install command across multiple editors is genuinely useful. Saved me from copy-pasting the same skill definitions into Cursor and Claude Code for the third time.

A nice take on making agent skills portable across editors. One thing that would help me get started: a built-in preview or diff view that shows exactly what each skill will inject into my project before I run the install command, so I can trust what is being added to my rules and configs.

A versioning system for skills would be huge, something like pinning specific versions when installing so updates don't silently break workflows. Maybe a `localskills install owner/[email protected]` syntax with a lockfile would make it way more reliable for team setups.

Centralized skill and MCP management feels increasingly necessary for teams. Does localskills support signed provenance, version pinning, approval policies, and rapid rollback when a skill update causes unexpected behavior?

One install command across every tool is the obviously useful part, so I will ask about the part that tends to get hard later. Once a skill is installed across a team, how does anyone know it still does what it did last month? The underlying tools move, prompts rot quietly, and the failure mode is not an error, it is slightly worse output that nobody attributes to the skill. Do you give a team any way to see that a shared skill still behaves, or is that on the author to keep an eye on? Asking because reusable prompt assets are easy to share and genuinely hard to keep honest. Congrats on shipping this.

The thing I'd want from a registry that a dotfile never had to solve is selection. I keep 16 skills in one project, and the failure mode isn't that they die unread — it's that two of them describe overlapping territory and the agent picks the wrong one, or reaches for none and answers from general knowledge instead. Right now that's self-limiting, because installing a skill costs me the work of writing it. One install command removes that cost, and a team namespace with 200 skills in it turns the description string into the real interface: whatever sits in that field is competing against 199 others for a decision the model makes in a fraction of a second.

Do you do anything about that at publish time — collision detection against descriptions already in the namespace, or a lint that flags a new skill whose trigger surface overlaps an existing one? Abdullah's point about never being able to prove what loaded gets sharper at that size, because "it never fired" and "the wrong one fired" look identical from outside the run.

@matthew_zhao3 The governance and versioning answers above cover a lot of ground. One thing I didn't see addressed: once a skill is published and adopted, can an admin see usage data, like which skills are actually being pulled across the org versus sitting unused?

Would love to see a simple way to preview what a skill does before installing it, like a short description or example output. Right now I have to trust the repo blindly, and a quick "what you'll get" snippet would make it way easier to decide which skills to grab.

The dotfiles problem is real. The cross-tool support is what makes this genuinely useful though: Claude Code, Cursor, and Windsurf each interpret rule directives differently enough that a shared skill definition needs to either normalize across them or emit tool-specific outputs. How does localskills handle skills that need slightly different behavior per agent runtime without requiring separate skill definitions for each tool?

one thing not covered above - what happens when two installed skills actively contradict each other. say one teammate published a skill that says always squash commits and another published one that says never rewrite history. does localskills flag that kind of conflict when both get pulled into the same session, or does the agent just silently pick whichever loaded last and nobody notices until someone's history gets rewritten unexpectedly.

The version question upthread has a quieter cousin, and I think it is the one that actually bites.

Drift is at least detectable. Two people compare notes and find different versions. A skill that fails to load at all, or loads a version nobody expected, produces no signal whatsoever. A missing dependency throws. A missing skill just means the agent answers without the rules that were meant to constrain it, and that answer looks completely normal. I keep my own agent rules in one global file with a stack of skills beside it, and the runs that cost me were never the ones that errored. They were the ones where a rule sitting right there on disk plainly did not reach the model, and nothing in the output said so.

So underneath the permissions and pinning questions: can a run prove which skills were in its context, after the fact? Installed and loaded are different claims, and only one of them is checkable right now.

Mine would be a pre-deploy checklist skill, the boring one nobody keeps updated. The mid-task pull is the part I would want to understand though. If a skill carries rules that shape what the agent does, whoever can publish to the namespace can change agent behaviour without a code review. Is publishing gated by the same reviewers as a repo merge, or by namespace permission alone?

The "dies in someone's dotfiles" framing is exactly right — I've seen the same happen with .cursorrules and Cursor rules files that only the senior who wrote them actually knows about. One thing I'd want to understand before rolling this out: is the skills registry self-hosted by default, or does it live in your cloud? If team-specific conventions end up baked into a skill definition — internal API patterns, data handling rules — that changes the trust model depending on where the registry lives.

the "dies in someone's dotfiles" framing is exactly right, every team I've seen has one senior engineer's excellent cursor rules file that nobody else knows exists. to answer your question - probably a PR-description skill that pulls from the actual diff instead of the commit messages, ours are always out of sync with what actually changed.

question on the mid-task pull via MCP - if a skill gets updated mid-sprint, does an agent already partway through a task on the old version get bumped automatically, or does it keep running on whatever it pulled at task start? version drift across a team seems like the thing that'd quietly cause the most confusion if two people's agents are working off different skill versions without realizing it