localskills.sh

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

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?