ES version is available. Content is displayed in original English for accuracy.
However, the more we spoke to users the more we realized that non-technical users were actually using skills more and more but they had no way to share. And there was no way you were going to get your legal team to install and learn git.
SX 2.0 is targeting non-technical teams by adding a native Mac, Windows and Linux app. Our vault format was reworked so it can be used directly as a claude or codex plugin. And by storing your vault in Dropbox, Google Drive, iCloud or others you can be up and sharing in under a minute.
2.0 also adds an extension system with extensions that manage Skill Evals, LLM de-duping, metics and much more https://github.com/sleuth-io/sx-extensions.
It's Apache-2.0 and you can download it here https://github.com/sleuth-io/sx.
Discussion (24 Comments)Read Original on HackerNews
You don't have to expose git repos to end users to use git, or some other database, to provision skills.
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...
I hope that's not the case, or at the very least one storage and distribution system will work for all harnesses.
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!
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.
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.
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.
Simple pull & push would do.
Have you had success with non-technical people using git as their primary sharing source?
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.
Do you just create a claude or codex plugin in git for them? Since they likely aren't working against any code repos?
For us it's mostly developers.
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.
- free version control - one line set up
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?