why this do not belong to git, and does not go with release cycle.
With bigger autonomy, I'd like my skill be tight to my release in prod/commit sha for dev, to figure out what version caused harm/bug. What is the motivation to decouple and make it a separate thing?
with git, you even have git blame and everything else that makes it nice, once you merge it everyone else got access to it, with exception to local branch, which is a gray area, you can argue you want to lock the skill version to your code.
The sx vault also stores things in git, I agree that it's a pretty good medium for storage.
My main argument is that just using vanilla git where you store it in the directory that the AI coding agent expects means that you can't share across teams or orgs.
Also, not every kind of team is comfortable with git. How would you distribute these assets to a Marketing team?
The short version: sx treats skills, MCP server configs, slash commands, agents, hooks, and rule files as versioned packages. You define them once, push them to a vault (a local folder, a git repo, or our hosted backend), and install them where they belong. There's a lockfile so installs are reproducible, scope levels for org / team / repo / individual, and the CLI translates the same asset into the format each AI client expects.
Supported clients today: Claude Code, Cursor, GitHub Copilot, Cline, Codex, Gemini (CLI / VS Code / JetBrains / Android Studio), Kiro, claude.ai, chatgpt.com. The last two are what let non-engineering teams (marketing, legal, ops) use the same primitive instead of being locked out of the AI-assets ecosystem.
The thing I'd most like feedback on is whether the scope model is the right shape. Org → team → repo → path → individual is what's emerged from talking to ~60 teams over the last six months, but I expect bigger orgs will surface scopes we haven't modeled (sub-team, environment, etc.).
Why this and not just plugins / vendor marketplaces? Claude Code plugins are real and a good step up over raw git-checked-in CLAUDE.md files. The limitations show up at scale: each plugin is scoped to its publishing repo, so teams duplicate skills across plugins, and you're still locked to a single vendor's client. Full writeup with the technical details: https://www.sleuth.io/post/there-s-an-npm-shaped-hole-in-the...
not sure if this premise is valid. In most cases, skills (and other assets) are not independent of each other. Take gstack por example; it would be weird to install skill A without installing skill B. They work together.
So, it is true that some skills are independent, but not all. IN my company, we ship assets by domain and workflows (development, discovery, data science, etc)
Say more, what kind of tools are you thinking about?
The tool support is certainly one of the key pillars of the project so we're open to any tool additions that will help people get value from the project.
How does one pronounce this tool
lol, just s ... x, the two letters.
We wanted something short and easy to remember
It's like in "essex" but I fear those more adventurous will short it out at the first "e".
why this do not belong to git, and does not go with release cycle.
With bigger autonomy, I'd like my skill be tight to my release in prod/commit sha for dev, to figure out what version caused harm/bug. What is the motivation to decouple and make it a separate thing?
with git, you even have git blame and everything else that makes it nice, once you merge it everyone else got access to it, with exception to local branch, which is a gray area, you can argue you want to lock the skill version to your code.
The sx vault also stores things in git, I agree that it's a pretty good medium for storage.
My main argument is that just using vanilla git where you store it in the directory that the AI coding agent expects means that you can't share across teams or orgs.
Also, not every kind of team is comfortable with git. How would you distribute these assets to a Marketing team?
seven
Hi HN — I'm one of the maintainers.
The short version: sx treats skills, MCP server configs, slash commands, agents, hooks, and rule files as versioned packages. You define them once, push them to a vault (a local folder, a git repo, or our hosted backend), and install them where they belong. There's a lockfile so installs are reproducible, scope levels for org / team / repo / individual, and the CLI translates the same asset into the format each AI client expects.
Supported clients today: Claude Code, Cursor, GitHub Copilot, Cline, Codex, Gemini (CLI / VS Code / JetBrains / Android Studio), Kiro, claude.ai, chatgpt.com. The last two are what let non-engineering teams (marketing, legal, ops) use the same primitive instead of being locked out of the AI-assets ecosystem.
The thing I'd most like feedback on is whether the scope model is the right shape. Org → team → repo → path → individual is what's emerged from talking to ~60 teams over the last six months, but I expect bigger orgs will surface scopes we haven't modeled (sub-team, environment, etc.).
Why this and not just plugins / vendor marketplaces? Claude Code plugins are real and a good step up over raw git-checked-in CLAUDE.md files. The limitations show up at scale: each plugin is scoped to its publishing repo, so teams duplicate skills across plugins, and you're still locked to a single vendor's client. Full writeup with the technical details: https://www.sleuth.io/post/there-s-an-npm-shaped-hole-in-the...
not sure if this premise is valid. In most cases, skills (and other assets) are not independent of each other. Take gstack por example; it would be weird to install skill A without installing skill B. They work together.
So, it is true that some skills are independent, but not all. IN my company, we ship assets by domain and workflows (development, discovery, data science, etc)
Will there be support for importing other tools that have their own CLIs?
Say more, what kind of tools are you thinking about?
The tool support is certainly one of the key pillars of the project so we're open to any tool additions that will help people get value from the project.