detkin

How do you concretely solve this for your marketing team? What’s the tech stack you have in place to support them?

A repo, if it’s not overly complex, is a great place to store skills for all the reasons you list. It’s just not the only place where skills are super valuable.

I completely agree and sx tries to make it easier to share, not just on one project/repo but across teams.

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.

The one place I’ve seen this break down on teams is when a skill gets improved or adjusted. If everyone is copying it you end up not knowing which the best and most accurate. We worked with a team that had 5 copies that had all drifted.

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.

It also wouldn't surprise me if the model companies ship a strong version of this to try to lock us all in a bit more.

I hope that's not the case, or at the very least one storage and distribution system will work for all harnesses.

That makes sense. The one thing that really bugs me about git sharing is when you have different repos but want to share the same collection of skills. We have three different golang projects/repos. They follow very similar patterns and can share a bunch of skills but I don't want to copy/paste into the different repos and have them drift.

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.

Very cool, sounds like you have some technically open-minded co-workers.

Do you just create a claude or codex plugin in git for them? Since they likely aren't working against any code repos?

sx has a git vault storage layer, or a local file layer or a server backed vault.

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?

Hey man! Yeah, many of the non-techincal folks I've spoken to are using claude.ai or chatgpt.com. But I've been amazed at how many are using Claude CoWork or even Claude Code.

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 agree that that works pretty well for developers who work with a code repository everyday. But, if you're working on a mono-repo, you can end up with more skills loading than you'd like pretty quickily.

Have you had success with non-technical people using git as their primary sharing source?

Yes. You can just point sx add at your existing skill directories and it will put them into the git vault which you can easily share via Github access control.

Thank you for sharing, this is exactly the kind of thing I'm interested in learning.

Is this just for engineering or is it being used for other functions, like Marketing and HR as well?

Very cool! What would you say is the biggest learning you've had about how people are using it?

We added the idea of dependencies for exactly that reason. However, honestly, I've not see any usage of it in the wild. Seems like most folks are ok with either bundling them and calling it a day or not really worrying about it.

Very interesting about the domain and workflows. Do you think domain could map to a team or is it different?

At your company how are you shipping your assets? How do you do the domain and workflow grouping?

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.

lol, just s ... x, the two letters.

We wanted something short and easy to remember

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?

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

At some of the larger orgs that I've worked at each individual system had some level of RBAC. Often they would try to centralize around an Okta-style system, but the roles in there infrequently matched what was needed. In the places you are describing what have they done around security? Even without AI it sounds like they didn't have a feasible solution?

Machine assisted, not fully machine generated ¯\_(ツ)_/¯

You're right, I used AI to help organize the content but we have spoken to almost 50 companies over the last 5 months and the messages and pains they have conveyed are real.

How are you handing distributing your Agent Skills and MCP's? Is this a problem you're seeing?

I hear you, results is a gray area. However, with the companies we spoke to results looks like increased productivity for their developers.

It was a constant with all that they felt like 2 - 7 percent of their developers had made huge productivity gains but that the rest were not really seeing any, despite having access to the same tools.

Seems very interesting.

Skills have been really helpful in my team as we've been encoding tribal knowledge into something that other developers can easily take advantage of. For example, our backend architecture has these hidden patterns, that once encoding in a skill, can be followed by full stack devs doing work there, saving a ton of time in coding and PR review.

We then hit the problem of how to best share these and keep them up to date, especially with multiple repositories. It led us to build sx - https://github.com/sleuth-io/sx, a package manager for AI tools.

Hey all, Dylan here, co-founder of Sleuth (http://sleuth.io), along with Don and Michael. We just launched a powerful automations framework and marketplace that allows dev teams to discover and implement best practice workflows with a single click. We’re excited to share and to make life easier for developers and teams.

For background, Sleuth makes improving engineering efficiency easy and continuous. We started by focusing on tracking DORA metrics to give teams useful insight they can act on to improve (https://news.ycombinator.com/item?id=27974573). We built first-class integrations that span your entire software delivery tech stack, from ticketing and change management all the way through to CI/CD and observability tools.

Now, we’re leveraging that foundation to allow teams to improve engineering efficiency even more rapidly, continuously and easily with automation. We’ve built a bunch of engineering best practices into no-code automations that you can install via a single click from our Automations Marketplace (https://marketplace.sleuth.io/ ). These will help your teams drive improvements across their entire engineering tech stack.

We built this to give software teams the capabilities they’ve always wanted, but that are often too much lift to invest in. We see four key categories of these capabilities:

PR Checks – They’re like linters for your PR process. They let you analyze pull requests to ensure they conform to industry best practices, cutting down review time and improving morale by relieving reviewers of the onus of “policing” best practices.

Notifications – drive awareness, nudge things in the right direction and help teams respond quickly by automatically alerting them when Sleuth determines there’s something they need to know.

Actions – provide a variety of simple, if-this-then-that automations targeted across your software delivery tool chain, that allow you to modify a state in an external system — like automatically transitioning or commenting on a Jira issue to let stakeholders know immediately when a change they care about has deployed to its target environment.

Workflows – provide advanced automations that can evaluate conditions and perform actions across multiple integrated tools. If you’ve ever wanted Slack-based approvals for deploys moving from staging to production, now you have have it with a single click.

We’d love for you to check them all out in our Marketplace and let us know what feedback you have. Thanks in advance!

You can check out Sleuth by going to our website (https://www.sleuth.io ) or better yet, watching us in action in Sleuth (https://app.sleuth.io/sleuth/sleuth/metrics/). Or, you can try our 30-day trial.