localskills.sh
AI Skill & MCP server management for teams & enterprises
126 followers
AI Skill & MCP server management for teams & enterprises
126 followers
Create, share, and install reusable agent skills and rules for Cursor, Claude Code, Windsurf, and more. One install command, every tool.
@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?
localskills.sh
@clement_avq Yes! as well as which version of which skill is consumed by which user
@matthew_zhao3 That's useful! so if an admin spots someone stuck on a stale version, is there any way to nudge or force the re-pull from the admin side, or does it still come down to asking that person to do it manually?
localskills.sh
@clement_avq Just pinging the other person on Slack is the current solution. We generally don't want to turn the LocalSkills CLI into a daemon because it brings in another layer of complexity.
Arguably if you implement skill consumption via the MCP, you can write something like `use git-format-skill@1.3.1` and the agent harness will pull the fresh skill during a prompt invocation.
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.
localskills.sh
@omri_ben_shoham1 The general idea is that you pick the skill you install from your registry, just by loading LocalSkills MCP doesn't mean it will load all the skills in the workspace.
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.
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.
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.
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.
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.