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.
Legitimately, it would work better. I could bulk fax Skills to each of the branch offices on Monday afternoon in preparation for the AI teleconference bridge meeting at 8AM. They can fax back any suggested improvements on Friday.
Because the thermal paper fades you would need freshly faxed Skills every few weeks or the turbo encabulator would misfeed when they were loaded. In fact, I'd have the local steno pool ladies feed in a weekly fax with authorisation codes for each Skill, and without that it just wouldn't load.
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.
Hey man! Yeah, many of the non-techincal folks I've spoken to are using claude.ai or chatgpt.com. But I've been amazed at how many are using Claude CoWork or even Claude Code.
The theme seems to be wanting the same set of knowledge across any and every tool they use, without having to worry much about the mechanics of the how.
I agree that for security and governance conscious orgs a more robust server-side solution is probably what's needed. We've built that vault for sx as well. However, I am seeing that many larger orgs have decided to just build it themselves. There was a post from Mike at Gusto the other day saying as much.
Yup I agree with the consistent access across surfaces ideal. WorkOS has some cool piping to support this and uses it for their internal version of the same thing. I think everyone experimenting here is a good thing. I expect we’ll end up with a few good commonly use OSS approaches, a few tech companies with NIH syndrome versions for their needs, and commercial options like we have with past technologies. These are more reflections of culture amongst buyers than anything else.
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 other 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! (Editing to add a tip: make sure all the folders are set to offline visibility in Dropbox, rather than being loaded on demand from online.)
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 agree that that works pretty well for developers who work with a code repository everyday. But, if you're working on a mono-repo, you can end up with more skills loading than you'd like pretty quickily.
Have you had success with non-technical people using git as their primary sharing source?
My extension for pi https://github.com/gitsense/pi-brains solves the too many skills problem and it can be adapted to work with any coding agent that supports hooks like Claude and Codex.
Git has easy to use GUI tools, particularly if you’re willing to use GitHub. I have not had trouble getting non technical staff to use it (book editors, graphic designers, writers, copywriters)
That makes sense. The one thing that really bugs me about git sharing is when you have different repos but want to share the same collection of skills. We have three different golang projects/repos. They follow very similar patterns and can share a bunch of skills but I don't want to copy/paste into the different repos and have them drift.
I also like having a system on top that manages our evals so I know when I can retire a skill that isn't pulling it's weight and I can see the usage stats to understand which skills are making a real difference.
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.
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.
sx has a git vault storage layer, or a local file layer or a server backed vault.
The thing it buys you over vanilla git is that you don't have to sym-link dirs for different AI harnesses. And, you can share skills across repos and teams without having to copy them into different repositories.
All that said, with the right setup, I think that vanilla git is a great answer. But if you start to want to bundle collections and share across teams and repos things start to fall apart.
Do you try to share across teams or repos? Or with non-technical teams?
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.
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.
It would probably be worse to fax them to your teammates
I mean
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…
Legitimately, it would work better. I could bulk fax Skills to each of the branch offices on Monday afternoon in preparation for the AI teleconference bridge meeting at 8AM. They can fax back any suggested improvements on Friday.
Because the thermal paper fades you would need freshly faxed Skills every few weeks or the turbo encabulator would misfeed when they were loaded. In fact, I'd have the local steno pool ladies feed in a weekly fax with authorisation codes for each Skill, and without that it just wouldn't load.
Y2K technology for the win.
How do you concretely solve this for your marketing team? What’s the tech stack you have in place to support them?
Librechat self-hosted in our cluster that points to our ZDR ai gateway. They have SSO logins.
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.
Hey man! Yeah, many of the non-techincal folks I've spoken to are using claude.ai or chatgpt.com. But I've been amazed at how many are using Claude CoWork or even Claude Code.
The theme seems to be wanting the same set of knowledge across any and every tool they use, without having to worry much about the mechanics of the how.
I agree that for security and governance conscious orgs a more robust server-side solution is probably what's needed. We've built that vault for sx as well. However, I am seeing that many larger orgs have decided to just build it themselves. There was a post from Mike at Gusto the other day saying as much.
The cost for build has just gotten so low now...
Yup I agree with the consistent access across surfaces ideal. WorkOS has some cool piping to support this and uses it for their internal version of the same thing. I think everyone experimenting here is a good thing. I expect we’ll end up with a few good commonly use OSS approaches, a few tech companies with NIH syndrome versions for their needs, and commercial options like we have with past technologies. These are more reflections of culture amongst buyers than anything else.
It also wouldn't surprise me if the model companies ship a strong version of this to try to lock us all in a bit more.
I hope that's not the case, or at the very least one storage and distribution system will work for all harnesses.
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 other 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! (Editing to add a tip: make sure all the folders are set to offline visibility in Dropbox, rather than being loaded on demand from online.)
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!
We hosted shared skills via a git repo.
Simple pull & push would do.
I agree that that works pretty well for developers who work with a code repository everyday. But, if you're working on a mono-repo, you can end up with more skills loading than you'd like pretty quickily.
Have you had success with non-technical people using git as their primary sharing source?
My extension for pi https://github.com/gitsense/pi-brains solves the too many skills problem and it can be adapted to work with any coding agent that supports hooks like Claude and Codex.
You can find a simple example at https://github.com/gitsense/gsc-rules-demos which shows how skills can be injected when needed. The example is:
"read the file at data/accounting/q1.ledger and explain what this ledger tracks"
If you know what the use needs to read or edit, you can inject knowledge/skills for the agent.
Git has easy to use GUI tools, particularly if you’re willing to use GitHub. I have not had trouble getting non technical staff to use it (book editors, graphic designers, writers, copywriters)
Very cool, sounds like you have some technically open-minded co-workers.
Do you just create a claude or codex plugin in git for them? Since they likely aren't working against any code repos?
yeah skills overwhelming is a problem. Splitting into sub-dirs works for now.
For us it's mostly developers.
That makes sense. The one thing that really bugs me about git sharing is when you have different repos but want to share the same collection of skills. We have three different golang projects/repos. They follow very similar patterns and can share a bunch of skills but I don't want to copy/paste into the different repos and have them drift.
I also like having a system on top that manages our evals so I know when I can retire a skill that isn't pulling it's weight and I can see the usage stats to understand which skills are making a real difference.
I feel that skills should live in the repo folder so they can be used by everyone on the project.
I landed on this too.
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.
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.
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.
Will a team wise GitHub repo a better solution?
- free version control - one line set up
sx has a git vault storage layer, or a local file layer or a server backed vault.
The thing it buys you over vanilla git is that you don't have to sym-link dirs for different AI harnesses. And, you can share skills across repos and teams without having to copy them into different repositories.
All that said, with the right setup, I think that vanilla git is a great answer. But if you start to want to bundle collections and share across teams and repos things start to fall apart.
Do you try to share across teams or repos? Or with non-technical teams?
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.
> And there was no way you were going to get your legal team to install and learn git.
Same thoughts. Get a team github repository and add the marketplace.
What's wrong with git?
Absolutely nothing, if it fits your usecase, but how do you handle e.g. reusing the same skill in multiple repos?
Are you manually keeping all copies in sync?
Not that i recommend it or anything but git submodules would probably work.
Who needs Dropbox? At my shop we're sharing skills with rsync...
[flagged]