Recent submissions

Comment · 3 months ago
How do you concretely solve this for your marketing team? What’s the tech stack you have in place to support them?
Comment · 3 months ago
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.
Comment · 3 months ago
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.

Comment · 3 months ago
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.

Comment · 3 months ago
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.

Comment · 3 months ago
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.

Comment · 3 months ago
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?

Comment · 3 months ago
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?

Comment · 3 months ago
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...

Comment · 3 months ago
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?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton