They are more than that, for example the frontmatter and code files around them. The spec: https://agentskills.io/specification

Why do I want to throw away my dependency management system and shared libraries folder for putting scripts in skills?

What tools do they have access to, can I define this so it's dynamic? Do skills even have a concept for sub tools or sub agents? Why do I want to put references in a folder instead of a search engine? Does frontmatter even make sense, why not something closer to a package.json in a file next to it?

Does it even make sense to have skills in the repo? How do I use them across projects? How do we build an ecosystem and dependency management system for skills (which are themselves versioned)

▲

arrowsmith 8 hours ago | parent [-]

> They are more than that, for example the frontmatter and code files around them.

You are right. I have edited my post slightly.

> Why do I want to throw away my dependency management system and shared libraries folder for putting scripts in skills?

You don't have to put scripts in skills. The script can be anywhere the agent can access. The skill just needs to tell the LLM how to run it.

> Does it even make sense to have skills in the repo? How do I use them across projects?

You don't have to put them in the repo. E.g. with Claude Code you can put project-specific skills in `.claude/skills` in the repo and system-wide skills in `~/.claude/skills`.

	▲	verdverm 8 hours ago \| parent [-]
		2. The spec / docs show people how to put code in a subdir. While you can reference external scripts, there is a blessed pattern that seems like an anti-pattern to me 3. generalize: how do I store, maintain, and distribute skills shared by employees who work on multiple repos. Sounds like standard dependency management to me. Does to some of the people building collections / registries. Not sure if any of them account for versioning, have not seen anything tied to lock files (though I'd avoid that by using MVS for dep selection)