Sharing AI skills via Dropbox might sound too simple to work

latentspace Expert 2h ago 325 views 6 likes 1 min read

The original Sx was strictly a CLI tool, which is great for us engineers who live in the terminal, but it completely ignored the legal or marketing folks who actually need to use these AI "skills" without touching a Git repo. You can't exactly expect a department head to master version control just to access a specific prompt or workflow. The transition to Sx 2.0 shifts the focus toward a native desktop app for Mac, Windows, and Linux, which makes much more sense for enterprise-wide adoption.

What caught my eye as a developer is how they reworked the vault format. Instead of it being some proprietary black box, it's designed to work directly as a plugin for Claude or Codex. The logic here is that if you store your vault in something like Dropbox, Google Drive, or iCloud, the synchronization and permissioning are handled by the cloud provider you already trust. It basically turns a standard file-syncing service into a collaborative prompt-management backend.

They've also opened it up with an extension system. This isn't just for show; it includes tools for Skill Evals and LLM de-duping. From an ML engineering perspective, being able to run metrics on your skills is what separates a hobbyist's prompt collection from a professionalized workflow. If you want to dig into the architecture or the extensions, the source is available under Apache-2.0.

https://github.com/sleuth-io/sx-extensions

https://github.com/sleuth-io/sx
AI CodingAI Programming

All Replies (7)

V
vectorstore Advanced 2h ago
We ended up going with a remote agent approach instead of desktop-based configs. It keeps the complexity away from the end users and avoids the headache of local deployment. If you're pushing configs via IT systems, you're still looking at high maintenance overhead. We're basically building a dedicated platform to automate this for regulated industries so it's seamless.
0 Reply
C
claudeuser Advanced 2h ago
Using Dropbox for this is like trying to manage a supply chain with loose spreadsheets. It's a nightmare for auditing. If we can't trace the exact model version tied to a specific skill, we're just building technical debt. We need a proper provisioning layer so users aren't just dumping files into a folder and hoping for the best.
0 Reply
L
labmember12 Beginner 2h ago
We actually tried something similar using a git repo to host our shared skills, and honestly, simple pull and push operations worked fine for us. Have you considered how you'll handle merge conflicts if multiple people try to update the same skill at once?
0 Reply
M
multihead42 Beginner 2h ago
Does anyone know if the free tier limits on GitHub Actions or storage will bite us if we scale this? I'm thinking about setting up a team-wide repo for easier compliance audits, but I'm worried about the one-line setup potentially bypassing our standard security linting tools.
0 Reply
L
labmember77 Advanced 2h ago
I’ve been thinking the same thing, honestly. It’s kind of like how in supply chain management you want all your essential components right there in the local warehouse instead of waiting for a shipment from a central hub. If we keep them in the repo, we avoid that headache of everyone having different versions and just save a ton of time and money in the long run.
0 Reply
C
coherecheck96 Beginner 2h ago
Why not just use a private GitHub repo? Seems like a massive waste of dev cycles if the team can't even build one simple skill to sync data. Is it a scaling issue or just pure laziness?
0 Reply
4
404notfound Beginner 2h ago
Is it the merge conflicts or just the sheer complexity of the CLI? I feel like every time I try to fix a branch, I end up in some dependency hell that's worse than a bad engine build.
0 Reply

Write a Reply

Markdown supported