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.

Sleuth | Remote (US and Europe) | Full Time | https://www.sleuth.io/careers

We're a series A company, Sleuth makes engineering efficiency measurable and easy to improve. We give teams a complete and accurate view into DORA metrics, insights on where the bottlenecks lie, and tools to automate workflows for efficiency.

We are hiring in Sales, Engineering, & more!

See more details on our open roles via the careers page linked above and you can apply by sending an email with your resume to jobs@sleuth.io

That's a great question, failure rate and MTTR are the two metrics teams have the most trouble getting a real handle on. We've found that different teams define change failure and MTTR in widely differing ways. Some customers just want to track incidents where others are using team KPIs as their definition of failure.

Today, you can manually update the status of a deploy as an incident, rollback, unhealthy or ailing. This allows you to "correct" data that Sleuth may have gotten wrong via integrations to Datadog or your incident management system. Right now the correction is at the deploy level. However, we do have more control coming soon so you can override any period of time as having been in a specific state.

Hi HN, Dylan here, co-founder of Sleuth (https://sleuth.io) along with Don and Michael. Together we have over 40 years of experience building developer tools at Atlassian (Jira, Bitbucket, Hipchat, Statuspage).

Over the past 15 years we've witnessed first-hand the positive impact of frequent deployments, but watched as teams struggled to get the visibility needed to continue progressing towards Continuous Delivery.

In our experience, the larger the team, and the faster they move, the harder it becomes for engineering leaders to find "trust but verify" moments - the moments where you should dig in and ensure your team is improving or in a good place.

With Sleuth, we decided to focus solely on Accelerate / DORA metrics because 1) studies have proven they affect software delivery performance, and 2) they're project- and team-based, vs. targeting individual developers. A healthy team depends on trust between team and leadership. Sleuth helps you verify without breaking trust with your developers.

Sleuth is the #1 most accurate way to track Accelerate metrics because it integrates with sources of truth beyond source control - such as issues, builds, observability metrics, incidents, etc - and tracks deploys to all your environments, so it knows when a change actually deploys to your customers.

Deploy Frequency and Change Lead Time: Sleuth gives you a detailed breakdown of time spent by activity, like coding, waiting for review to begin, reviewing, and how long it takes to deploy. More importantly, it shows you exactly how the metrics came to be.

Change Failure Rate: we recognize that failure could mean something different to different teams. Sleuth allows teams to define failure as broadly as an incident, to something as simple as a rollback, or as finely as a custom observability metric being outside of its normal range. To do this, Sleuth connects with observability tools like Datadog, New Relic, Sentry, etc.

MTTR: Understanding failure means we have an accurate view of MTTR, and Sleuth lets you know how much time your project has spent in: incident, rollback, unhealthy or ailing states. With instant Slack notifications Sleuth sends to developers, you can easily drive your MTTD to zero.

We want to help teams improve, not just track metrics, and the best way to do that is to empower developers! Features like deploy locking, Slack-based deploy approvals, and deploy verification help make deploys easier and less stressful to developers - and makes Sleuth a tool for devs as much as it is for managers.

To date, Sleuth is used by teams at companies like LaunchDarkly, Ujet, Secure Code Warrior, Flatfile, Automox, Atlassian, and more.

You can check out Sleuth by going to our website (Sleuth | Accelerate metrics and deployment tracking ) or better yet, watching us sleuth in Sleuth (https://app.sleuth.io/sleuth/sleuth/metrics/lead_time) - building dev tools is the best! Or you can try our 30-day trial and quickly find out what your Accelerate (DORA) baseline looks like.

We’re sure many HN members will have encountered similar challenges with engineering productivity and/or have expertise in this area. We’d love to hear from you: How do you track your team's performance? Do you track Accelerate metrics? What works and doesn’t? Thank you!

Sorry about that the live demo is at https://app.sleuth.io/sleuth/sleuth

I ran the Bitbucket team for 5 years and in that time this was the tool I wanted for understanding what the team was shipping and for letting the rest of Atlassian know what we were up to.

Creating a project on DeployHub makes it easy to understand when your features ship:

* Integrates with your GitHub or Bitbucket repositories

* See commits, issues, pull requests, changed files and authors for every deploy

* Allow everyone in your organization to understand what code changes you're shipping by subscribing to email digests

* Instantly see the full code diff for a deploy

* Quickly see when you've rolled out code and exactly what's changed to help squash bugs

* Have automatically generated release notes sent to your Slack or HipChat team channels

* See an aggregate of what's been deployed today, this week or this month

I've been working on this passion project for some time and I'm excited to share it with all of you and answer any questions you might have.