Show HN: Sx – an open-source package manager for AI skills, MCPs, and commands

detkin

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...

maxdo

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?

garettmd

How does one pronounce this tool

waffleman21

I've been working on something very similar: https://github.com/shrug-labs/aipack/tree/main/ I therefore love the idea. Thanks for sharing

eqvinox

One more package manager will fix it. One more! I don't disagree there's probably a need and niche, but why not extend and adapt an existing package manager?