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?

▲

maxdo 3 hours ago | parent [-]

with git, you even have git blame and everything else that makes it nice, once you merge it everyone else got access to it, with exception to local branch, which is a gray area, you can argue you want to lock the skill version to your code.

▲

detkin 3 hours ago | parent [-]

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?

	▲	maxdo 41 minutes ago \| parent \| next [-]
		we are in the world where everyone is doing things differently now, but here is my 5 cents. I almost 100% sure everything that you described is part of nested harness of your company, not some external registry. what would you like to share? there a few generic skills, that are optional , e.g. tdd, etc. sure. Maybe environment related items, like going to db , how to use secrets etc, the surface of that is very very thin. you place them in git, and vibe code a tiny script on how to pull it in. done? the rest are debugging scripts, very specific skills, that are very coupled to the root repo. I tried a few similar "external" systems. Anything beyond ralph loop/use tdd skills, feels hostile in your internal system.
	▲	huflungdung 2 hours ago \| parent \| prev [-]
		[dead]