Hey Dylan, long time. The solution we landed on was that the skills should be authored by a small set of people who know what they’re doing and made available to non technical team members “magically”. This means either use your IT systems to push the configs, or embed them into an agent that doesn’t live on the desktop. We’ve gone the latter route and are building a whole company around solving this for regulated customers.
We've adopted a simple/similar Dropbox-based approach for skills and rules - each person's ~/.claude/skills is actually symlinked to a folder just for them inside a shared Dropbox folder, one that others on our (small) team can see and edit as well.
This solves a set of problems around people writing skills that reference artifacts or skills that only exist on their system, and/or that reference their own name/information as the creator, and not knowing to make them self-contained and replicable. Luckily, adapting your colleagues' skills to self-contained versions and pulling them into your folder is trivial to instruct an agent to do. And you can have meta-skills that do this on the fly if a colleague has a skill that would unblock your project!
The courtesy simply has to be that you don't write into other people's skill folders unless/until they ask you to maintain something for them - at which point the words "I am assuming direct control" are said with all the necessary gravity and effect.
It's great to see someone putting UI and guardrails around this pattern!
The one place I’ve seen this break down on teams is when a skill gets improved or adjusted. If everyone is copying it you end up not knowing which the best and most accurate. We worked with a team that had 5 copies that had all drifted.
That is why we built the deduplicator extension for sx. It finds the dups and lets you use the llm to build the consolidated “best” version of the skill.
To the point of people overtuning/overfitting skills that were once generic, to overly reference and draw upon their private preferences and workflows... sometimes having "installation = effectively forking" for a known-good skill is a feature, not a bug!
I can't think of anything worse than sharing skills via Dropbox. The version management and AIBoM problems that generates is extremely painful. There's no way to track which version LLM is being used or match it against the skill, and people will likely load up too many skills.
You don't have to expose git repos to end users to use git, or some other database, to provision skills.
I completely agree and sx tries to make it easier to share, not just on one project/repo but across teams.
For example, we have a collection of skills that have to do with brand marketing and blog writing. But developers use these too when blogging. That way all skills and knowledge in the org are shared. Not just with the folks who have git access and know where to look.
A repo, if it’s not overly complex, is a great place to store skills for all the reasons you list. It’s just not the only place where skills are super valuable.
Why not a private GitHub repo? It's hard to believe that the technical team could not write 1 skill which all non-technical teams could use to sync their skills to GitHub.
23 comments
[ 2.8 ms ] story [ 29.9 ms ] threadSimple pull & push would do.
- free version control - one line set up
This solves a set of problems around people writing skills that reference artifacts or skills that only exist on their system, and/or that reference their own name/information as the creator, and not knowing to make them self-contained and replicable. Luckily, adapting your colleagues' skills to self-contained versions and pulling them into your folder is trivial to instruct an agent to do. And you can have meta-skills that do this on the fly if a colleague has a skill that would unblock your project!
The courtesy simply has to be that you don't write into other people's skill folders unless/until they ask you to maintain something for them - at which point the words "I am assuming direct control" are said with all the necessary gravity and effect.
It's great to see someone putting UI and guardrails around this pattern!
That is why we built the deduplicator extension for sx. It finds the dups and lets you use the llm to build the consolidated “best” version of the skill.
You don't have to expose git repos to end users to use git, or some other database, to provision skills.
Honestly from a BoM and version control standpoint, the fax might work out to be superior… they come timestamped; pop them in a filing cabinet, and…
For example, we have a collection of skills that have to do with brand marketing and blog writing. But developers use these too when blogging. That way all skills and knowledge in the org are shared. Not just with the folks who have git access and know where to look.
An advantage of this is when you got to hotfix an old customer, the skills align with how the code was authored at that point in time.
Are you manually keeping all copies in sync?