LightfieldAI-native CRM that builds itself and does work for you
Promoted
localskills.sh
AI Skill & MCP server management for teams & enterprises
130 followers
AI Skill & MCP server management for teams & enterprises
130 followers
Create, share, and install reusable agent skills and rules for Cursor, Claude Code, Windsurf, and more. One install command, every tool.
localskills.sh
Hey PH 👋 Matthew here.
Everyone is writing skills and rules for their coding agents, and almost all of them die in someone's dotfiles. localskills.sh is a registry that fixes that.
Publish a skill once, install it into Claude Code, Cursor, Windsurf, Codex, or Copilot with one command. Teams get a private namespace with permissions, SSO, and two-way GitHub sync. There's an MCP server, so your agent can pull skills on its own mid-task.
What's the one skill you'd want your whole team using?
Pythagora
@matthew_zhao3 This looks awesome. Congratulations on the launch and best of luck with the momentum! 🚀
Dial
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
localskills.sh
@galdayan Thanks for the review. For your question, you would have to ask the agent to re-pull the skill just because the MCP protocol does not currently have a method of sending an update to the end consumer.
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?
localskills.sh
@rahulladumor A few things to gate a supply chain skill update attack here. We have granular ACL for skills and folders and role based permission systems in LocalSkills, we also support pinning down an exact version (versions are immutable) of a skill to fetch via the cli or MCP. It is definitely in the works though to support a more complete multi user contribution system similar to GitHub pull requests.
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.
localskills.sh
@abdullah_javaid3 This is a really interesting problem we will look into. With what we have currently, if you load a skill via the MCP, the version is loaded into context as part of the MCP response and will persist in context after compaction.
@matthew_zhao3 That covers the path where the pull happens, which is the half I am least worried about.
The case I would want covered is the response that never arrives, or the skill the agent simply never thought to fetch. There the record and the skill are missing together, so nothing in context can tell you whether the skill was skipped or never requested. Proof of loading that lives inside the context window is produced by the same run that may have skipped it.
Which is why I would want it server side. You already know which namespace served what to which session. A per run list of skills actually fetched would be checkable without asking the agent to vouch for itself, and it would turn a support conversation from why did it ignore our rules into it never pulled them.
localskills.sh
@abdullah_javaid3 Good question. This is not something we have a answer for today and we will definitely add this to the roadmap!
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?
localskills.sh
@anand_thakkar1 We have not seen a usecase like that in the wild where you can not define various behaviors in the skill files themselves. Happy to hear more about your use case.
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 "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.
localskills.sh
@hi_i_am_mimo The registry is hosted on the LocalSkills cloud, however you can link a Github repository to LocalSkills for continuous data export so we won't lock your data in the platform.