Launching today
localskills.sh
AI Skill & MCP server management for teams & enterprises
100 followers
AI Skill & MCP server management for teams & enterprises
100 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.
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.
localskills.sh
@upton_zen The idea currently is that 99% of what you install at LocalSkills is your organization's internal skills, however we can definitely look into a AI summarization feature for what a skill does.
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.
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?
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/skill@1.2.0` syntax with a lockfile would make it way more reliable for team setups.
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.