← Back to Blogs
HN Story

Managing AI Assets at Scale: Introducing sx

May 17, 2026

Managing AI Assets at Scale: Introducing sx

As AI coding assistants like Claude Code, Cursor, and GitHub Copilot become central to the modern development workflow, a new problem has emerged: the fragmentation of "AI assets." These assets—custom prompts, Model Context Protocol (MCP) configurations, slash commands, and coding rules—are the secret sauce that make an AI assistant truly productive. However, these assets are typically trapped on individual developer machines or duplicated across repositories in a fragmented way.

sx is an open-source package manager designed to solve this by treating AI assets as versioned packages. It allows teams to capture the expertise of their most productive AI users and distribute it automatically across the entire organization.

The Problem: The "AI Asset" Fragmentation

For most teams, the current methods of sharing AI configurations are unsustainable:

  • Manual Copy-Pasting: Copying prompt files or .claude configs into every repository leads to a duplication nightmare and version drift.
  • Global Configurations: Using a single global config often bloats the AI's context window with irrelevant skills for the specific task at hand.
  • Client Lock-in: Many plugins are locked to a single AI client, making it difficult to switch tools or use a different assistant for a specific project.

sx addresses these issues by decoupling the asset from the client and the repository, providing a centralized "vault" for management and a scoped installation process.

How sx Works: The Manifest and Lock Pattern

Following the design patterns of npm, cargo, and uv, sx utilizes a manifest-and-lock system to ensure reproducibility and consistency:

  1. The Manifest (sx.toml): This is the source of truth for the vault. It defines every managed asset, its version, and the scopes to which it should be installed (e.g., organization, team, repository, or individual).
  2. The Lock File: When a user runs sx install, the tool resolves the manifest against the caller's identity and environment. It then writes a resolved lock file to the user's local cache. This ensures that the same set of tools is deployed to every developer on a team.
  3. Audit and Usage Streams: To maintain visibility, sx logs every mutation and usage event, allowing leads to track adoption via sx stats and sx audit.

Scoped Distribution and Versatility

One of the most powerful features of sx is its granular scoping model. Instead of a "one size fits all" approach, assets can be targeted specifically:

  • --org: Distributed to everyone in the vault.
  • --repo / --path: Only active when the developer is working within a specific repository or sub-directory.
  • --team: Limited to specific team members (admin-gated).
  • --user: Targeted to a single individual.
  • --bot: Assigned to a bot identity, such as a CI runner or an autonomous agent.

Supported Assets and Clients

sx is designed to be client-agnostic. It translates the same asset into the format required by various tools, supporting a wide array of clients including:

  • IDE-based assistants: Cursor, GitHub Copilot, Gemini (VS Code/JetBrains/Android Studio), and Codex.
  • CLI tools: Claude Code, Cline, and Kiro.
  • Open-web interfaces: claude.ai and chatgpt.com (via the skills.new cloud relay, which allows non-engineering teams like marketing or legal to access the same AI assets).

Distribution Models

Depending on the size of the organization, sx offers three distribution modes:

  • Local (Personal): A simple path-based vault for personal project synchronization.
  • Git Vault (Small Teams): A shared Git repository acting as the central source of truth.
  • Skills.new (Enterprise): A hosted backend with a UI for discovery, creation, and advanced analytics.

Community Perspectives and Technical Trade-offs

While the launch of sx has been met with enthusiasm for its clean approach to fragmented workflows, some developers have raised important questions regarding its placement in the software lifecycle.

One user questioned why these skills should be decoupled from the Git release cycle, suggesting that tying a skill to a specific commit SHA could help identify which version of a prompt caused a bug in production.

In response, the maintainers clarified that sx aims to solve the scale problem. While raw .CLAUDE.md files in Git are a good start, they lead to duplication across plugins and vendor lock-in. By treating assets as versioned packages, sx allows for a unified distribution layer that works across multiple AI clients simultaneously.

Getting Started

For those already using Claude Code, sx can auto-detect existing skills and commands in the .claude directory, making the transition seamless:

# Initialize a vault
sx init

# Add existing skills
sx add ~/.claude/commands/my-command

# Install assets to current project
sx install

By treating AI prompts and configurations as first-class citizens of the engineering organization, sx transforms individual "prompt engineering" hacks into scalable, shared team assets.

References

HN Stories