I find that even though this isn't standard, that these -cli tools will scan the repo for .md files and for the most part execute the skills accordingly. Having said that, I would much prefer standards not just for this, but for plugins as well.
Standards for plugins makes sense, because you're establishing a protocol that both sides need to follow to be able to work together.
But I don't see why you need a strict standard for "an informal description of how to do a particular task". I say "informal" because it's necessarily written in prose -- if it were formal, it'd be a shell script.
I mean, it'd be good if these tools followed the xdg base spec and put their config in `~/.config/claude` e.t.c instead of `~/.claude`.
It's one of my biggest pet peeves with a lot of these tools (now admittedly a lot of them have a config env var to override, but it'd be nice if they just did the right thing automatically).
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)
Agreed. I think being overly formal about what can be in the frontmatter would be a mistake, but the beauty of doing this with an LLM is that you can pretty much emulate skills in any agent by telling it to start by reading the frontmatter of each skills file and use that to decide when to read the rest, so given that as a fallback, it's hardly imposing some massive burden to standardise it a bit.
That doesn't work very well if your developers are on Windows (and most are). Uneven Git support for symbolic links across platforms is going to end up causing more problems than it solves.
It's why I wrapped my tiny skills repo with a script that softlink them into whichever is your skills folder, defaulting to Claude, but could be any other.
I treat my skills the same as I would write tiny bash scripts and fish functions in the days gone to simplify my life by writing 2 words instead of 2 sentences. Tiny improvement that only makes sense for a programmer at heart.
This is happening as we speak.
Codex started this and OpenCode followed suit with the hour.
https://x.com/embirico/status/2018415923930206718
“Proposal: include a standard folder where agent skills should be“
https://github.com/agentskills/agentskills/issues/15
Could we adhere to the XDG standard and put config in ~/config/agents Or perhaps create a new XDG standard? Like $XDG_AGENTS_HOME ?
I find that even though this isn't standard, that these -cli tools will scan the repo for .md files and for the most part execute the skills accordingly. Having said that, I would much prefer standards not just for this, but for plugins as well.
Standards for plugins makes sense, because you're establishing a protocol that both sides need to follow to be able to work together.
But I don't see why you need a strict standard for "an informal description of how to do a particular task". I say "informal" because it's necessarily written in prose -- if it were formal, it'd be a shell script.
That is being discussed in https://github.com/agentskills/agentskills/issues/15.
I mean, it'd be good if these tools followed the xdg base spec and put their config in `~/.config/claude` e.t.c instead of `~/.claude`.
It's one of my biggest pet peeves with a lot of these tools (now admittedly a lot of them have a config env var to override, but it'd be nice if they just did the right thing automatically).
.agent/
Skills seem a bit early to standardize. We are so early in this, why do we want to handcuff our creativity so soon?
Skills are a really simple concept. They're just custom prompts with a name and some metadata. What are you afraid of handcuffing?
Just the decision of whether to allow models to invoke them has [1][2][3] different ways.
[1]: https://code.claude.com/docs/en/skills#control-who-invokes-a... [2]: https://opencode.ai/docs/skills/#disable-the-skill-tool [3]: https://developers.openai.com/codex/skills/#enable-or-disabl...
3 replies →
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)
2 replies →
Agreed. I think being overly formal about what can be in the frontmatter would be a mistake, but the beauty of doing this with an LLM is that you can pretty much emulate skills in any agent by telling it to start by reading the frontmatter of each skills file and use that to decide when to read the rest, so given that as a fallback, it's hardly imposing some massive burden to standardise it a bit.
it's actually .agents/ :)
why plural?
3 replies →
There are 14 competing standards.
The problem is that the de facto standard is `.claude`, which is problematic for folks not using Claude.
Your skill then just becomes an .md file containing
>any time you want to search for a skill in `./codex`, search instead in `./claude`
and continue as you were.
2 replies →
Now, there are 15 competing standards.
Soon...
Worse yet; opencode uses singular words by default:
On the website[1] it says:
[1]: https://opencode.ai/docs/skills/#place-files
They changed it. It was singular.
ln -s to the rescue!
That doesn't work very well if your developers are on Windows (and most are). Uneven Git support for symbolic links across platforms is going to end up causing more problems than it solves.
Win developers aren't using WSL?
It's why I wrapped my tiny skills repo with a script that softlink them into whichever is your skills folder, defaulting to Claude, but could be any other.
I treat my skills the same as I would write tiny bash scripts and fish functions in the days gone to simplify my life by writing 2 words instead of 2 sentences. Tiny improvement that only makes sense for a programmer at heart.
[1] https://github.com/flurdy/agent-skills
The root cause should be fixed.
Why not hardlinks?
You can't hardlink a directory.
1 reply →
might be too early to standardize
standards are good but they slow development and experimentation